Monitoring vs. Observability: quando usar cada um

Imagine o seguinte cenário: uma grande plataforma de e-commerce enfrenta uma interrupção de 4 horas. O sistema de monitoramento mostra todos os servidores “verdes” — CPU normal, memória OK, disco disponível. Mas ninguém consegue fazer checkout. O problema? Uma incompatibilidade de versão entre dois microserviços que o monitoramento tradicional não conseguia detectar.

Este cenário ilustra por que a distinção entre monitoring e observability importa. Para grandes plataformas de e-commerce, uma interrupção em horários de pico pode custar milhões de dólares.

Monitoramento tradicional é eficaz para detectar condições previamente modeladas. Sistemas modernos sofrem de problemas que não foram previstos. Entender essa diferença é fundamental para escolher a abordagem adequada.

O que é Monitoring?

Monitoring é a prática de coletar, processar, agregar e exibir métricas predefinidas sobre o estado de um sistema. Seu objetivo principal é detectar condições conhecidas que indicam problemas ou degradação, respondendo perguntas como “o servidor está disponível?” e “CPU está acima de 90%?”.

Características fundamentais:

• Reativo: Responde a condições predefinidas após o fato
• Baseado em thresholds: Alertas configurados com limites fixos (ex: CPU > 90%)
• Orientado a dashboards: Visualização de métricas agregadas em tempo real
• Foco em simplicidade: Mais fácil de implementar em sistemas com arquitetura simples

Componentes típicos:

1. Coleta de métricas: CPU, memória, disco, rede, requisições por segundo
2. Agregação: Média, soma, min, max, percentis
3. Alertas: Notificações quando thresholds são ultrapassados
4. Dashboards: Visualização de séries temporais

Quando monitoring tende a ser suficiente:

• Sistemas monolíticos com arquitetura simples
• Infraestrutura estática (servidores fixos, poucas mudanças)
• Problemas bem conhecidos e recorrentes
• Requisitos básicos de disponibilidade (99% uptime)
• Times pequenos sem engenheiros de confiabilidade dedicados

Exemplo prático:

Alerta: CPU do servidor web-01 > 90% nos últimos 5 minutos
Dashboard: Requisições por segundo = 1.200
Dashboard: Taxa de erro = 0.5%

Limitação: Isso indica que há um problema, mas não necessariamente por que. Se o problema for uma incompatibilidade entre serviços, thresholds de CPU não ajudarão na investigação.

O que é Observability?

Observability é uma propriedade de sistemas que permite inferir o estado interno examinando suas saídas externas. Em engenharia de software, isso significa a capacidade de fazer perguntas arbitrárias sobre o comportamento do sistema sem precisar prever essas perguntas antecipadamente.

O termo vem da teoria de controle, introduzido por Rudolf E. Kalman em 1960. Um sistema é observável se você pode determinar seu estado interno medindo suas saídas. Na engenharia de software, foi popularizado por Charity Majors a partir de 2017 como evolução necessária do monitoring tradicional para sistemas distribuídos.

Características fundamentais:

• Investigativa: Permite explorar problemas não previstos em tempo real
• Orientada a queries: Faça perguntas arbitrárias sem dashboards predefinidos
• Rica em contexto: Dados individuais com contexto detalhado (user_id, trace_id)
• Correlacional: Conecta eventos através de múltiplos sistemas
• Nativa para distribuídos: Projetada para arquiteturas de microserviços complexas

Os Três Pilares da Observability

Observability se apoia em três tipos de dados (pilares) complementares:

1. Métricas (Metrics):

• Medidas numéricas agregadas ao longo do tempo
• Respondem: “Qual a tendência? O sistema está saudável?”
• Exemplo: Latência P95, taxa de erro, throughput, cache hit rate
• Custo: Baixo (dados agregados, alta compressão)

2. Logs:

• Registros de eventos discretos com timestamps
• Respondem: “O que aconteceu exatamente neste momento?”
• Exemplo: Stack traces, mensagens de erro, eventos de negócio
• Custo: Alto (dados individuais, alto volume de armazenamento)

