# 11 metricas de performance que todo desenvolvedor deve monitorar

> As 11 métricas de performance que todo desenvolvedor deve monitorar incluem latência, taxa de erro, throughput, uso de CPU, memória, disco, rede, tempo de resposta do banco de dados, filas, garbage collection e taxa de requisições. O monitoramento contínuo dessas métricas previne falhas em produção e otimiza a experiência do usuário. Ferramentas como Prometheus e Grafana auxiliam na coleta e visualização dos dados.

*Blog Sem Juízo · Destaques · 16 de julho de 2026 · Tomás Wenzel*

Monitorar metricas de performance e essencial para evitar surpresas em producao. Este guia lista as 11 principais, de latencia a taxa de erro, com exemplos praticos e dicas de ferramentas.

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.

---

Fonte (canonical): https://blogsemjuizo.com.br/destaques/11-metricas-de-performance-que-todo-desenvolvedor-deve-monitorar/