Engenharia de alertas: burn rate multijanela e revisão do plantão

Esta aula transforma a ideia de alerta acionável em uma política verificável. O objetivo não é silenciar sintomas, mas chamar alguém apenas quando há uma decisão urgente. Para cada regra, escreva impacto, responsável, ação inicial e canal; sem esses itens, severity: critical é apenas um rótulo.

Considere SLO de disponibilidade de 99,9% em 30 dias, medido por requisições. A fração de falha permitida é 0.001; o burn rate é a proporção observada de erros dividida por esse valor. Assim, 1,44% de erros corresponde a 14.4 vezes a taxa permitida.

A janela longa acumula evidência de impacto; a curta confirma que o problema continua acontecendo. Exigir burn rate acima de 14.4 tanto em uma hora quanto em cinco minutos reduz páginas causadas por uma falha antiga que já cessou. O operador and on(service) combina séries da mesma dimensão.

O limiar tem uma interpretação de orçamento: mantendo o mesmo perfil de tráfego, 14.4 × 1h / 720h representa aproximadamente 2% do orçamento de 30 dias. Para SLO por requisições, o consumo real depende da distribuição do tráfego; valide também contagens acumuladas, em vez de converter tudo automaticamente em minutos.

O bloco usa o contador de histograma já instrumentado, http_request_duration_seconds_count, e pressupõe a label service. As regras de gravação calculam proporções por serviço. Se a sua instrumentação não expõe essa label, adicione-a de forma consistente ou adapte a agregação antes de copiar a regra.

Sem tráfego não significa 100% de disponibilidade. A divisão pode gerar NaN, e ausência de coleta pode eliminar séries; não force zero com um preenchimento que esconda falhas. Monitore scrape e disponibilidade do pipeline separadamente e use uma sonda sintética quando a jornada precisar de validação mesmo sem usuários.

Paginação e ticket têm urgências diferentes. A queima rápida pode chamar o plantão; uma degradação lenta e persistente pode gerar trabalho para o horário útil, conforme a política acordada. for: 2m adiciona persistência, mas também atraso: avalie esse custo no tempo de detecção.

Por fim, faça uma revisão semanal de ruído: quantas notificações exigiram ação, quais duplicaram outras e quais chegaram tarde? Teste regras com promtool, simule recuperação e confira roteamento no Alertmanager. Só ajuste limites após comparar impacto e evidência; reduzir páginas às cegas pode ocultar incidentes.