Eu ja passei por aquela reuniao onde o gerente pergunta "por que o sistema esta lento?" e tudo que voce tem e um palpite. Nao e legal. Depois de alguns incidentes em producao, aprendi que monitorar as metricas certas faz a diferenca entre apagar incendio e prevenir que ele comece. Aqui vai minha lista das 11 metricas de performance que todo desenvolvedor deveria ter no radar, e o que fazer com cada uma.
1. Latencia (p95 e p99)
A latencia mede o tempo que uma requisicao leva para ser processada. Mas a media engana: 90% das requisicoes podem ser rapidas e 10%, terriveis. Por isso, o percentil 95 (p95) e o 99 (p99) sao mais uteis: eles mostram o tempo para os 5% e 1% mais lentos. Se o p99 da sua API esta em 2 segundos, significa que 1 em cada 100 usuarios tem uma experiencia ruim. Ferramentas como Datadog ou Prometheus ajudam a visualizar isso.
2. Throughput (requisicoes por segundo)
Throughput e quantas requisicoes sua aplicacao consegue processar por segundo. Uma queda repentina pode indicar gargalo, talvez o banco de dados esteja travando ou um servidor caiu. Num e-commerce em Black Friday, por exemplo, o throughput precisa escalar sem degradar latencia. Monitore em dashboards e configure alertas para quedas abruptas.
3. Taxa de erro (HTTP 5xx e excecoes)
Erros HTTP 5xx ou excecoes nao tratadas sao o alarme de incendio. A taxa de erro ideal e zero, mas na pratica, algo entre 0,1% e 1% e toleravel dependendo do servico. Um aumento para 5% ja merece investigacao imediata. Use ferramentas como Sentry ou New Relic para rastrear a causa raiz.
4. Uso de CPU
CPU a 100% por muito tempo significa que sua aplicacao esta lutando por processamento. Pode ser um loop infinito, um algoritmo ineficiente ou pico de trafego. Monitore a media e o pico: se a CPU fica acima de 80% por mais de 5 minutos, considere escalar ou otimizar codigo.
5. Uso de memoria
Vazamento de memoria e classico: o consumo sobe, sobe, e de repente o processo morre com OutOfMemoryError. Monitore o uso de heap (em Java) ou RSS (em Node.js). Um crescimento constante sem estabilizacao e bandeira vermelha. Ferramentas como Grafana com metricas do garbage collector ajudam a detectar.
6. Tempo de resposta do banco de dados
Queries lentas derrubam aplicacoes. Monitore o tempo medio de resposta do banco (deve ficar abaixo de 100ms para consultas simples) e identifique queries que passam de 1 segundo. No PostgreSQL, o parametro log_min_duration_statement ajuda a capturar as lentas. Um indice faltando pode ser a causa.
7. Taxa de cache hit
Cache existe para evitar trabalho repetido. Se a taxa de hit do Redis ou Memcached cai abaixo de 80%, voce esta perdendo o beneficio. Isso pode acontecer por chaves expirando cedo demais ou um padrao de acesso imprevisivel. Ajuste o TTL e veja a taxa subir.
8. Disponibilidade (uptime)
Uptime de 99,9% parece bom, mas sao 8,7 horas de downtime por ano. Monitore a disponibilidade por endpoint critico, nao so o servidor, mas a API que o usuario realmente usa. Servicos como Pingdom ou UptimeRobot disparam alertas quando cai.
9. Tempo de inicializacao da aplicacao
Em ambientes com Kubernetes ou auto-scaling, uma aplicacao que demora 5 minutos para subir atrasa o deploy e a recuperacao de falhas. Monitore o tempo de startup e otimize: evite inicializacoes sequenciais desnecessarias, use lazy loading.
10. Taxa de garbage collection (para linguagens gerenciadas)
Em Java, C# ou Go, o GC pausa a execucao. Uma taxa alta de GC (mais de 5% do tempo de CPU) indica pressao na memoria. Monitore a frequencia e duracao das pausas: se o GC jovem leva mais de 100ms, talvez seja hora de aumentar o heap.
11. Tamanho do payload de resposta
Respostas JSON de 2 MB sobrecarregam a rede e o cliente. Monitore o tamanho medio das respostas. Se uma API de listagem retorna 500 KB, considere paginacao ou campos seletivos. Use ferramentas como Chrome DevTools ou Wireshark para inspecionar.
Qual ferramenta escolher?
Nao precisa de todas de uma vez. Comece com Prometheus + Grafana (gratuitos e robustos) para as metricas principais. Depois adicione APM como Datadog ou New Relic para tracing. O importante e ter visibilidade antes do incidente, nao depois.
Perguntas frequentes
Qual a diferenca entre latencia e throughput?
Latencia mede o tempo de cada requisicao; throughput mede quantas cabem por segundo. Eles se relacionam: alta latencia geralmente reduz throughput.
Preciso monitorar todas essas metricas?
Nao. Comece com latencia, taxa de erro e uso de CPU. Adicione as outras conforme o sistema cresce ou aparecem problemas especificos.
O que e p95 e p99?
Percentis: p95 significa que 95% das requisicoes sao mais rapidas que aquele valor. p99 e o limite para 99%. Eles ignoram outliers extremos.
Como definir alertas sem gerar ruido?
Use limites dinamicos baseados em desvio padrao (anomaly detection) em vez de valores fixos. Assim, evita alarmes falsos em horarios de pico.
Qual ferramenta e melhor para comecar?
Prometheus com Grafana e gratuito e cobre a maioria dos casos. Para tracing distribuido, Jaeger ou Zipkin sao boas opcoes open-source.
Devo monitorar em tempo real ou historico?
Ambos. O historico ajuda a identificar tendencias (ex.: memoria crescendo), e o tempo real, a reagir a incidentes.