Monitorar performance não é olhar para um dashboard cheio de gráficos. É saber qual métrica indica um problema real antes que o usuário perceba. A lista abaixo reúne as 11 que mais aparecem em ambientes de produção, com um critério prático para cada uma.
A latência mede o tempo entre a requisição e a resposta. Ela costuma ser a primeira a acusar lentidão, mas sozinha não diz onde está o gargalo. Observe percentis como p95 e p99, não apenas a média, pois ela esconde picos.
Throughput é o volume de requisições processadas por segundo. Se ele cai enquanto a latência sobe, há contenção. Se ambos sobem juntos, o sistema pode estar escalando bem, mas fique atento ao limite da infraestrutura.
Taxa de erro indica a porcentagem de requisições que falham. HTTP 500, timeouts e exceções entram aqui. Um aumento súbito de 0,1% para 2% pode ser sintoma de deploy ruim ou dependência externa instável.
Uso de CPU mostra o quanto os núcleos estão ocupados. Picos de 100% podem ser normais em jobs pontuais, mas sustentados por minutos indicam loop ineficiente ou falta de capacidade.
Memória é o consumo de RAM pelo processo. Vazamento de memória aparece como crescimento contínuo mesmo sem aumento de carga. Monitore o heap e o número de objetos retidos.
I/O de disco mede leitura e escrita. Latência alta de disco afeta bancos e logs. Se o disco está em 90% de uso constante, a aplicação pode estar fazendo flush excessivo ou o volume é pequeno.
Rede inclui pacotes perdidos, latência de rede e banda consumida. Perda de pacotes gera retransmissão e aumenta a latência percebida. Monitore também conexões abertas, pois esgotamento de portas derruba serviços.
Saturação de filas indica quando threads ou conexões ficam esperando. Se a fila de um pool de conexões cresce, o tempo de resposta sobe mesmo com CPU folgada. É um sinal de configuração inadequada de concorrência.
Garbage collection (GC) em linguagens como Java e Go. Pausas longas de GC congelam a aplicação. Monitore frequência e duração; se o GC roda o tempo todo, o heap está pequeno ou há muita alocação.
Tempo de resposta de banco é a latência das queries. Uma query que leva 500ms pode ser aceitável em relatório, mas não em uma API de tempo real. Monitore também locks e conexões ativas.
Disponibilidade é o percentual de tempo em que o serviço responde corretamente. 99,9% parece alto, mas representa cerca de 43 minutos de indisponibilidade por mês. Defina o SLO conforme o impacto no usuário.
Para escolher por onde começar, avalie o tipo de aplicação. APIs precisam de latência e taxa de erro. Processamentos batch exigem throughput e I/O. Comece com latência, erro e disponibilidade, pois elas refletem a experiência direta.
FAQ
Qual a diferença entre métrica e KPI?
Métrica é uma medição bruta, como tempo de resposta. KPI é uma métrica ligada a um objetivo de negócio, como manter o checkout abaixo de 2 segundos. No monitoramento, você coleta métricas e define KPIs para tomar decisões.
Com que frequência devo monitorar cada métrica?
Latência, erro e disponibilidade em tempo real (intervalos de 1 minuto ou menos). Uso de CPU e memória a cada 5 minutos. I/O e rede podem ser a cada 1 minuto se houver suspeita de gargalo. Ajuste conforme o custo de coleta.
Qual a melhor ferramenta para monitorar performance?
Depende do stack. Prometheus com Grafana é comum para infraestrutura. APMs como New Relic ou Datadog dão visão de aplicação. Ferramentas nativas da nuvem, como CloudWatch, integram bem com AWS. Teste antes de adotar.
Por que a média de latência não é suficiente?
A média esconde picos. Se 99 requisições levam 100ms e 1 leva 10 segundos, a média fica em 200ms, mas o usuário daquela requisição sentiu demora. Percentis como p95 e p99 mostram o que a maioria experimenta.
Como evitar alertas falsos em métricas?
Use limites dinâmicos baseados em baseline, não em valores fixos. Um pico de CPU de 80% por 2 minutos pode ser normal em horário de pico. Alerte por tendência e duração, não por um único ponto.
O que fazer quando uma métrica está fora do esperado?
Comece pelo erro, depois latência. Olhe logs e traces daquele período. Verifique se houve deploy ou mudança de configuração. Se nada mudou, investigue dependências externas e capacidade da infraestrutura.