Monitoramento com Prometheus, Grafana, AlertManager e VictoriaMetrics

Autores: Aécio Pires, Alan Santos e Gabriel Monteiro.

Introdução

O monitoramento de aplicações é um grande desafio, portanto, várias ferramentas são utilizadas para fornecer controle de alto nível às equipes envolvidas no controle e análise de dados. Considerando isso e trazendo um pouco da experiência da Sensedia, podemos mencionar os seguintes sistemas que podem auxiliar no monitoramento das aplicações e serviços de uma empresa:

- Prometheus: um sistema de coleta de métricas de aplicações e serviços para armazenamento em um banco de dados de séries temporais. É muito eficiente.

- AlertManager: trabalha de forma integrada com a Prometheus para avaliar regras de alerta e enviar notificações por e-mail, Jira, Slack, e outros sistemas suportados.

- Grafana: uma solução de análise e observabilidade que suporta vários sistemas de coleta de toras e métricas. Quando integrada ao Prometheus, serve para exibir métricas em painéis muito elegantes e úteis para diferentes áreas de uma empresa/organização.

- Prometheus-Operator: software para simplificar e automatizar a instalação e configuração do Prometheus, AlertManager, Grafana e exportadores nos clusters de Kubernetes.

- VictoriaMetrics: uma solução rápida, econômica e escalável de banco de dados e monitoramento de séries temporais. Mas em nosso caso, ela é usada para armazenamento centralizado e de longo prazo das métricas coletadas por diferentes servidores Prometheis (o plural da Prometheus).

Todas estas ferramentas são de código aberto e estão disponíveis no Github.

No tutorial anterior, aprendemos como criar um cluster Kubernetes na AWS usando o Terraform. Você pode criar o cluster e instalar o Prometheus-Operator seguindo o tutorial que está disponível no repositório sensedia/open-tools . Se você não sabe o que é o Prometheus-Operator, recomendo vivamente que assista a esta palestra apresentada por Daniel Requena durante a StayAtHomeConf e/ou veja os links que estão nas referências.

Qual é a vantagem de usar essas ferramentas?

Podemos destacar várias vantagens de usar essas ferramentas para aumentar o controle de dados. Como estamos olhando muito para a Open Finance este ano, podemos falar um pouco sobre como estas ferramentas podem ajudar a trazer controle e governança sobre os processos bancários.

Quando você integra seu software com as APIs do banco, você abre uma gama de possibilidades, mas e quanto ao controle de tudo isso? Como monitorar se os serviços que suportam essas interações estão funcionando corretamente? A resposta a estas perguntas é o monitoramento, que pode ser feito usando o Prometheus, AlertManager, Grafana e outros sistemas.

Ao ter um monitoramento eficaz, você pode:

1. Ter mais agilidade na solução de problemas;
2. Identificar instabilidades e picos de transação de alto volume;
3. Maior controle de dados.

E estes são alguns dos muitos benefícios que o rastreamento de dados pode trazer ao seu negócio.

Como utilizamos estas ferramentas?

Nosso ambiente de produção é multi-nuvem e temos vários clusters Kubernetes distribuídos em AWS e GCP. É lá que executamos as aplicações e serviços utilizados pelos clientes.

Basicamente, em cada cluster Kubernetes, o prometheus-operator é instalado para gerenciar apenas o prometheus e os exportadores necessários para coletar as métricas. Em vez de instalar Grafana e Alertmanager em cada cluster, optamos por instalar estes serviços em um único cluster.

Todas as métricas coletadas pela Prometheis são enviadas à VictoriaMetrics, que centraliza seu armazenamento e consultas. Por padrão, a Prometheus-Operator armazena as métricas localmente por apenas 2 horas. Com a VictoriaMetrics podemos armazenar todas as métricas de toda a Prometheis por um longo período de tempo.

O Grafana é então configurado para conectar-se à VictoriaMetrics para consultar e exibir as métricas. Com relação aos alertas, todos os Prometheis enviam para um AlertManager pool. Assim, podemos garantir a disponibilidade e a centralização das métricas e alertas. Vale mencionar que todos os dados são transmitidos de forma criptografada e o acesso aos dados é feito através de autenticação e a partir de IPs de fonte autorizada.

VictoriaMetrics

Esta ferramenta merece atenção especial, e explicaremos o motivo abaixo.

De janeiro a outubro de 2020, utilizamos o InfluxDB como solução de armazenamento para as métricas de longo prazo da Prometheis. Mas começamos a ter sérios problemas no armazenamento e visualização das métricas diante da crescente demanda por coleta de novas métricas. Isto não significa que o InfluxDB seja uma má solução, pelo contrário, ele nos serviu muito bem por muito tempo, mas após uma extensa pesquisa, ajustes nos arquivos de configuração e um aumento considerável nos recursos de CPU e memória, vimos que executar o InfluxDB sem usar o modo cluster (que é pago) não estava nos servindo bem.

Então, decidimos fazer uma busca por soluções alternativas e entre elas estavam

-Thanos;

-Cortex;

-ElasticSearch;

-TimeScaleDB;

- M3DB;

-VictoriaMetrics.

