VictoriaMetrics é um SGBD rápido e escalável para armazenamento e processamento de dados na forma de uma série temporal (um registro consiste em um tempo e um conjunto de valores correspondentes a esse tempo, por exemplo, obtidos por meio de pesquisas periódicas do status dos sensores ou coleção de métricas).
Meu nome é Kolobaev Pavel. DevOps, SRE, LeroyMerlin, tudo é como código - é tudo sobre nós: sobre mim e sobre outros funcionários da LeroyMerlin.
Existe uma nuvem baseada em OpenStack. Existe um pequeno link para o radar técnico.
Ele é construído no hardware Kubernetes, bem como em todos os serviços relacionados para OpenStack e registro.
Este é o esquema que tínhamos em desenvolvimento. Quando estávamos desenvolvendo tudo isso, tínhamos um operador Prometheus que armazenava dados dentro do próprio cluster K8s. Ele automaticamente encontra o que precisa ser esfregado e coloca sob seus pés, grosso modo.
Precisaremos mover todos os dados para fora do cluster Kubernetes, porque se algo acontecer, precisaremos entender o que e onde.
A primeira solução é usarmos a federação quando tivermos um Prometheus de terceiros, quando formos para o cluster Kubernetes através do mecanismo de federação.
Mas existem alguns pequenos problemas aqui. No nosso caso, os problemas começaram quando tínhamos 250 mil métricas, e quando havia 000 mil métricas, percebemos que não poderíamos trabalhar assim. Aumentamos scrape_timeout para 400 segundos.
Por que tivemos que fazer isso? Prometheus começa a contar o tempo limite desde o início da cerca. Não importa que os dados ainda estejam fluindo. Se durante esse período especificado os dados não forem mesclados e a sessão não for fechada via http, a sessão será considerada como tendo falhado e os dados não entrarão no próprio Prometheus.
Todos estão familiarizados com os gráficos que obtemos quando faltam alguns dados. Os horários estão rasgados e não estamos satisfeitos com isso.
A próxima opção é a fragmentação baseada em dois Prometheus diferentes por meio do mesmo mecanismo de federação.
Por exemplo, basta pegá-los e fragmentá-los pelo nome. Isso também pode ser usado, mas decidimos seguir em frente.
Agora teremos que processar esses fragmentos de alguma forma. Você pode pegar o promxy, que vai para a área do shard e multiplica os dados. Funciona com dois fragmentos como um único ponto de entrada. Isso pode ser implementado através do promxy, mas ainda é muito difícil.
A primeira opção é abandonarmos o mecanismo de federação porque é muito lento.
Os desenvolvedores do Prometheus estão dizendo claramente: "Pessoal, usem um TimescaleDB diferente porque não ofereceremos suporte ao armazenamento de métricas a longo prazo." Esta não é a tarefa deles.
Anotamos em um pedaço de papel que ainda precisamos descarregar lá fora, para não guardar tudo no mesmo lugar.
A segunda desvantagem é o consumo de memória. Sim, entendo que muitos dirão que em 2020 alguns gigabytes de memória custam um centavo, mas ainda assim.
Agora temos um ambiente de desenvolvimento e produção. No desenvolvimento, são cerca de 9 gigabytes para 350 métricas. Em produção, são 000 gigabytes e pouco mais de 14 métricas. Ao mesmo tempo, nosso tempo de retenção é de apenas 780 minutos. Isto é mau. E agora vou explicar o porquê.
Fazemos um cálculo, ou seja, com um milhão e meio de métricas, e já estamos próximos delas, na fase de projeto obtemos 35-37 gigabytes de memória. Mas já 4 milhões de métricas requerem cerca de 90 gigabytes de memória. Ou seja, foi calculado usando a fórmula fornecida pelos desenvolvedores do Prometheus. Analisamos a correlação e percebemos que não queríamos pagar alguns milhões por um servidor apenas para monitoramento.
Não só aumentaremos o número de máquinas, como também monitoraremos as próprias máquinas virtuais. Portanto, quanto mais máquinas virtuais, mais métricas de vários tipos, etc. Teremos um crescimento especial do nosso cluster em termos de métricas.
Com espaço em disco nem tudo é tão ruim aqui, mas gostaria de melhorar. Recebemos um total de 15 gigabytes em 120 dias, dos quais 100 são dados compactados, 20 são dados descompactados, mas sempre queremos menos.
Nesse sentido, anotamos mais um ponto - trata-se de um grande consumo de recursos, que ainda queremos economizar, pois não queremos que nosso cluster de monitoramento consuma mais recursos do que nosso cluster, que gerencia o OpenStack.
Há mais uma desvantagem do Prometheus, que identificamos por nós mesmos: é pelo menos algum tipo de limitação de memória. Com o Prometheus aqui tudo é muito pior, porque não tem essas reviravoltas. Usar um limite no docker também não é uma opção. Se de repente o seu RAF cair e houver 20 a 30 gigabytes, demorará muito para aumentar.
Esta é outra razão pela qual o Prometheus não é adequado para nós, ou seja, não podemos limitar o consumo de memória.
Seria possível criar tal esquema. Precisamos deste esquema para organizar um cluster HA. Queremos que nossas métricas estejam disponíveis sempre e em qualquer lugar, mesmo se o servidor que armazena essas métricas falhar. E assim teremos que construir tal esquema.
Este esquema diz que teremos duplicação de shards e, consequentemente, duplicação dos custos dos recursos consumidos. Pode ser dimensionado quase horizontalmente, mas mesmo assim o consumo de recursos será infernal.
Desvantagens em ordem na forma em que as escrevemos para nós mesmos:
- Requer upload de métricas externamente.
- Alto consumo de recursos.
- Não há como limitar o consumo de memória.
- Implementação complexa e com uso intensivo de recursos de HA.
Por nós mesmos, decidimos que estávamos nos afastando do Prometheus como depósito.
Identificamos requisitos adicionais de que precisamos para nós mesmos. Esse:
- Este é o suporte ao promql, porque muitas coisas já foram escritas para o Prometheus: consultas, alertas.
- E então temos o Grafana, que já foi escrito exatamente da mesma maneira para o Prometheus como backend. Não quero reescrever painéis.
- Queremos construir uma arquitetura HA normal.
- Queremos reduzir o consumo de quaisquer recursos.
- Há outra pequena nuance. Não podemos usar vários tipos de sistemas de coleta de métricas em nuvem. Ainda não sabemos o que cairá nessas métricas. E como tudo pode voar para lá, temos que nos limitar à colocação local.
Houve pouca escolha. Coletamos tudo o que tivemos experiência. Vimos a página do Prometheus na seção de integração, lemos vários artigos e vimos o que havia por aí. E para nós mesmos, escolhemos VictoriaMetrics como substituto do Prometheus.
Por que? Porque:
- Pode fazer promql.
- Existe uma arquitetura modular.
- Não requer alterações no Grafana.
- E o mais importante, provavelmente iremos fornecer o armazenamento de métricas dentro de nossa empresa como um serviço, por isso estamos olhando antecipadamente para restrições de vários tipos para que os usuários possam usar todos os recursos do cluster de alguma forma limitada, porque há uma chance que será multilocatário.
Vamos fazer a primeira comparação. Pegamos o mesmo Prometheus dentro do cluster, o Prometheus externo vai até ele. Adicione via remoteWrite VictoriaMetrics.
Farei imediatamente uma reserva que aqui detectamos um ligeiro aumento no consumo de CPU do VictoriaMetrics. O wiki VictoriaMetrics informa quais parâmetros são melhores. Nós os verificamos. Eles reduziram muito bem o consumo de CPU.
No nosso caso, o consumo de memória do Prometheus, localizado no cluster Kubernetes, não aumentou significativamente.
Comparamos duas fontes de dados com os mesmos dados. No Prometheus vemos os mesmos dados ausentes. Está tudo bem na VictoriaMetrics.
Resultados do teste de espaço em disco. Nós da Prometheus recebemos 120 gigabytes no total. Na VictoriaMetrics já recebemos 4 gigabytes por dia. Existe um mecanismo um pouco diferente daquele que estamos acostumados a ver no Prometheus. Ou seja, os dados já ficam bastante bem compactados em um dia, em meia hora. Já foram bem colhidos em um dia, em meia hora, apesar de os dados ainda se perderem depois. Como resultado, economizamos espaço em disco.
Também economizamos no consumo de recursos de memória. No momento do teste, tínhamos o Prometheus implantado em uma máquina virtual - 8 núcleos, 24 gigabytes. Prometeu come quase tudo. Ele caiu em cima do OOM Killer. Ao mesmo tempo, apenas 900 métricas ativas foram inseridas nele. Isso representa cerca de 000 a 25 métricas por segundo.
Executamos o VictoriaMetrics em uma máquina virtual dual-core com 8 gigabytes de RAM. Conseguimos fazer o VictoriaMetrics funcionar bem mexendo em algumas coisas em uma máquina de 8 GB. No final, mantivemos 7 gigabytes. Ao mesmo tempo, a velocidade de entrega do conteúdo, ou seja, das métricas, foi ainda maior que a do Prometheus.
A CPU ficou muito melhor em comparação com o Prometheus. Aqui o Prometheus consome 2,5 núcleos e o VictoriaMetrics consome apenas 0,25 núcleos. No início – 0,5 núcleos. À medida que se funde, atinge um núcleo, mas isso é extremamente raro.
No nosso caso, a escolha recaiu sobre a VictoriaMetrics por razões óbvias: queríamos poupar dinheiro e conseguimos.
Risquemos logo dois pontos – o upload de métricas e o alto consumo de recursos. E só nos resta decidir dois pontos que ainda nos restam.
Aqui já vou fazer uma reserva, consideramos o VictoriaMetrics um armazenamento de métricas. Mas como provavelmente forneceremos VictoriaMetrics como armazenamento para todo Leroy, precisamos limitar aqueles que usarão esse cluster para que não o forneçam para nós.
Existe um parâmetro maravilhoso que permite limitar por tempo, volume de dados e tempo de execução.
Existe também uma excelente opção que nos permite limitar o consumo de memória, podendo assim encontrar o equilíbrio que nos permitirá obter uma velocidade normal de funcionamento e um consumo adequado de recursos.
Menos mais um ponto, ou seja, riscar o ponto - você não pode limitar o consumo de memória.
Nas primeiras iterações, testamos VictoriaMetrics Single Node. Em seguida, passamos para a versão VictoriaMetrics Cluster.
Aqui temos liberdade para separar diferentes serviços no VictoriaMetrics dependendo de onde eles serão executados e quais recursos irão consumir. Esta é uma solução muito flexível e conveniente. Nós usamos isso em nós mesmos.
Os principais componentes do VictoriaMetrics Cluster Version são vmstsorage. Pode haver N número deles. No nosso caso, existem 2 deles até agora.
E há vminsert. Este é um servidor proxy que nos permite: organizar o sharding entre todos os storages de que falamos, e também permite uma réplica, ou seja, você terá tanto o sharding quanto uma réplica.
Vminsert oferece suporte aos protocolos OpenTSDB, Graphite, InfluxDB e remoteWrite do Prometheus.
Também existe o vmselect. Sua principal tarefa é ir ao vmstorage, receber os dados deles, desduplicar esses dados e entregá-los ao cliente.
Existe uma coisa maravilhosa chamada vmagent. Nós realmente gostamos dela. Ele permite que você configure exatamente como o Prometheus e ainda faça tudo exatamente como o Prometheus. Ou seja, coleta métricas de diferentes entidades e serviços e as envia para o vminsert. Então tudo depende de você.
Outro ótimo serviço é o vmalert, que permite usar VictoriaMetrics como backend, receber dados processados do vminsert e enviá-los para o vmselect. Ele processa os próprios alertas, bem como as regras. No caso de alertas, recebemos o alerta através do alertmanager.
Existe um componente wmauth. Podemos ou não (ainda não decidimos isso) usá-lo como um sistema de autorização para a versão multitenancy de clusters. Ele suporta remoteWrite for Prometheus e pode autorizar com base na url, ou melhor, na segunda parte dela, onde você pode ou não escrever.
Há também vmbackup, vmrestore. Isto é, em essência, a restauração e backup de todos os dados. Pode fazer S3, GCS, arquivo.
A primeira iteração do nosso cluster foi feita durante a quarentena. Naquela época, não havia réplica, então nossa iteração consistia em dois clusters diferentes e independentes nos quais recebíamos dados via remoteWrite.
Aqui farei uma ressalva que quando mudamos do VictoriaMetrics Single Node para o VictoriaMetrics Cluster Version, ainda permanecemos com os mesmos recursos consumidos, ou seja, o principal deles é a memória. É aproximadamente assim que nossos dados, ou seja, o consumo de recursos, foram distribuídos.
Uma réplica já foi adicionada aqui. Combinamos tudo isso em um cluster relativamente grande. Todos os nossos dados são fragmentados e replicados.
Todo o cluster possui N pontos de entrada, o que significa que o Prometheus pode adicionar dados via HAPROXY. Aqui temos esse ponto de entrada. E através deste ponto de entrada você pode fazer login no Grafana.
No nosso caso, HAPROXY é a única porta que os proxies selecionam, inserem e outros serviços dentro deste cluster. No nosso caso, era impossível fazer um endereço; tivemos que fazer vários pontos de entrada, porque as próprias máquinas virtuais nas quais o cluster VictoriaMetrics é executado estão localizadas em zonas diferentes do mesmo provedor de nuvem, ou seja, não dentro da nossa nuvem, mas fora .
Temos alerta. Nós usamos isso. Usamos o alertmanager do Prometheus. Usamos Opsgenie e Telegram como canal de entrega de alertas. No Telegram, eles vêm do dev, talvez algo do prod, mas principalmente algo estatístico, necessário aos engenheiros. E o Opsgenie é crítico. São chamadas, gerenciamento de incidentes.
A eterna pergunta: “Quem monitora o monitoramento?” No nosso caso, o monitoramento monitora o próprio monitoramento, porque usamos vmagent em cada nó. E como nossos nós estão distribuídos em diferentes data centers do mesmo provedor, cada data center tem seu próprio canal, são independentes e mesmo que chegue um cérebro dividido, ainda receberemos alertas. Sim, haverá mais deles, mas é melhor receber mais alertas do que nenhum.
Terminamos nossa lista com uma implementação de HA.
E ainda gostaria de destacar a experiência de comunicação com a comunidade VictoriaMetrics. Acabou sendo muito positivo. Os caras são receptivos. Eles tentam se aprofundar em cada caso que é oferecido.
Comecei problemas no GitHub. Eles foram resolvidos muito rapidamente. Há mais alguns problemas que não estão completamente resolvidos, mas já posso ver pelo código que o trabalho nessa direção está em andamento.
A principal dor para mim durante as iterações foi que, se eu desligasse um nó, nos primeiros 30 segundos o vminsert não conseguiria entender que não havia back-end. Isto já foi decidido. E literalmente em um ou dois segundos, os dados são obtidos de todos os nós restantes e a solicitação para de esperar pelo nó ausente.
Em algum momento, queríamos que a VictoriaMetrics fosse uma operadora da VictoriaMetrics. Esperamos por ele. Agora estamos construindo ativamente uma estrutura para o operador VictoriaMetrics aceitar todas as regras de pré-cálculo, etc. Prometheus, porque estamos usando ativamente as regras que vêm com o operador Prometheus.
Existem propostas para melhorar a implementação do cluster. Eu os descrevi acima.
E eu realmente quero reduzir a resolução. No nosso caso, a redução da resolução é necessária exclusivamente para visualizar tendências. Grosso modo, uma métrica é suficiente para mim durante o dia. Essas tendências são necessárias para um ano, três, cinco, dez anos. E um valor métrico é suficiente.
- Conhecemos a dor, assim como alguns de nossos colegas, ao usar o Prometheus.
- Escolhemos VictoriaMetrics para nós mesmos.
- Ele escala muito bem tanto vertical quanto horizontalmente.
- Podemos distribuir diferentes componentes para diferentes números de nós no cluster, limitá-los por memória, adicionar memória, etc.
Usaremos VictoriaMetrics em casa porque gostamos muito. Isto é o que foi e o que se tornou.
Alguns códigos QR para bate-papo VictoriaMetrics, meus contatos, radar técnico LeroyMerlin.
Fonte: habr.com