3. Traces (Rastreamento Distribuído):

• Rastreamento de requisições através de múltiplos serviços
• Respondem: “Como essa requisição trafegou? Onde está o gargalo?”
• Exemplo: Jornada do API Gateway → Auth Service → Payment Service → Database
• Custo: Médio (amostragem comum para controlar volume)

Juntos, esses pilares permitem investigação completa: métricas detectam anomalias, traces localizam serviços problemáticos, logs diagnosticam causas específicas.

Known Knowns, Known Unknowns, Unknown Unknowns

A diferença fundamental entre monitoring e observability fica clara ao categorizar tipos de problemas:

Known Knowns (o que sabemos que sabemos):

• “CPU está em 90%”
• “Disco está 80% cheio”
• “Servidor está down”
• “Taxa de erro aumentou para 5%”

→ Monitoring tradicional é adequado — perguntas predefinidas, alertas baseados em thresholds.

Known Unknowns (o que sabemos que não sabemos):

• “Por que a latência aumentou às 14h?”
• “Qual serviço está lento?”
• “Onde está o gargalo de performance?”
• “Qual usuário está sendo afetado?”

→ Observability é mais adequada — queries ad-hoc, correlação de dados, investigação dinâmica.

Unknown Unknowns (o que não sabemos que não sabemos):

• “A aplicação está falhando silenciosamente sem erros explícitos”
• “Usuários estão tendo experiência degradada que não detectamos”
• “Uma mudança de configuração causou degradação gradual ao longo de dias”
• “Uma feature nova introduziu incompatibilidade sutil entre serviços”

→ Observability é essencial — capacidade de investigar problemas que você nunca imaginou que poderiam existir.

Este é o ponto crucial: monitoring detecta condições que você previu que poderiam acontecer. Observability permite investigar problemas que você não previu.

Principais Diferenças entre Monitoring e Observability

MTTR e o Custo de Investigação

O tempo médio de resolução (MTTR) impacta diretamente o custo de indisponibilidade. Dois fatores principais determinam esse custo:

• MTTD (Mean Time to Detect): Tempo médio para detectar que há um problema
• MTTR (Mean Time to Resolve): Tempo médio para restaurar o sistema após a detecção

Monitoring tradicional foca em reduzir o tempo de detecção para falhas óbvias (servidor down, CPU alto). Observability tende a reduzir tanto o tempo de detecção quanto o tempo de resolução para falhas complexas e silenciosas — problemas que podem demorar horas para detectar e dias para resolver sem correlação de dados.

Exemplo ilustrativo: Uma falha silenciosa que demora 4 horas para detectar e 2 horas para resolver (total de 6 horas), com custo de US$ 100.000 por hora, resulta em prejuízo de US$ 600.000. Com observability bem implementada, a mesma investigação pode levar 30 minutos para detectar e 30 minutos para resolver — reduzindo o custo para US$ 100.000.

Monitoring e Observability Trabalham Juntos

Observability não substitui monitoring — estende e complementa:

Fase 1: Monitoring básico

• Métricas de infraestrutura (CPU, memória, disco, rede)
• Alertas por threshold
• Dashboards fixos

Fase 2: APM (Application Performance Monitoring)

• Métricas de aplicação (latência, throughput, erros)
• Distributed tracing básico
• Correlação parcial

Fase 3: Observability completa

• Três pilares correlacionados (métricas, logs, traces)
• Queries ad-hoc dinâmicas
• Contexto rico em cada evento
• SLOs baseados em experiência do usuário

Recomendação prática: Comece com monitoring, adicione observability conforme a complexidade do sistema aumenta. Não pule etapas — cada fase constrói sobre a anterior.

Quando Usar Cada Abordagem

Cenários onde Monitoring é Adequado

Monitoring tende a ser suficiente quando:

1. Sistemas monolíticos: Arquitetura simples, poucas dependências, fluxo de dados linear
2. Infraestrutura estática: Número fixo de servidores e serviços, mudanças infrequentes
3. Problemas conhecidos: Você sabe o que pode dar errado e como detectar
4. Alertas básicos: CPU, memória, disco, disponibilidade são suficientes
5. Budget limitado: Custo de infraestrutura precisa ser baixo
6. Time pequeno: Sem engenheiros de confiabilidade dedicados, equipe generalista
7. SLAs simples: Apenas disponibilidade básica (99% uptime)

