Monitoramento de métricas e alertas

01 · CONTEXTO E REQUISITOS

O que uma plataforma de métricas precisa fazer

Uma plataforma de monitoramento de métricas coleta dados de desempenho de servidores e serviços, guarda tudo como séries temporais, mostra em painéis e dispara alertas quando limites são ultrapassados. Datadog, Prometheus com Grafana e CloudWatch são exemplos conhecidos.

Os requisitos funcionais são quatro: ingerir métricas dos serviços; consultar e visualizar em painéis, com filtros, agregações e intervalos de tempo; definir regras de alerta com limites sobre janelas de tempo; e notificar quem precisa por e-mail, Slack ou PagerDuty.

Ficam fora do escopo a busca e a agregação de logs, o rastreamento distribuído e a detecção de anomalias por aprendizado de máquina. Cada um é um problema à parte.

02 · ESTIMATIVA DE ESCALA

Cinco milhões de pontos por segundo

A Hello Interview propõe monitorar 500 mil servidores. Se cada um emite 100 pontos de métrica a cada 10 segundos, o pico é de 5 milhões de pontos por segundo. Cada ponto é pequeno (carimbo de tempo, valor e rótulos), algo entre 100 e 200 bytes, mas nesse volume a ingestão bruta chega a cerca de 1 GB por segundo.

Os outros requisitos não funcionais puxam em direções diferentes. Painéis devem responder em segundos, mesmo sobre dias ou semanas. Alertas devem ser avaliados em menos de um minuto entre a emissão da métrica e o disparo. O sistema deve ficar disponível, tolerando consistência eventual nos painéis, mas com avaliação de alertas confiável. E dados atrasados ou fora de ordem precisam ser tratados com tolerância.

Menos de um minuto parece lento para alertas, mas em geral só se enxerga um evento depois de acumular dados suficientes, e por isso os alertas costumam usar médias móveis ou tendências.

03 · DESENHO INICIAL

Coletar, guardar, consultar

Comece pelo caminho mais simples: um coletor recebe os pontos e grava num banco de séries temporais, e um serviço de consulta lê esse banco para os painéis.

1. Os serviços monitorados entregam seus pontos ao coletor, que os recebe ou os raspa.

2. O coletor grava cada ponto no banco de séries temporais, com carimbo de tempo, valor e rótulos.

3. Quem abre um painel faz uma consulta com filtros, agregação e intervalo de tempo; o serviço de consulta a recebe.

4. O serviço de consulta lê as séries do intervalo pedido e devolve o resultado já agregado.

O modelo de dados é o de séries temporais: cada métrica é guardada com o instante em que foi registrada e com rótulos de chave e valor. É o modelo do Prometheus, que serve de referência aqui.

Há dois jeitos de coletar. No modelo pull, o servidor de monitoramento raspa os alvos por HTTP, e os alvos são descobertos por service discovery ou por configuração estática. O push também existe: o Prometheus o suporta por meio de um gateway intermediário.

04 · INGESTÃO E ARMAZENAMENTO

Absorver picos sem perder pontos

Garantir alta disponibilidade durante picos e falhas é um dos aprofundamentos que a Hello Interview lista para este problema.

O desenho inicial grava direto do coletor no banco, e por isso um pico ou uma falha do banco chega direto à ingestão. Uma fila entre os dois desacopla as duas pontas.

1. Os pontos chegam ao balanceador, que os espalha entre várias instâncias do coletor.

2. O coletor valida o ponto e o publica na fila, sem esperar a gravação terminar.

3. Os gravadores consomem a fila em lotes, no ritmo que o banco aguenta.

4. Cada lote é gravado no banco de séries temporais, com o carimbo de tempo do próprio ponto.

5. Se o banco ficar indisponível por um tempo, a fila acumula os pontos e os coletores seguem aceitando dados; os gravadores retomam quando o banco volta.

A fila troca um pouco de latência por folga: ela desacopla quem recebe de quem grava e dá tempo para reprocessar. Como o carimbo de tempo vem do ponto e não do momento da chegada, um ponto atrasado ainda cai no lugar certo da série. O custo é que a fila entra no orçamento de latência dos alertas.

O maior perigo para o armazenamento são os rótulos. Cada combinação única de rótulos é uma nova série e pode aumentar muito os dados guardados, e por isso a documentação do Prometheus manda não usar rótulos para dimensões de alta cardinalidade, como IDs de usuário. A Hello Interview também lista a explosão de cardinalidade como aprofundamento.

Quanto ao banco, o Prometheus é um bom exemplo de como um banco de séries temporais lida com escrita contínua: as amostras ingeridas são agrupadas em blocos de duas horas, o bloco atual fica em memória e é protegido por um write-ahead log, e os blocos iniciais são compactados em segundo plano em blocos maiores.

Para painéis sobre semanas de dados, o servidor também pode executar regras que agregam e gravam novas séries a partir das existentes. A Hello Interview trata consultas de baixa latência sobre semanas de dados como um dos aprofundamentos.

Isso sugere pré-agregar: guardar, além dos pontos brutos, versões resumidas por intervalos maiores, e deixar os painéis longos lerem as resumidas. Em troca de mais armazenamento, a consulta deixa de varrer os pontos brutos.

05 · ALERTAS

Da regra à notificação

Uma regra de alerta é uma condição sobre uma janela de tempo. O exemplo da Hello Interview é alertar se a latência p99 passar de 500 ms por 5 minutos. No Prometheus, a cláusula for faz o servidor esperar uma duração antes de contar o alerta como disparado, e o alerta que já está ativo, mas ainda não disparou, fica no estado pendente. Já keep_firing_for mantém o alerta ativo por um tempo depois que a condição deixa de valer, para evitar alertas oscilantes.

1. O avaliador carrega as regras de alerta: o limite, a janela e quem deve ser avisado.

2. A cada ciclo, o avaliador consulta no banco as séries da janela de cada regra.

3. Quando a condição é verdadeira, o alerta fica pendente e só dispara se ela se mantiver pelo tempo exigido.

4. Confirmado o disparo, o avaliador entrega o alerta ao notificador, que agrupa e elimina duplicatas.

5. O notificador avisa a pessoa de plantão pelo canal configurado, como e-mail, Slack ou PagerDuty.

O Alertmanager do Prometheus é uma referência para a última etapa: ele deduplica, agrupa e roteia os alertas. O agrupamento reúne alertas parecidos numa só notificação, o que importa numa falha grande, quando muitos alertas disparam juntos. A inibição suprime notificações de alguns alertas quando outros já estão disparando.

Reduzir a latência de alerta abaixo de um minuto é outro aprofundamento da Hello Interview. A própria fonte observa que, quando se quer disparar o mais cedo possível, o alerta costuma ser construído de um jeito particular.

06 · LIMITES E EVOLUÇÃO

O que ficou de fora

A replicação multirregião ficou fora do escopo por adicionar complexidade.

Se o produto crescer, a multirregião é um próximo passo natural, junto de mais camadas de resumo para consultas longas. Também vale monitorar o próprio monitoramento, e não o fazer depender dos mesmos componentes que ele vigia.

Outro limite: para precisão total, como cobrança por requisição, o Prometheus não é uma boa escolha. Métricas de monitoramento servem para entender a saúde do sistema, não para faturar.