Alertas que não viram ruído

Um alerta que dispara sem exigir ação treina o time a ignorar alertas — inclusive o que importava. Fadiga de alerta não é falta de disciplina de quem está de plantão; é defeito de projeto do conjunto de regras. A correção é reduzir a quantidade e aumentar a qualidade, nunca o contrário.

Todo alerta precisa de uma ação

Antes de criar a regra, responda três perguntas. Se qualquer uma falhar, aquilo é painel, não alerta:

1. Alguém precisa fazer algo agora? Se a resposta é “olhar amanhã”, vire relatório.
2. O que essa pessoa faz? Se não há runbook, o alerta ainda não está pronto.
3. O usuário está sendo afetado, ou vai estar em breve? Se não, não é página.

Só existem dois destinos legítimos: página (acorda alguém) e ticket (entra na fila de trabalho). Alerta em canal de chat que ninguém lê é a forma mais comum de esconder um problema achando que o registrou.

Sintoma, não causa

Alerte sobre o que o usuário sente: erro, latência, indisponibilidade, fila que não anda. Causas — CPU alta, memória, disco em 80%, Pod reiniciando — vão para o painel e para o diagnóstico, porque quase sempre acontecem sem impacto nenhum.

# Sintoma: o checkout está falhando para as pessoas.
sum(rate(http_requests_total{route="/checkout", status=~"5.."}[5m]))
  / sum(rate(http_requests_total{route="/checkout"}[5m])) > 0.02

As exceções legítimas de causa são as preditivas com prazo: disco que, na taxa atual, enche em quatro horas, ou certificado que expira em uma semana. Elas alertam cedo porque a correção demora.

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*3600) < 0

Alertas por taxa de consumo do orçamento de erro

O melhor alerta de serviço não usa um limiar arbitrário: ele usa a velocidade com que o serviço está gastando o orçamento de erro do SLO. Duas janelas evitam tanto o falso positivo de um pico curto quanto a demora de uma janela longa.

groups:
  - name: slo-checkout
    rules:
      # Queima rápida: 14,4x o orçamento — em 2h consome 2% do mês. Página.
      - alert: CheckoutBurnRateAlta
        expr: |
          (slo:erro:ratio_rate5m{route="/checkout"} > 14.4 * 0.001)
            and (slo:erro:ratio_rate1h{route="/checkout"} > 14.4 * 0.001)
        for: 2m
        labels: { severity: page }
        annotations:
          summary: "Checkout queimando orçamento de erro 14x acima do previsto"
          runbook: "https://portal.exemplo.com/guias/observabilidade/alerta-por-burn-rate/"

      # Queima lenta: degradação persistente. Ticket, não madrugada.
      - alert: CheckoutBurnRateLenta
        expr: |
          (slo:erro:ratio_rate6h{route="/checkout"} > 6 * 0.001)
            and (slo:erro:ratio_rate3d{route="/checkout"} > 6 * 0.001)
        for: 30m
        labels: { severity: ticket }

O 0.001 é o orçamento (SLO de 99,9%). Substitua pelo seu, e pré-calcule as taxas com recording rules: alerta que depende de consulta pesada falha quando o Prometheus está sob pressão — ou seja, no incidente.

for: existe para engolir pico transitório; sem ele, uma coleta perdida vira página.

Agrupamento, silenciamento e inibição

Um nó com problema pode gerar quarenta alertas. O Alertmanager transforma isso em uma notificação:

route:
  group_by: [alertname, cluster, namespace]
  group_wait: 30s          # espere irmãos antes de mandar a primeira
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: plantao
    - matchers: [severity="ticket"]
      receiver: fila-do-time

inhibit_rules:
  # Se o cluster inteiro caiu, não notifique cada serviço individualmente.
  - source_matchers: [alertname="ClusterIndisponivel"]
    target_matchers: [severity="page"]
    equal: [cluster]

Silenciamento é ferramenta legítima durante manutenção — desde que tenha prazo. Silêncio permanente é um alerta que deveria ter sido apagado; apague-o de verdade, no Git, com a razão no commit.

Meça a qualidade dos seus alertas

Alertas são código e merecem revisão periódica com dados:

topk(10, sum by (alertname) (count_over_time(ALERTS{alertstate="firing"}[7d])))

Leve para a retrospectiva: quantos dispararam, quantos exigiram ação, quantos foram silenciados na hora, e quantos incidentes reais não tiveram alerta. Alerta que dispara toda semana e nunca gera ação é candidato a remoção — remover é uma melhoria, não uma derrota. E teste as regras no CI, como qualquer outro código:

promtool test rules testes/slo-checkout.yaml

Próximo passo: você fechou a trilha de Observabilidade. Ligue esses alertas a objetivos explícitos em SLO na prática e monte a regra completa no guia Alerta por burn rate.