System Design/03 - Qualidade/Monitoring2 min
Visualization & Alerts
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
A camada onde os sinais viram decisão humana: painéis para ver, alertas para agir.
Níveis de painel
| Nível | Público | Conteúdo |
|---|---|---|
| Visão geral | Todos | Os quatro sinais dourados, saúde geral |
| Por serviço | Time dono | RED do serviço, dependências |
| Profundidade | Quem está depurando | Métricas internas, filas, pools |
| Negócio | Produto | Pedidos, receita, conversão |
Painel útil responde uma pergunta específica. Painel com 60 gráficos não responde nenhuma — ninguém consegue olhar para tudo durante um incidente.
Alertar por sintoma, não por causa
| Ruim (causa) | Bom (sintoma) |
|---|---|
| CPU > 80% | Latência p99 > 2 s |
| Memória > 90% | Taxa de erro > 1% |
| Disco em 75% | Disco cheio em < 4 h (projeção) |
CPU a 85% pode ser eficiência, não problema. O que importa é se o usuário está sendo prejudicado. A exceção são sinais preditivos — saturação e projeção de esgotamento — que valem alerta justamente por darem tempo de agir.
SLI, SLO e error budget
- SLI: o que se mede (latência p99, taxa de sucesso)
- SLO: a meta (99,9% das requisições abaixo de 300 ms)
- Error budget: o quanto se pode falhar dentro do SLO — 0,1% do mês
O error budget transforma confiabilidade em decisão explícita: com orçamento sobrando, o time acelera entregas; com orçamento estourado, congela e estabiliza.
Trade-offs
Fadiga de alerta é o problema dominante. Alertas demais, ou alertas que não exigem ação, treinam a equipe a ignorá-los — e o alerta importante chega numa caixa que ninguém lê mais.
O critério para todo alerta deve ser: se isso disparar às 3h da manhã, alguém precisa acordar e fazer algo? Se a resposta é não, vira ticket ou painel, não alerta paginável.
O erro simétrico existe: alertar de menos, e descobrir o incidente pelo cliente.
Alerta baseado em taxa de queima do error budget é a evolução do limiar fixo: em vez de "erro > 1%", alerta quando o ritmo de consumo do orçamento indica que o SLO será violado — o que ajusta a urgência ao impacto real.
E cada alerta deve carregar contexto suficiente para agir: o que quebrou, desde quando, qual o impacto, e um link para o runbook. Alerta que só diz "erro em produção" transfere todo o trabalho de diagnóstico para quem foi acordado.
Exemplo prático
PAGINÁVEL (acorda alguém):
taxa de erro de /checkout > 5% por 2 min
serviço totalmente indisponível por 1 min
error budget será estourado em < 24 h no ritmo atual
TICKET (horário comercial):
latência p99 acima do SLO por 30 min
disco atinge 90% em < 7 dias
taxa de erro de job em lote > 10%
PAINEL (sem alerta):
CPU, memória, throughput, hit rate de cache
A separação é a política: três alertas que realmente acordam alguém, e todo o resto tratado no ritmo normal de trabalho. É isso que mantém o primeiro grupo confiável.
Relacionado
Parte de Monitoring · roadmap.sh/system-design