# 11 métricas de observabilidade essenciais para monitorar aplicações

> As 11 métricas de observabilidade essenciais para monitorar aplicações incluem latência, taxa de erro, throughput, saturação de recursos, uso de CPU, memória, disco, rede, tempo de resposta de API, contagem de requisições e duração de transações. Essas métricas fornecem visibilidade sobre performance, disponibilidade e saúde do sistema, permitindo que times de operações identifiquem gargalos e garantam a confiabilidade das aplicações.

*PosUp · Apps e Software · 27 de julho de 2026 · Patrícia Lemos*

Monitorar aplicações exige mais que logs. Conheça as 11 métricas de observabilidade que todo time de operações precisa acompanhar para garantir performance e disponibilidade.

Métricas de observabilidade são os sinais de telemetria que ajudam times de operações a entender o que acontece dentro de sistemas complexos. Elas transformam dados brutos em respostas sobre performance, disponibilidade e comportamento de aplicações. A seguir, listamos as 11 métricas essenciais que todo monitoramento deve incluir, do básico ao avançado.

## 1. Latência

Latência mede o tempo que uma requisição leva para ser processada. É o primeiro indicador de que algo vai mal. Uma API que respondeva em 200ms e passa a responder em 2s indica gargalo. Monitore percentis (p50, p95, p99), não apenas médias - a média esconde picos. Exemplo: se o p99 sobe, usuários reais estão sofrendo, mesmo que a média pareça aceitável.

## 2. Taxa de erro

Percentual de requisições que retornam código de erro (4xx, 5xx) ou exceções não tratadas. Idealmente abaixo de 1%. Um aumento súbito de 500s indica falha funcional ou de infraestrutura. Crucial para SLIs e SLOs.

## 3. Throughput

Número de requisições processadas por segundo ou minuto. Ajuda a dimensionar capacidade e detectar quedas de tráfego (possível outage) ou picos (possível ataque). Compare com o baseline histórico.

## 4. Saturação de recursos

Percentual de uso de CPU, memória, disco e rede. Quando um recurso chega perto de 100%, o sistema degrada. Use alertas em 80% para ter margem de reação. Exemplo: disco 90% pode travar gravações de log.

## 5. Uso de CPU e memória por processo

Métrica granular: quanto cada serviço consome. Um vazamento de memória (uso crescente sem queda) é detectável antes de causar crash. Ferramentas como Prometheus e cAdvisor expõem esses dados.

## 6. Tempo de resposta de banco de dados

Consultas lentas são causa comum de latência alta. Monitore tempo médio de query, número de conexões abertas e taxa de locks. Se o banco demora, a aplicação inteira sofre.

## 7. Taxa de requisições HTTP por status

Distribuição de respostas 2xx, 3xx, 4xx, 5xx. Um pico de 429 (too many requests) indica throttling; 503 indica serviço indisponível. Permite correlacionar com deploys ou mudanças de configuração.

## 8. Duração de filas de mensageria

Tempo que uma mensagem fica na fila antes de ser processada. Filas longas indicam consumidores lentos ou subdimensionados. Exemplo: fila de pagamentos com 30s de espera pode estourar timeout do frontend.

## 9. Disponibilidade de serviços (uptime)

Percentual de tempo que um serviço responde corretamente. Um microsserviço com 99,9% de uptime ainda pode falhar 8 horas por ano. Monitore health checks e endpoints de readiness.

## 10. Taxa de cache hit

Percentual de requisições atendidas pelo cache sem precisar buscar no banco. Taxa abaixo de 80% sugere configuração de cache inadequada. Aumentar hit reduz latência e carga no banco.

## 11. Tempo de inicialização de pods (em ambientes Kubernetes)

Quanto tempo um contêiner leva para ficar pronto. Inicializações lentas atrasam deploys e escalonamento automático. Ideal abaixo de 10 segundos para serviços web.

## Como escolher as métricas certas para seu caso

Não tente monitorar tudo de uma vez. Comece com latência, taxa de erro e saturação - os Três Pilares da Observabilidade (logs, métricas e rastreios) da IBM. Depois adicione métricas específicas do seu domínio, como tempo de fila para sistemas de mensageria ou cache hit para aplicações com alto tráfego. O importante é que cada métrica responda a uma pergunta de negócio: "o usuário está satisfeito?" ou "o sistema vai quebrar nas próximas horas?".

## FAQ

### O que são métricas de observabilidade?

São valores numéricos coletados de sistemas que descrevem seu estado e comportamento. Exemplos: latência, taxa de erro, uso de CPU. Diferem de logs (texto) e traces (rastreio de requisições). Juntos formam os três pilares da observabilidade.

### Qual a diferença entre métrica e log?

Métrica é um valor numérico agregado (ex.: 200ms de latência média). Log é um registro textual de um evento (ex.: "erro de conexão às 14:32"). Métricas são mais leves para armazenar e ideais para alertas.

### Quantas métricas devo monitorar?

Não existe número mágico. Comece com 5 a 10 métricas essenciais (latência, erro, throughput, saturação, CPU). Adicione conforme a complexidade do sistema. Mais métricas não significam mais visibilidade - podem gerar ruído.

### Como definir alertas para métricas de observabilidade?

Use limites dinâmicos baseados em percentis históricos (ex.: alertar se p95 de latência ultrapassar 3 desvios padrão da média). Evite limites fixos que se tornam obsoletos com mudanças de tráfego.

### Métricas de observabilidade são suficientes para depurar problemas?

Não sozinhas. Métricas indicam que algo está errado, mas logs e traces mostram o quê e por quê. A combinação dos três pilares é necessária para diagnóstico completo.

### Ferramentas open source para coletar métricas?

Prometheus (coleta e alertas), Grafana (visualização), Node Exporter (métricas de sistema), cAdvisor (contêineres). Todas integram bem com Kubernetes.

---

Fonte (canonical): https://posup.com.br/apps-e-software/11-metricas-de-observabilidade-essenciais-para-monitorar-aplicacoes/