Observabilidade: a diferença entre log, métrica e trace que ninguém explica direito
Todo sistema produz dados. Poucos sistemas são observáveis. A diferença está em entender o que perguntar — e ter as ferramentas certas para responder.
Durante muito tempo, minha estratégia de observabilidade era: console.log em tudo e torcer para o erro aparecer no terminal quando algo quebrasse.
Funcionava razoavelmente bem com uma aplicação, um desenvolvedor, e um servidor. Quebrou completamente quando o sistema cresceu para múltiplos serviços.
Observabilidade tem três pilares. A maioria das pessoas aprende sobre eles separadamente e demora para entender como se encaixam. Vou tentar encurtar esse caminho.
Logs são eventos discretos. "Usuário X fez login às 14:32." "Request para /api/users retornou 500." "Conexão com banco de dados falhou." Logs são bons para entender o que aconteceu numa sequência específica de eventos. O problema de logs: volume. Um sistema com tráfego moderado produz milhões de logs por dia. Sem estrutura e indexação, procurar algo específico nos logs é como procurar agulha em palheiro.
Métricas são medidas numéricas ao longo do tempo. Taxa de requests por segundo. Latência média. Percentual de CPU. Número de erros nas últimas 5 minutos. Métricas são bons para entender tendências e para alertar quando algo está fora do normal. O problema: métricas são agregações. Elas te dizem que a latência média subiu — mas não dizem qual request específico está lento e por quê.
Traces são o caminho que uma request percorre através do sistema. Em microserviços, uma request do usuário pode passar por dez serviços diferentes. Trace te mostra cada hop, quanto tempo levou em cada um, e onde o tempo foi perdido. O problema: instrumentação. Você precisa propagar um trace ID através de todos os serviços, o que requer código adicional e um sistema de coleta como Jaeger ou Tempo.
A armadilha comum: equipes implementam logs abundantes e métricas básicas, e chamam isso de observabilidade. Mas quando um usuário reporta que "às vezes o sistema fica lento", você não consegue responder. Você tem médias — não a experiência individual do usuário.
Observabilidade de verdade é a capacidade de responder perguntas novas sobre o sistema sem precisar de novo código. Você olha para os dados que já tem e consegue triangular o problema.
Como eu aprendi na prática: meu primeiro contato com Prometheus e Grafana foi numa situação de crise. A aplicação estava lenta, os usuários reclamando, e eu não tinha nenhuma métrica de latência instrumentada. Ficamos horas no modo debug às cegas — olhando logs um por um, rodando queries no banco de dados manualmente, tentando reproduzir o problema localmente.
Depois de resolver, a primeira coisa que fiz foi instrumentar as rotas principais com histogramas de latência no Prometheus. Criei um dashboard no Grafana mostrando p50, p95, e p99 de latência por rota.
Na próxima vez que houve uma lentidão, levou dez minutos para identificar qual rota, qual dependência, e qual janela de tempo. O problema que antes levava horas virou minutos.
Não precisa implementar os três pilares de uma vez. O caminho que recomendo:
Começa com logs estruturados. JSON em vez de texto livre. Campos padronizados: timestamp, level, service, message, trace_id. Isso já vai longe.
Depois adiciona métricas para as coisas que você monitora: latência, taxa de erro, throughput. Cria alertas para quando essas métricas saem do normal.
Trace fica para quando você tem múltiplos serviços e precisa entender fluxo entre eles.
Observabilidade não é produto, é prática. Você não instala Grafana e fica observável. Você precisa instrumentar, definir o que medir, criar dashboards que fazem perguntas úteis, e calibrar alertas que disparam quando importa — não toda hora.
Essa semana: olha para o sistema em que você trabalha. Consegues responder essas três perguntas só com os dados que você tem agora? (1) Qual a latência do endpoint mais crítico nos últimos 7 dias? (2) Em qual horário do dia ocorreram mais erros na última semana? (3) Se um usuário específico reportar problema, você consegue ver o que aconteceu na request dele? Se alguma resposta for "não sei", você tem um gap de observabilidade para endereçar.