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

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.