Alertas (Alertmanager, PagerDuty, Opsgenie)

Alertas são o mecanismo que transforma telemetria em ação humana no momento certo, notificando pessoas ou automações quando o comportamento do sistema sai do padrão aceitável. Em produção, eles são a última linha de defesa da observabilidade: painéis e traces ajudam a investigar, mas é o alerta que inicia a resposta. O Alertmanager é o componente de referência da stack Prometheus para deduplicar, agrupar, rotear e silenciar notificações, enquanto PagerDuty e Opsgenie são plataformas de gerenciamento de incidentes que cuidam de escalonamento, on-call schedules e integrações com canais de comunicação. A qualidade de um sistema de alertas se mede por duas taxas opostas: a de incidentes detectados tarde demais, que indica cobertura insuficiente, e a de alertas ignorados por fadiga, que indica ruído excessivo. Acertar esse equilíbrio é uma das disciplinas mais difíceis e mais importantes da operação de software.

O problema que os alertas resolvem

Ninguém consegue olhar painéis 24 horas por dia, e muitos sintomas críticos aparecem em janelas de baixo tráfego, quando qualquer degradação pode passar despercebida por horas. O alerta automatiza essa vigilância contínua, aplicando regras determinísticas sobre métricas, logs e traces, e aciona o time apenas quando o desvio importa. Ele também padroniza a triagem: um bom alerta chega ao on-call com contexto suficiente para orientar a primeira ação, em vez de apenas anunciar que algo está estranho. Sem essa camada, o incidente só aparece por reclamação de cliente, o que custa reputação e receita; com excesso de alertas, aparece o problema inverso, o time desenvolve tolerância ao ruído e ignora até os avisos verdadeiros.

Regras de alerta

No ecossistema Prometheus, as regras de alerta são expressões PromQL avaliadas periodicamente que produzem alertas quando a condição permanece verdadeira pela duração configurada. A duração evita alertas por picos momentâneos, e as labels do resultado alimentam todo o roteamento posterior. O exemplo abaixo demonstra o padrão recomendado.

groups:
  - name: checkout-api-sintomas
    rules:
      # Alerta de sintoma: latência p99 acima de 300 ms por 10 minutos
      - alert: CheckoutLatenciaP99Alta
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{job="checkout-api"}[5m]))
            by (le)) > 0.3
        for: 10m          # Persistência exigida para disparar
        labels:
          severity: critical
          service: checkout-api
        annotations:
          summary: "p99 do checkout acima de 300 ms"
          description: "Latência p99 de {{ $value }}s por mais de 10 minutos"
          runbook_url: "https://runbooks.interno/checkout/latencia-p99"

Três detalhes separam regras maduras de regras improvisadas: a condição mede sintoma percebido pelo usuário, como latência e taxa de erro, e não apenas causa interna; os annotations carregam contexto, incluindo o link do runbook, obrigatório em alertas que acionam humanos; e a label service padroniza o roteamento e a agregação no Alertmanager. Regras devem ser tratadas como código versionado, avaliadas em revisão com o mesmo rigor de uma mudança de aplicação, porque um limiar errado custa tanto quanto um bug de produção.

Agrupamento, silenciamento e inibição

Quando uma falha de infraestrutura derruba cinquenta serviços, o problema não é detectar, é não receber cem notificações idênticas. O Alertmanager resolve isso com três mecanismos complementares. O agrupamento colapsa alertas semelhantes em uma única notificação, configurável por chaves como serviço e severidade. O silenciamento suprime notificações por janela de tempo combinada, essencial durante manutenções planejadas, e deve sempre documentar quem silenciou, o motivo e quando expira. A inibição suprime alertas filhos quando um alerta pai mais amplo já está ativo, por exemplo calando alertas de instância quando o alerta de região inteira já disparou.

# Configuração do Alertmanager: roteamento, agrupamento e inibição
route:
  receiver: slack-baixo-custo     # Rota padrão para ruído aceitável
  group_by: [service, severity]
  group_wait: 30s                 # Espera coletar alertas vizinhos
  group_interval: 5m              # Intervalo entre notificações do grupo
  repeat_interval: 4h             # Reenvia o alerta não resolvido
  routes:
    - matchers: [severity="critical"]
      receiver: pagerduty-critico # Críticos acionam o on-call imediato
      continue: false
    - matchers: [team="pagamentos"]
      receiver: slack-pagamentos
