# 11 metricas de performance para monitorar em dev

> As métricas de performance para desenvolvimento de software abrangem 11 indicadores essenciais, incluindo latência, throughput, taxa de erro, utilização de CPU e memória, além de métricas de fila e dependências externas. A interpretação correta exige contexto operacional, como picos sazonais ou mudanças de código, pois números isolados enganam. Monitorar essas métricas permite identificar gargalos e otimizar a experiência do usuário final.

*Bombou na Web · Tecnologia · 28 de agosto de 2026 · Priscila Andrade*

Monitorar metricas de performance vai além de CPU e memoria. Veja as 11 que realmente importam, como interpretar cada uma e por que contexto vale mais que numero solto.

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.

---

Fonte (canonical): https://www.bombounaweb.com.br/tecnologia/11-metricas-de-performance-para-monitorar-em-dev/