Observabilidade: como enxergar o que acontece dentro da aplicação

O que é observabilidade e por que vai além do monitoramento

Saber que algo quebrou versus entender o porquê

Monitoramento tradicional responde "o sistema está funcionando?" — verificando se serviços estão de pé e retornando resposta. Observabilidade responde "por que o sistema se comporta assim?" — entendendo a causa raiz de problemas, gargalos, comportamentos inesperados e a experiência real do usuário. A diferença prática: monitoramento diz que o endpoint /checkout está com latência alta; observabilidade revela que é uma query específica que está executando full scan por falta de índice, causada pelo filtro de data específico que o usuário final aplicou. Observabilidade é construída sobre três pilares: logs, métricas e traces.

Logs — o registro do que aconteceu

Eventos discretos com contexto suficiente para diagnóstico

Logs registram eventos específicos que aconteceram no sistema: uma requisição chegou, um erro ocorreu, um job completou. Bons logs têm: timestamp preciso (com timezone), nível de severidade (DEBUG, INFO, WARN, ERROR), contexto suficiente para entender o que aconteceu sem precisar de contexto externo (qual usuário, qual operação, qual recurso afetado), e um trace ID para correlacionar logs de múltiplos serviços de uma mesma requisição. Logs estruturados em JSON (em vez de texto livre) permitem busca e filtragem eficiente. O erro mais comum é logar demais (milhões de logs DEBUG em produção que soterram os logs importantes) ou de menos (sem contexto suficiente para diagnosticar o problema).

Métricas — tendências e comportamento ao longo do tempo

Números que revelam como o sistema se comporta em escala

Métricas são valores numéricos coletados periodicamente que revelam o comportamento do sistema ao longo do tempo: número de requisições por segundo, latência (p50, p95, p99), taxa de erros, uso de CPU e memória, comprimento de fila, número de conexões de banco de dados ativas. Métricas são ideais para alertas (alertar quando taxa de erro ultrapassa 1%), dashboards (visualizar tendências), e capacity planning (prever quando o sistema vai precisar de mais recursos). A diferença fundamental de logs é que métricas são agregações numéricas — você não sabe qual request específico contribuiu para o p99, mas sabe que o p99 subiu.

Traces — o caminho de uma requisição pelo sistema

Rastrear uma operação através de múltiplos serviços

Distributed tracing rastreia o caminho completo de uma requisição através de todos os serviços que ela atravessa. Em uma arquitetura de microsserviços, uma requisição do usuário pode passar por API Gateway, serviço de autenticação, serviço de produto, serviço de preços e serviço de estoque antes de retornar resposta. Um trace captura cada "span" (operação em um serviço) com duração e metadados, formando uma árvore que mostra onde o tempo foi gasto. Com traces, é possível identificar que a latência alta em /checkout é porque o serviço de preços está esperando 800ms por uma resposta do serviço externo de taxas — algo impossível de identificar só com logs ou métricas.

Os três pilares juntos — quando usar cada um

Logs para diagnóstico, métricas para alertas, traces para performance

Os três pilares são complementares. Métricas revelam que há um problema (taxa de erro subiu para 5%). Logs revelam o que está causando o problema (TypeError: cannot read property 'id' of undefined, linha 234). Traces revelam onde no fluxo o problema aparece e qual é o impacto de performance (o erro ocorre no passo de validação de estoque, que está levando 2 segundos por timeout em API externa). Na prática: configure alertas baseados em métricas, investigue com logs e traces. Ferramentas como Grafana, Prometheus, Datadog, New Relic e OpenTelemetry permitem correlacionar os três pilares de forma integrada.

Alertas — quando e como ser notificado

Alertar no momento certo, sem alertas desnecessários que treinam a ignorar

Alertas eficazes têm três características: são acionáveis (quando recebo esse alerta, sei o que fazer), têm threshold correto (baixo demais gera falsos positivos que são ignorados; alto demais notifica tarde demais), e têm contexto (o alerta inclui link para dashboard relevante, janela de tempo e qual métrica disparou). Alertas ruins geram alert fatigue — equipes que recebem dezenas de alertas por dia param de tratá-los com seriedade. As métricas mais importantes para alertar: taxa de erro em endpoints críticos (SLI), latência p99 acima do SLO, fila de jobs crescendo sem consumir, e disponibilidade do serviço.

Structured Logging — logs que as ferramentas conseguem processar

JSON estruturado em vez de texto livre para busca e análise eficiente

Logs em texto livre como "ERROR: User 12345 failed to checkout at 2024-01-15 14:32:11" são legíveis para humanos mas difíceis de filtrar e agregar automaticamente. Logs estruturados em JSON permitem: filtrar por userId = 12345, agregar erros por tipo, criar dashboards de taxa de erro por operação, e correlacionar com traces pelo traceId. O formato mínimo para um log estruturado: timestamp, level, message, service, traceId, spanId, e campos específicos do contexto (userId, orderId, operationName). Bibliotecas como Serilog (.NET), winston (Node.js), loguru (Python) e log4j2 (Java) suportam saída JSON nativa.

Health Checks — sabendo que o serviço está pronto para receber tráfego

Liveness, readiness e startup probes em Kubernetes

Health checks são endpoints que respondem ao orquestrador (Kubernetes, ECS) se o serviço está saudável. Liveness probe verifica se o processo está vivo (se falhar, o container é reiniciado). Readiness probe verifica se o serviço está pronto para receber tráfego (se falhar, o pod é removido do load balancer mas não reiniciado). Startup probe dá tempo extra para serviços com inicialização lenta. Um health check bem implementado verifica não apenas que o processo responde, mas que as dependências críticas estão funcionando: banco de dados, Redis, e outros serviços obrigatórios. Um health check que sempre retorna 200 sem verificar dependências dá falsa confiança.

Custo e volume de observabilidade

Coletar tudo tem custo — priorizar o que importa

Logs, métricas e traces têm custo de armazenamento, processamento e ingestão — especialmente em sistemas de alto volume. Estratégias para controlar custo: sampling de traces (rastrear 10% das requisições em vez de 100% para tráfego normal, 100% para erros e operações críticas), log levels por ambiente (DEBUG apenas em desenvolvimento, INFO/WARN/ERROR em produção), métricas com granularidade adequada (30 segundos é suficiente para a maioria dos alertas; 1 segundo é desnecessário e caro), e retenção diferenciada (erros guardados por 30 dias, debug logs por 24h). A regra: coletar o suficiente para diagnosticar problemas em produção, não coletar tudo apenas porque é possível.

Conclusão — observabilidade é a diferença entre adivinhar e saber

Sistemas sem observabilidade são black boxes que só revelam problemas quando é tarde

Um sistema sem observabilidade é um sistema que você não entende. Você sabe que algo quebrou (o usuário reclamou), mas não sabe por quê, quando começou, quem foi afetado, ou se está piorando. Com os três pilares implementados, você responde todas essas perguntas em minutos em vez de horas. Comece pelo básico: logs estruturados com nível correto, métricas de latência e taxa de erro, e alerts nos SLIs críticos. Adicione traces quando investigar performance distribuída for uma necessidade frequente. Continue em: Fundamentos obrigatórios antes de produção.