System Design/03 - Qualidade/Monitoring2 min
Performance Monitoring
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Mede quão rápido e quão perto do limite o sistema opera.
Os quatro sinais dourados
| Sinal | O que medir |
|---|---|
| Latência | Tempo de resposta — separando sucesso de erro |
| Tráfego | Requisições/s, transações/s |
| Erros | Taxa de falha, explícita e implícita |
| Saturação | Quão cheio está o recurso mais escasso |
Um complemento útil é o RED para serviços (Rate, Errors, Duration) e o USE para recursos (Utilization, Saturation, Errors).
Percentis, nunca média
Latência tem distribuição de cauda longa. A média esconde exatamente quem está sofrendo:
p50 = 40 ms metade dos usuários
p95 = 180 ms
p99 = 2.400 ms ← 1% dos usuários espera 2,4 s
média = 95 ms ← não descreve ninguém
Numa página que faz 100 chamadas internas, quase todo usuário encontra pelo menos uma resposta p99 — por isso a cauda importa muito mais do que a proporção sugere.
Tracing distribuído
Métricas dizem que está lento; traces dizem onde. Um trace mostra o caminho da requisição por todos os serviços, com o tempo de cada trecho — indispensável em Microservices.
Trade-offs
Medir custa: alta cardinalidade (métrica por usuário, por URL única) explode o custo do sistema de métricas. Tracing de 100% do tráfego é caro — daí amostragem, que por sua vez pode perder exatamente a requisição lenta que interessava. Amostragem por cauda (guardar o trace se foi lento) resolve isso e exige mais infraestrutura.
Separar latência de sucesso e de erro é importante e frequentemente esquecido: erros costumam ser rápidos, e misturá-los melhora artificialmente a métrica durante um incidente.
Sobre saturação, vale lembrar a relação da Lei de Little: a latência cresce como 1/(1-utilização). Um sistema a 90% de utilização tem latência ~10x maior que a 50% — por isso saturação é um sinal preditivo, e alertar nela dá tempo de agir antes de a latência explodir.
Exemplo prático
Um alerta que descreve o sintoma, não a causa:
alerta: latência p99 de /checkout > 2s por 5 minutos
O trace da requisição lenta mostra:
POST /checkout ................. 2.340 ms
├─ validar ...................... 12 ms
├─ consultar estoque ........... 18 ms
├─ processar pagamento ......... 2.280 ms ← aqui
│ └─ HTTP gateway externo ... 2.270 ms
└─ gravar pedido ............... 30 ms
Nenhuma métrica de CPU, memória ou banco apontaria isso — o gargalo é um terceiro. E a correção não é escalar nada: é timeout, Circuit Breaker e um caminho de degradação para quando o gateway estiver lento.
Relacionado
Parte de Monitoring · roadmap.sh/system-design