Exemplo: Uma aplicação web simples com 3 servidores, banco de dados único, sem microserviços.

Cenários que se Beneficiam de Observability

Observability tende a ser essencial quando:

1. Arquiteturas distribuídas: Microserviços, containers, serverless functions
2. Sistemas dinâmicos: Containers são criados e destruídos constantemente, escala automática
3. Problemas desconhecidos: Você não sabe o que pode dar errado — e isso é normal
4. SLAs rigorosos: 99.9%+ disponibilidade, latência < 100ms, SLOs específicos
5. Investigação profunda: Root cause analysis em minutos, não horas ou dias
6. Experiência do usuário: Correlacionar métricas técnicas com UX real (Core Web Vitals)
7. Compliance: Auditoria detalhada de eventos, trilhas para PCI-DSS, GDPR
8. Automação: AIOps, resposta automática a incidentes

Exemplo: Uma plataforma de e-commerce com 50+ microserviços, múltiplos bancos de dados, caches distribuídos, APIs externas, fluxos de pagamento assíncronos.

Como Evoluir de Monitoring para Observability

A evolução para observability requer planejamento gradual. Aqui está um roteiro prático:

1. Comece pelos Golden Signals

Os “golden signals” do Google SRE são um ponto de partida eficaz:

• Latência: Tempo para atender requisições
• Tráfego: Requisições por segundo
• Erros: Taxa de requisições com erro
• Saturação: Uso de recursos (CPU, memória, disco)

Implemente esses sinais primeiro nos serviços mais críticos.

2. Implemente Logs Estruturados

Logs em formato JSON com campos consistentes facilitam correlação:

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "error",
  "service": "payment-service",
  "trace_id": "abc123",
  "user_id": "user-456",
  "message": "Payment timeout after 30s"
}

Boas práticas:

• Use timestamps em ISO 8601
• Inclua trace_id em todos os logs
• Padronize nomes de campos
• Evite logs não-estruturados

3. Adicione Distributed Tracing

Propague trace IDs através de todos os serviços:

• Use o padrão W3C Trace Context (traceparent header)
• Instrumente pontos de entrada (API gateways, load balancers)
• Propague contexto através de HTTP headers, mensagens, etc.
• Comece pelos serviços mais críticos

4. Defina SLOs Baseados em Experiência

Service Level Objectives traduzem métricas técnicas em experiência do usuário:

• SLI (Service Level Indicator): Métrica que mede comportamento (ex: latência P95)
• SLO (Service Level Objective): Meta para o SLI (ex: 99% das requisições < 200ms)
• SLA (Service Level Agreement): Compromisso contratual com consequências

Exemplo: “99.9% das requisições de checkout devem completar em menos de 2 segundos”

5. Considere OpenTelemetry

OpenTelemetry fornece instrumentação unificada e vendor-neutral:

• Uma instrumentação, múltiplos backends
• Padrão aberto com suporte da CNCF
• APIs para métricas, logs e traces
• Exportadores para diversas ferramentas

Isso reduz vendor lock-in e facilita migração entre ferramentas.

Boas Práticas e Armadilhas Comuns

Boas Práticas

Comece pequeno:

• Instrumente serviços críticos primeiro
• Evite instrumentar tudo de uma vez
• Itere baseado em incidentes reais

Use amostragem inteligente:

• Traces 100% para erros
• Amostragem proporcional para sucesso
• Ajuste baseado em volume e custo

Correlacione dados:

• Trace IDs em logs e métricas
• User IDs para contexto de negócio
• Tags consistentes entre pilares

Monitore o monitoramento:

• Alertas funcionando?
• Dados chegando?
• Dashboards atualizados?

Armadilhas Comuns

Cardinalidade alta:

• Métricas com muitas combinações de labels explodem custos
• Exemplo: user_id como label de métrica → milhões de séries temporais
• Solução: Use logs para alta cardinalidade, métricas para agregados