inhibit_rules:
  # Inibe alertas de instância quando o serviço inteiro está fora
  - source_matchers: [alertname="ServicoIndisponivel"]
    target_matchers: [severity="warning"]
    equal: [service]

Essa configuração encarna uma política clara: críticos pagam o custo de acordar alguém, avisos ficam em canal assíncrono e ruído repetitivo é reenviado em intervalos longos. Ajustar group_wait e repeat_interval é um exercício contínuo de calibração com o time de on-call.

Ciclo de vida de um alerta

Um alerta passa por estados que precisam ser entendidos para calibrar cada parâmetro. Ele nasce quando a regra fica verdadeira, entra em estado pending durante a janela for, vira firing ao completar a janela e retorna ao normal quando a condição deixa de valer. A notificação, por sua vez, tem seu próprio ciclo no Alertmanager e nas plataformas de incidente: disparada, entregue, reconhecida pelo on-call e resolvida, manualmente ou pela condição de origem. Reconhecer sem resolver é um passo importante do fluxo, porque marca que uma pessoa assumiu o incidente e o escalonamento deve pausar. Erros de configuração nesse ciclo geram os dois sintomas clássicos de ruído: alertas que disparam e se resolvem em minutos, os chamados flapping, e alertas resolvidos que continuam sendo reenviados por intervalos mal calibrados.

Entender esse ciclo também define onde cada ferramenta atua. O Prometheus e o Alertmanager gerenciam a detecção e o encaminhamento; a plataforma de incidentes gerencia o reconhecimento, o escalonamento e o registro histórico. Times que tentam fazer o Alertmanager assumir o papel de plataforma de incidentes completam o ciclo com planilhas e memória humana, o que não escala para equipes com múltiplos on-calls e dezenas de serviços.

Sintoma versus causa

A distinção mais importante em engenharia de alertas é entre alertar sobre sintomas, o que o usuário percebe, e alertar sobre causas, o que provavelmente o provocou. Alertas de sintoma, como taxa de erro, latência e disponibilidade do endpoint, são sempre acionáveis e devem chegar ao humano. Alertas de causa, como utilização de CPU acima de 80 por cento, espaço em disco em 70 por cento e conexões de banco em crescimento, quase sempre já têm resposta automatizada, seja auto scaling, seja cleanup, e viram notificação quando alguém precisa decidir algo sobre eles. A regra prática: todo alerta que acorda alguém precisa ser algo que exija julgamento humano agora; o restante vira ticket, automação ou apenas sinal em painel. Times que invertem essa proporção acumulam fadiga e perdem a capacidade de resposta nos incidentes reais.

Alert fatigue e calibração

Fadiga de alerta é o processo pelo qual notificações excessivas treinam o time a ignorar o canal, e ela se instala silenciosamente: cada alerta ignorado aumenta o limiar de atenção do próximo. Os sinais clássicos são alertas acionados e fechados automaticamente sem ação, alertas que disparam fora do horário comercial e ninguém comenta, e a frase recorrente de "é sempre esse alarme". O tratamento é um processo de qualidade contínua, com três práticas consolidadas.

• Revisão periódica do acervo, removendo ou reclassificando alertas sem acionamento útil nos últimos meses, tratando cada alerta como software que envelhece.
• Métricas de qualidade do sistema de alertas, como proporção de alertas acionados e resolvidos com ação humana, publicadas e discutidas em retrospectivas de incidente.
• Automação de primeira resposta, para que causas conhecidas sejam mitigadas por runbooks automatizados antes de se tornarem alertas humanos.

O resultado esperado dessa calibração é um canal de alertas tratado como produto, com backlog de melhoria, indicadores de qualidade e dono responsável. Times que alcançam esse patamar relatam uma mudança cultural perceptível: o disparo de um alerta crítico volta a significar emergência real, e o tempo de reconhecimento cai porque o on-call confia no que chega.

PagerDuty e Opsgenie como camada de incidentes

