Observabilidade na AWS: CloudWatch, Grafana e o que monitorar de verdade

Monitoramento não é ter dashboards bonitos. É detectar problemas antes que o cliente perceba e ter contexto suficiente para resolver em minutos, não horas.

Os 3 pilares

• Métricas: números agregados ao longo do tempo (CPU, latência, error rate)
• Logs: eventos discretos com contexto (stack traces, requests, audit trail)
• Traces: o caminho de uma request através de múltiplos serviços (distributed tracing)

Sem os três, você sempre vai ter pontos cegos.

Stack que recomendamos

O que monitorar (de verdade)

Esqueça métricas de vaidade. Foque no que impacta o negócio:

Sinais de ouro (Golden Signals)

1. Latência — P50, P95, P99 das APIs e páginas críticas
2. Error rate — % de respostas 5xx e 4xx anômalas
3. Tráfego — requests/s por endpoint (detecta anomalias e ataques)
4. Saturação — CPU, memória, IOPS, conexões do banco

Alarmes que acordam alguém de madrugada

• Error rate > 5% por 3 minutos consecutivos
• Latência P99 > 2x do baseline por 5 minutos
• Disco de banco acima de 85%
• Fila de processamento crescendo sem drenar

Grafana como camada de visualização

O CloudWatch é excelente para coleta e alarmes, mas a UX de dashboards é limitada. Usar o Amazon Managed Grafana como camada de visualização dá:

• Dashboards mais legíveis e compartilháveis
• Correlação entre métricas, logs e traces na mesma tela
• Alertas visuais com contexto do incidente

O anti-padrão mais comum

Ter 200 alarmes configurados que ninguém olha. Resultado: alarm fatigue — quando tudo é urgente, nada é urgente.

Menos alarmes, mais precisos. Cada alarme deve ter um runbook associado: “se disparou, faça X”. Sem runbook, o alarme não deveria existir.