Retenção insuficiente:

• Logs deletados antes de investigar incidentes
• Métricas com granularidade perdida após poucos dias
• Solução: Defina retenção baseada em SLAs e requisitos de compliance

Instrumentação inconsistente:

• Nomes de serviços diferentes em logs vs métricas
• Formatos de timestamp variados
• Solução: Padronize convenções antes de escalar

Custo sem controle:

• Volume de dados crescendo sem limite
• Ferramentas duplicadas
• Solução: Defina orçamento, use amostragem, consolide ferramentas

Comparativo: Fluxo de Investigação

Cenário: Usuários reportam lentidão no checkout, mas métricas de CPU e memória estão normais.

Diferença crítica: Monitoring pode indicar “não há problema” (falso negativo). Observability detecta e localiza o problema real.

Perguntas Frequentes

Qual a principal diferença entre monitoring e observability?

Monitoring é uma ação reativa que coleta métricas predefinidas para detectar condições conhecidas. Observability é uma propriedade do sistema que permite fazer perguntas arbitrárias sobre seu estado interno, investigando até problemas não previstos através da correlação de logs, métricas e traces. Monitoring responde “o sistema está saudável?”, observability responde “por que não está saudável?”.

Observability substitui monitoring?

Não, observability complementa e estende o monitoring tradicional. Você continua precisando de alertas básicos de infraestrutura (CPU, memória, disco, disponibilidade), mas observability adiciona capacidade de investigação profunda em sistemas distribuídos complexos. Eles não são mutuamente exclusivos — são evolutivos.

Quais são os 3 pilares da observabilidade?

Os três pilares são: Métricas (dados numéricos agregados como latência P95, taxa de erro, throughput), Logs (registros de eventos discretos com contexto detalhado como stack traces, user_id, trace_id) e Traces (rastreamento de requisições através de múltiplos serviços, mostrando a jornada completa). Juntos, permitem investigação completa de problemas.

Quando usar monitoring ou observability?

Use monitoring para sistemas simples, arquitetura monolítica, problemas conhecidos, alertas básicos de infraestrutura, times pequenos. Use observability para sistemas distribuídos complexos, microserviços, problemas desconhecidos, investigação profunda, SLAs rigorosos (99.9%+), times SRE/DevOps. A evolução natural é começar com monitoring e adicionar observability conforme a complexidade aumenta.

O que são “unknown unknowns” em observability?

“Unknown unknowns” são problemas que você não sabe que existem e não previu que poderiam acontecer. Monitoring tradicional detecta “known unknowns” (problemas que você previu e configurou alertas). Observability permite investigar até mesmo problemas que você nunca imaginou que poderiam ocorrer — como uma incompatibilidade sutil entre serviços que degrada performance gradualmente sem erros explícitos.

Qual o papel do APM em monitoring vs observability?

APM (Application Performance Monitoring) é uma evolução do monitoring tradicional que adiciona distributed tracing e métricas de aplicação. É uma etapa intermediária entre monitoring básico e observability completa. APM ainda foca em perguntas predefinidas e dashboards fixos, enquanto observability permite queries arbitrárias e investigação de problemas não previstos.

Como migrar de monitoring para observability?

Comece implementando os três pilares gradualmente: (1) Métricas com golden signals (latência, tráfego, erros, saturação), (2) Logs estruturados com correlation IDs em formato JSON, (3) Distributed tracing em serviços críticos. Use OpenTelemetry para instrumentação unificada e vendor-neutral. Estabeleça cultura de investigação baseada em dados, com SLOs definidos. Não pule etapas — cada fase constrói sobre a anterior.

Conclusão

Monitoring e observability não são concorrentes — são evolutivos. Monitoring é necessário para detectar problemas óbvios. Observability é essencial para investigar problemas complexos em sistemas distribuídos.

Próximos passos para aprofundar:

1. Leia sobre os Três Pilares da Observabilidade
2. Explore o O que é Observabilidade?
3. Pratique implementando golden signals em um serviço crítico