APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um alerta deve indicar uma condição que merece ação e oferecer contexto para a decisão. Define serviço, janela, população e resultado antes de escolher o limiar. Para um SLO de 99,9%, a fração permitida de eventos maus é 0,1%. Se a fração observada for 0,5%, o burn rate é cinco: o orçamento é consumido a cinco vezes a taxa sustentável nessa interpretação. Este cálculo não diz sozinho em quanto tempo o orçamento restante acaba; precisas do período, consumo acumulado e evolução. Janelas longas e curtas em conjunto ajudam a detetar consumo relevante e a reconhecer recuperação. Os valores de exemplo em documentação não são limiares universais para serviços com tráfego e consequências diferentes.
Aplicação guiada
Em Prometheus, for mantém o alerta pending até a expressão permanecer ativa durante o intervalo definido. Não significa esperar esse tempo depois de recuperar. Acrescenta contexto e runbook nas annotations. Alertmanager pode agrupar notificações, inibir alertas quando outro está ativo e silenciar notificações correspondentes durante um intervalo. Estas funções reduzem ruído; não corrigem a falha. No caso fictício de manutenção, um silence demasiado amplo pode esconder um incidente não relacionado. Revê matchers, prazo e responsável. Em baixo volume, uma falha entre poucos pedidos produz uma percentagem elevada: interpreta volume e impacto em conjunto. Para batch diário, atraso desde o último sucesso pode ser mais acionável que um alerta baseado apenas em tráfego HTTP.
0,5% de erros perante 0,1% permitido corresponde a burn rate 5.
Armadilhas comuns
Limiar universal; silence como resolução; for como atraso após recuperar; percentagem sem volume.
Tópicos relacionados: Sinais e resultados do serviço · Métricas e consultas · Traces e contexto
Notifica com impacto, contexto e uma ação clara.
Referência: SLO burn-rate alerting and traffic limitations · Observability 2026-09; selected OpenTelemetry, Prometheus and Dynatrace Classic concepts