Como este tema funciona na sua empresa
Pequenas empresas raramente implementam observabilidade completa (é complexo). Começar com logs centralizados é passo 1 — "quando API falhou, o quê mostrou o log?". CloudWatch, Loki ou ELK são opções viáveis para startup.
Empresas médias implementam os "três pilares": logs (o quê aconteceu), métricas (quanto/quão rápido), traces (o caminho). Correlação manual ainda é comum — time de SRE agrupa eventos relacionados para diagnóstico.
Grandes organizações implementam observabilidade com IA: correlação automática de logs, métricas, traces via machine learning. Ferramentas: Datadog, Splunk, Dynatrace, Elastic. Um alerta integra todos os três pilares automaticamente.
Observabilidade em TI é capacidade de entender o estado interno de um sistema observando seus outputs externos — combinando três pilares (logs, métricas, traces) para diagnóstico profundo de problemas. É evolução de "monitoramento" — não apenas "o sistema está bem?" mas "por quê não está bem e onde começou?"[1].
Os três pilares da observabilidade
Observabilidade tradicional se divide em três componentes[2]:
- Logs: Registro textual de eventos discretos. "Usuário login falhou às 14:32:15, erro 401". Exemplo: aplicação escreve "ERROR: database connection timeout". Desvantagem: volume massivo (pode gerar petabytes/dia), unstructured (difícil correlacionar).
- Métricas: Série temporal numérica. "CPU está em 85%", "latência p99 = 500ms", "erro rate = 0.5%". Agregado (resumido), volume pequeno, fácil correlacionar. Desvantagem: perde detalhe (qual request causou a latência?).
- Traces: Fluxo de uma requisição através de múltiplos serviços. "Request #123 entrou em API ? chamou DB ? fez cache lookup ? retornou em 250ms". Distributed tracing mostra dependências entre serviços. Desvantagem: requer instrumentação complexa, volume grande se ativo para 100% de requests.
Observabilidade real combina os três: métrica alerta "latência p99 subiu", trace mostra qual serviço (DB?), logs confirmam (DB estava em lock).
Monitoramento vs Observabilidade: qual é a diferença?
Monitoramento responde: "o sistema está ok?" (binário). Observabilidade responde: "por quê não está ok, onde começou, qual é a causa raiz?"[3].
Exemplo: Monitoramento (alerta): "API /checkout retorna 500". Observabilidade (diagnóstico): "alerta foi disparado por métrica (latência 5s > threshold 2s). Trace mostra request #1234 chamou DB, DB levou 4.5s porque query fez full table scan (índice missing). Logs confirmam: 'WARNING: slow query detected'. Causa raiz: índice foi dropado por acidente em deploy anterior".
Monitoramento diz problema. Observabilidade diz problema + contexto + causa raiz. Segunda é crítica para SRE (Site Reliability Engineering).
Implementação dos três pilares
Logs centralizados: ELK Stack, Splunk, DataDog, Grafana Loki. Engenheiros instrumentam código para escrever logs estruturados (JSON, não texto livre). Exemplo: `{"level": "ERROR", "service": "api", "error": "db_timeout", "duration_ms": 5000, "user_id": 123}`.
Métricas: Prometheus, Grafana, DataDog. Aplicação expõe métricas (Prometheus formato). Sistema scrapes periodicamente. Agregação acontece aqui (P50, P95, P99 latências).
Traces distribuídos: Jaeger, Zipkin, DataDog, Splunk. Cada request recebe ID único. Passa por múltiplos serviços, cada um registra seu trecho. Tracer reconstrói fluxo completo. Exigência: padrão OpenTelemetry para interoperabilidade.
Desafios práticos de observabilidade
1. Volume de dados: Observabilidade gera dados massivos. Rastrear 100% de requests é impraticável (caro). Solução: sampling (rastrear 10% de requests, não 100%).
2. Correlação manual é slow: Sem automação, engenheiro procura: "qual métrica corresponde a este log?". Com IA/ML: sistema já correlacionou, sugere causa raiz.
3. Latência de insight: Dados precisam ser quase real-time para diagnóstico útil. Data warehouse tradicional (batch) é lento demais. Requer stream processing ou índices em tempo real.
4. Custo: Datadog/Splunk cobram por volume (USD 0.10-0.50 por GB de logs ingerido). Uma única aplicação pode gerar 100GB/dia de logs. Precisa descartar logs menos importantes.
Padrões recomendados
Estruturação de logs: Use campos estruturados (JSON), não texto livre. Exemplo bom: `{"timestamp": "2026-05-08T14:32:15Z", "service": "checkout", "event": "payment_processing", "duration_ms": 250}`. Ruim: "payment processing took a while".
Naming conventions: Logs devem ter prefixos claros. Exemplo: `app.checkout.payment.success`, `app.checkout.payment.failure`, `infra.db.slow_query`. Facilita filtro depois.
Cardinality control: Evitar campos com valores ilimitados em métricas (evita "cardinality explosion"). Exemplo: usar `user_id` em logs (ok, é detalhado), mas não em métricas de Prometheus (ruins, gera série temporal infinita).
Sinais de que sua empresa precisa observabilidade avançada
- Tempo de diagnóstico de incidente é >1 hora ("procurando em qual serviço falhou?").
- Não há histórico claro de "o sistema funcionava bem antes", quando começou a degradar?
- Bugs em produção são descobertos via usuário, não via sistema (sem visibilidade).
- Múltiplos times usam diferentes ferramentas para diagnóstico (falta de coordenação).
- Rollout de mudança é arriscado (não há visibilidade se causou problema).
- Serviços comunicam-se, mas não há visibilidade de latência inter-serviço.
- Auditors pedem "cadeia de evidência completa" para incidentes, e não há correlação fácil.
Caminhos para implementar observabilidade
- Perfil: SRE ou DevOps com experiência em ELK/Prometheus/OpenTelemetry
- Tempo: 4-8 meses para setup e instrumentação de aplicações
- Faz sentido quando: Aplicações são open-source (fácil modificar), time interno disponível
- Risco: Instrumentação incompleta, dados não correlacionados bem
- Tipo: Consultoria de observabilidade, SRE advisory, DataDog/Splunk partner
- Vantagem: Implementação rápida, metodologia pronta, suporte contínuo
- Faz sentido quando: Arquitetura complexa, precisa rollout em semanas
- Resultado: Observabilidade operacional em 2-4 meses
Precisa estruturar observabilidade?
Se implementar observabilidade é objetivo, o oHub conecta você com especialistas em SRE e infraestrutura. Em menos de 3 minutos, descreva sua arquitetura e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é a diferença entre logs, métricas e traces?
Logs: eventos textuais discretos (o quê aconteceu). Métricas: séries numéricas (quanto/quão rápido). Traces: fluxo de uma requisição (o caminho). Observabilidade combina os três para diagnóstico completo.
É possível fazer observabilidade com dados em tempo real?
Sim, mas caro. Solução prática: rastreamento 100% de alguns serviços críticos, sampling de 5-10% de outros. Logs estruturados com indexação rápida (Elasticsearch, Splunk) permitem busca quase real-time.
Quanto custa observabilidade em produção?
Open-source (ELK + Prometheus + Jaeger): USD 0 software + custo de infraestrutura (USD 500-2000/mês). SaaS (DataDog): USD 0.10-0.50 por GB de logs ingerido + USD 10-20 por métrica por mês (caro para volume alto).
OpenTelemetry é obrigatório?
Não, mas recomendado. OpenTelemetry é padrão aberto que evita lock-in com fornecedor. Permite migração entre DataDog, Splunk, Jaeger sem refazer instrumentação.
Observabilidade funciona em monolito ou só em microserviços?
Funciona em ambos, mas é mais critica em microserviços (múltiplos serviços = múltiplas causas possíveis de problema). Em monolito, logs centralizados + métricas é geralmente suficiente.