Após análise detalhada de cada solução, conversas com amigos e colegas que já utilizavam algumas delas em outros ambientes, além de refletir sobre as necessidades comerciais e o retorno do investimento que cada um acrescentaria, optamos pela VictoriaMetrics.

Os fatores-chave para tomar esta decisão foram:

- A simplicidade de instalação e configuração, após comparação com outras ferramentas;

- Não foi necessário refazer os painéis na Grafana, pois a VictoriaMetrics suporta a PromQL;

- Não foi necessário ter um Prometheus somente de leitura (isto é, usando o API de leitura remota, intermediando a comunicação entre a Grafana e a VictoriaMetrics);

- Pouco uso de recursos de CPU e memória para armazenar e processar um alto volume de métricas. Isto tem sido observado em alguns casos de uso em ambientes de produção de empresas globalmente relevantes. Veja a página: https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/CaseStudies;

- Benchmark com resultados positivos em comparação com outras soluções, feito por uma pessoa que trabalha na Addidas e em um ambiente com um alto volume de métricas.

Fizemos um PoC usando VictoriaMetrics (modo cluster) durante Black Friday (o período do ano em que ocorre o maior volume de geração de métricas de acordo com a demanda e o modelo de negócios de nossos clientes). Durante este período, não tivemos problemas para monitorar a pilha e ela tem permanecido assim desde então. Antes, tínhamos problemas recorrentes de monitoramento da pilha quase todos os dias. Isso não afetou o ambiente de produção do cliente, mas exigiu um bom tempo das equipes operacionais durante a solução de problemas.

Em modo cluster, a VictoriaMetrics consiste nos seguintes componentes:

- vmstorage: armazena métricas em um volume persistente. Em nosso caso, os dados são armazenados em discos EBS;

- vmselect: utilizado para a leitura/conquista de métricas. Ele recebe os pedidos de leitura, interage com o vmstorage para obter acesso a eles e depois envia os dados solicitados.

- vminsert: utilizado para a escrita de métricas. Ele recebe os pedidos de escrita e os passa para o vmstorage para armazenamento;

- vmauth: é um simples proxy de autenticação que redireciona os pedidos de leitura/escrita para vmselect/vminsert. Ele valida o nome de usuário e a senha para os cabeçalhos do Basic Auth, compara-os com as configurações de redirecionamento definidas e atua como um proxy para solicitações HTTP.

Sobre os números

- 28 Prometheis (um para cada agrupamento) enviando métricas para a VictoriaMetrics;

- 2 cápsulas para o componente vmselect

o CPU: 500 milicores no mínimo e 1 CPU no máximo

o Memória: 500 MB mínimo e 3 GB máximo

Volume: 8 GB

- 2 cápsulas para o componente vminsert

o CPU: 500 milicores no mínimo e 1 CPU no máximo

o Memória: 500 MB mínimo e 3 GB máximo

Volume: 8 GB

- 2 cápsulas para os componentes do vmstorage:

o CPU: 500 milicores no mínimo e 1 CPU no máximo

o Memória: 500 MB mínimo e 4 GB máximo

Volume: 1 TB

- 2 cápsulas para o componente vmauth

o CPU: 200 milicores no mínimo e 1 CPU no máximo

o Memória: 128 MB mínimo e 1 GB máximo

- 2 Balanceadores de carga para ALB (Application Load Balancer) tipo vmauth:

o 1 tipo interno para receber as métricas Prometheis que estão no mesmo VPC da VictoriaMetrics;

o 1 tipo voltado para a Internet para receber métricas de outros Prometheis que estão em outros VPCs ou em outro Provedor de Nuvens.

- Série de Tempo Ativo: 2,3 Milhões

- Utilização do espaço em disco: 67 GB (as métricas são giradas a cada 15 dias)

- Taxa de Ingestão: 40,1 K pontos/segundo

- Taxa de solicitações: 134 req/segundo

- Total de Datapoints: 90,3 bilhões (as métricas são giradas a cada 15 dias)

- Utilização da rede:

o 20 Mbps usados apenas para receber métricas de todos os Prometheis.

o 70 Kbps utilizados somente para a verificação de métricas através da Grafana.

Durante as atividades de migração para VictoriaMetrics, também tivemos que desenvolver a Carta do Leme para o componente vmauth. O código para este Helm Chart foi compartilhado no repositório oficial da VictoriaMetrics e também ajudamos a organizar a documentação de outros Helm Charts usando helm-docs. Esta foi uma maneira simples de retribuir e agradecer à comunidade de código aberto.

Se você estiver interessado em fazer um teste com a VictoriaMetrics nos clusters da Kubernetes, recomendamos o uso de Helm Charts que estão disponíveis em: https://github.com/VictoriaMetrics/helm-charts. Para maiores informações, acesse os links que se encontram nas referências.

Há vários painéis disponíveis no site da Grafana para visualizar as métricas internas da VictoriaMetrics, mas recomendamos o uso deste: https://grafana.com/grafana/dashboards/11831.

Considerações finais

Neste tutorial, aprendemos mais sobre um conjunto de ferramentas utilizadas para serviços e aplicações de monitoramento e descobrimos uma solução que pode ser utilizada para o armazenamento centralizado e de longo prazo das métricas coletadas pela Prometheus.

‍