Enquanto o Alertmanager decide o que notificar, PagerDuty e Opsgenie decidem quem e como, gerenciando escalonamento, agendas de on-call, reconhecimento de incidentes e integrações com Slack, Teams e teleconferência. O escalonamento é o recurso central: se o primeiro respondente não reconhece em cinco minutos, a notificação sobe para o próximo nível, o que garante cobertura em madrugadas e feriados. As duas plataformas expõem APIs e eventos que permitem enriquecer alertas com runbooks, serviços afetados e links de diagnóstico, funcionando como registro único do histórico de incidentes de um time.

Na prática, a combinação mais comum é Alertmanager para roteamento fino de dezenas de alertas com poucas rotas finais, e PagerDuty ou Opsgenie recebendo apenas o fluxo que exige resposta humana imediata. Essa separação de papéis evita o anti-padrão de transformar a plataforma de incidente em sumidouro de avisos informativos, que deveriam parar em canal assíncrono.

SLO e error budget como fonte de alertas

Alertas derivados de SLO substituem a pergunta "a métrica passou de um limiar" por "estamos gastando o orçamento de erro mais rápido do que o objetivo permite". Essa abordagem, conhecida como burn rate, dispara quando o consumo recente do error budget indica que, mantido o ritmo atual, o objetivo de período será violado. A vantagem é dupla: alertas ficam proporcionalmente sensíveis ao tráfego, funcionando igualmente bem de madrugada com pouco tráfego, e a severidade passa a ter significado de negócio, porque um alerta crítico representa ameaça real ao compromisso com o cliente. Um esquema típico combina um alerta rápido para burn rate alto em janela de uma hora, indicando incidente em andamento, com um alerta lento em janela de seis horas, indicando degradação sustentada que também consumiria o orçamento.

Vale registrar que esse modelo também disciplina o orçamento de engenharia: quando o error budget de um serviço se esgota, o burn rate permanece elevado e os alertas continuam disparando até que qualidade seja restaurada. Essa pressão contínua é deliberada, transformando a conversa sobre confiabilidade em decisão objetiva de priorização de backlog.

Erros comuns

Os equívocos abaixo alimentam a fadiga e reduzem a confiança no canal de alertas.

• Alertar sobre métricas de causa, como CPU e memória, com severidade crítica, acionando humanos para problemas que auto scaling já resolveria.
• Ausência de runbook no alerta, deixando o on-call descobrir o diagnóstico durante o incidente, sob pressão.
• Limiares fixos que não acompanham o crescimento do tráfego, gerando flapping quando o sistema opera próximo do valor definido.
• Silenciamentos permanentes e sem dono, que escondem alertas ativos até que o sintoma chegue ao usuário.
• Roteamento para canal coletivo, como um canal de Slack de todos, onde ninguém se sente responsável pela resposta.
• Notificações sem template padronizado, obrigando o respondente a decifrar expressões cruas em vez de ler um resumo acionável.

Boas práticas

As práticas abaixo consolidam um sistema de alertas que o time respeita e usa.

• Reserve severidade crítica para sintomas com impacto de usuário e exigência de resposta imediata, com runbook obrigatório e rota para o on-call.
• Implemente alertas de burn rate sobre SLOs como padrão para serviços críticos, complementando limiares absolutos apenas onde não há orçamento definido.
• Use agrupamento por serviço e severidade, com group_wait calibrado em conjunto com o time de on-call, e revise o parâmetro a cada incidente relevante.
• Mantenha todo silenciamento com prazo, motivo e autor registrados, e audite silenciamentos vencidos em reunião operacional semanal.
• Faça game days periódicos disparando alertas em ambiente controlado, validando runbooks, rotas e tempo de reconhecimento de ponta a ponta.
• Versione regras e rotas de alerta em repositório, submetendo qualquer alerta novo à mesma revisão de código aplicada a qualquer mudança de produção.
• Defina metas operacionais para o próprio canal, como tempo médio de reconhecimento e proporção de alertas críticos legítimos, revisadas em retrospectivas.
• Mantenha um alerta de ausência de dados para serviços críticos, porque telemetria que para de chegar é falha tão grave quanto sintoma disparado.