Sistemas modernos geram milhares de métricas. Dashboards lotados de gráficos. Alertas disparando constantemente. A ironia é que quanto mais dados, mais difícil é ver o que importa. Este artigo ensina a separar sinal de ruído.
O problema não é falta de dados. É excesso de dados sem contexto.
Os Três Níveis de Observação
Nível 1: Infraestrutura
O que medir:
CPU:
- Utilização média
- Picos de uso
- Throttling (em containers)
Memória:
- Uso atual vs disponível
- Swap usage
- OOM events
Disco:
- IOPS
- Latência de I/O
- Espaço disponível
Rede:
- Bandwidth utilizado
- Pacotes perdidos
- Conexões ativas
Por que observar: Identifica limites físicos e problemas de recursos.
Armadilha: Focar só aqui. Infraestrutura saudável não significa aplicação saudável.
Nível 2: Aplicação
O que medir:
Latência:
- p50, p95, p99
- Por endpoint
- Por tipo de operação
Throughput:
- Requests por segundo
- Transações por segundo
- Por funcionalidade
Erros:
- Taxa de erro
- Por tipo (4xx, 5xx)
- Por causa raiz
Saturação:
- Connection pools
- Thread pools
- Queue depths
Por que observar: Revela experiência real do usuário.
Armadilha: Métricas agregadas escondem problemas específicos.
Nível 3: Negócio
O que medir:
Conversão:
- Funil de vendas
- Taxa de abandono
- Tempo até conversão
Engajamento:
- Sessões por usuário
- Tempo na plataforma
- Features mais usadas
Receita:
- Transações/hora
- Valor médio
- Falhas de pagamento
Por que observar: Conecta performance técnica a impacto no negócio.
Armadilha: Difícil de correlacionar com métricas técnicas.
Os Golden Signals
Google SRE definiu 4 sinais essenciais:
1. Latência
# Tempo de resposta por percentil
histogram_quantile(0.50, rate(http_request_duration_seconds_bucket[5m]))
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
O que revela:
- p50: Experiência típica
- p95: Experiência da maioria
- p99: Pior caso comum
Por que percentis, não média:
Cenário: 99 requests de 10ms, 1 request de 10s
Média: 109ms (parece ok)
p99: 10s (revela o problema)
2. Tráfego
# Requests por segundo
rate(http_requests_total[5m])
# Por endpoint
sum by(endpoint) (rate(http_requests_total[5m]))
# Por status
sum by(status_code) (rate(http_requests_total[5m]))
O que revela:
- Volume atual vs esperado
- Distribuição de carga
- Tendências de uso
3. Erros
# Taxa de erro
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# Por tipo
sum by(status_code) (rate(http_requests_total{status=~"[45].."}[5m]))
O que revela:
- Saúde geral do sistema
- Problemas específicos (4xx vs 5xx)
- Tendências de degradação
4. Saturação
# Pool de conexões
pg_stat_activity_count / pg_settings_max_connections
# Threads
jvm_threads_current / jvm_threads_max
# CPU
sum(rate(container_cpu_usage_seconds_total[5m]))
/ sum(container_spec_cpu_quota / container_spec_cpu_period)
O que revela:
- Quanto do recurso está em uso
- Proximidade do limite
- Risco de saturação
RED Method (para serviços)
Rate:
- Requests por segundo
- Quantas operações o serviço processa
Errors:
- Taxa de falhas
- Quantas operações falham
Duration:
- Latência por request
- Quanto tempo cada operação leva
# Dashboard RED completo
# Rate
sum(rate(http_requests_total[5m]))
# Errors
sum(rate(http_requests_total{status=~"5.."}[5m]))
# Duration
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
USE Method (para recursos)
Utilization:
- % do recurso em uso
- CPU, memória, disco, rede
Saturation:
- Trabalho enfileirado
- Requests aguardando recursos
Errors:
- Falhas de recursos
- OOM, disk full, network errors
# USE para CPU
# Utilization
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))
# Saturation
avg(node_load15) / count(node_cpu_seconds_total{mode="idle"})
# Errors
increase(node_cpu_core_throttles_total[5m])
Métricas Específicas por Componente
Banco de Dados
Conexões:
- Ativas vs máximo
- Idle vs waiting
- Connection errors
Queries:
- Queries por segundo
- Tempo médio por query
- Slow queries
Recursos:
- Buffer cache hit rate
- Disk reads vs cache reads
- Lock wait time
Cache (Redis)
Performance:
- Hit rate
- Miss rate
- Latência de operações
Memória:
- Uso atual
- Evictions
- Fragmentation
Conexões:
- Clients conectados
- Blocked clients
Message Queue (Kafka)
Throughput:
- Messages in/out por segundo
- Bytes in/out
Consumer:
- Consumer lag
- Commit rate
- Rebalances
Broker:
- Under-replicated partitions
- Request queue size
Criando um Dashboard Efetivo
Estrutura recomendada
┌─────────────────────────────────────────────────┐
│ HEALTH OVERVIEW │
│ [Status] [Error Rate] [p95 Latency] [Traffic] │
├─────────────────────────────────────────────────┤
│ GOLDEN SIGNALS │
│ [Latência p50/p95/p99] [Traffic] [Errors] [Sat] │
├─────────────────────────────────────────────────┤
│ TOP ENDPOINTS │
│ [By latency] [By traffic] [By errors] │
├─────────────────────────────────────────────────┤
│ RESOURCES │
│ [CPU] [Memory] [DB] [Cache] │
├─────────────────────────────────────────────────┤
│ DEPENDENCIES │
│ [External APIs] [Payment] [Email] │
└─────────────────────────────────────────────────┘
Regras de design
1. Menos é mais:
- 5-10 gráficos por dashboard
- Foco no que requer ação
2. Hierarquia clara:
- Overview no topo
- Detalhes embaixo
- Drill-down disponível
3. Contexto temporal:
- Compare com baseline
- Mostre tendências
- Marque deploys/eventos
4. Acionável:
- Cada gráfico responde uma pergunta
- Se não requer ação, remova
Correlacionando Métricas
Exemplo: Investigando lentidão
Sintoma: p95 latency aumentou 2x
Verificar correlações:
1. Tráfego aumentou?
→ Não, estável
2. Erros aumentaram?
→ Sim, 5xx subiu 3x
3. Recursos saturados?
→ DB connections em 95%
4. Query específica lenta?
→ Sim, query de relatório sem índice
Root cause: Deploy incluiu nova query sem índice
que compete por conexões
Conclusão
Observar efetivamente significa:
- Foco nos Golden Signals como ponto de partida
- USE para recursos, RED para serviços
- Métricas de negócio para contexto
- Correlação para encontrar causas raízes
- Dashboards acionáveis, não decorativos
Quantidade de métricas não importa. Importa saber quais perguntas cada métrica responde.
Se você não sabe por que está medindo algo, pare de medir.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.