Três Pilares da Observabilidade | Métricas, Logs e Traces Explicados

Quando uma requisição demora 5 segundos para responder, você tem três perguntas fundamentais: quando o problema começou, onde está o gargalo e o que causou a falha. Métricas detectam quando algo está quebrado através de anomalias na linha do tempo. Traces mostram onde e como a requisição trafegou entre serviços distribuídos. Logs diagnosticam o que aconteceu em detalhes. Juntos, eles formam a base da observabilidade moderna.

Sistemas distribuídos geram dados em múltiplas camadas, cada uma respondendo a uma pergunta diferente do fluxo de debugging. Isolar um pilar limita severamente a capacidade de investigação. A correlação entre métricas, logs e traces é a chave para diagnóstico eficaz em arquiteturas modernas.

O que são os Três Pilares da Observabilidade?

Os três pilares da observabilidade são métricas, logs e traces. Métricas são medidas numéricas agregadas ao longo do tempo. Logs são registros de eventos discretos com timestamps. Traces rastreiam o caminho de requisições através de sistemas distribuídos. Juntos, esses pilares permitem investigar problemas complexos correlacionando diferentes tipos de dados.

O conceito dos três pilares foi popularizado pela comunidade de observabilidade a partir de 2017, com contribuições significativas de engenheiros como Charity Majors, como uma forma de estruturar a telemetria necessária para entender sistemas distribuídos. Cada pilar captura uma dimensão diferente da realidade operacional do sistema, e a correlação entre eles cria uma visão completa.

Por que os Três Pilares são Complementares

Nenhum pilar isolado é suficiente para investigação de problemas em sistemas modernos. A correlação entre métricas, logs e traces cria observability verdadeira.

Fluxo de investigação SRE típico:

1. Métricas detectam a anomalia: “Latência P95 ultrapassou SLO às 14h32”
2. Traces localizam o gargalo: “Serviço de pagamento demorou 1,8s na validação de banco de dados”
3. Logs diagnosticam a causa: “Stack trace de timeout de conexão com o banco de dados”

Isoladamente, cada pilar oferece uma visão parcial. Correlacionados, eles formam um sistema completo de investigação.

Métricas (Metrics)

Métricas são medidas numéricas agregadas ao longo do tempo, representando o estado do sistema em formato de séries temporais. Elas respondem perguntas quantitativas sobre o comportamento do sistema: “qual a taxa de erro atual?”, “a latência está dentro do SLO?”, “quantas requisições por segundo estamos processando?”.

Características fundamentais:

• Agregação: Dados são resumidos em médias, somas, percentis
• Timestamped: Cada ponto tem um carimbo de tempo preciso
• Low cardinality: Poucos valores únicos por dimensão de label
• Compressíveis: Ocupam pouco espaço de armazenamento
• Query rápida: Operações matemáticas em tempo real

Tipos de Métricas

Counters (Contadores) são valores que só aumentam ao longo do tempo, contando eventos cumulativos.

• Total de requisições HTTP processadas
• Total de erros ocorridos
• Bytes transferidos acumulados

Use cases: Calcular taxas (requests per second), frequência de eventos, throughput.

Gauges (Indicadores) são valores que podem subir ou descer, representando um estado momentâneo.

• Uso de CPU em porcentagem
• Memória disponível em MB
• Conexões ativas no momento
• Tamanho de fila atual

Use cases: Monitorar capacidade, utilização de recursos, estado atual do sistema.

Histograms (Histogramas) agrupam valores em buckets predefinidos, permitindo calcular distribuição e percentis.

• Latência de requisições (P50, P95, P99)
• Tamanho de payloads
• Tempo de processamento

Use cases: SLIs de performance, entender distribuição de valores, detectar outliers.

Summaries (Resumos) são similares a histograms, mas calculam percentis no lado do cliente antes de enviar.

• Request duration percentis calculados localmente
• Response size percentis

Use cases: Alta precisão de percentis quando você não quer depender de buckets predefinidos.

Golden Signals

Os “golden signals” do Google SRE são as 4 métricas mais importantes para qualquer sistema:

1. Latência: Tempo para responder requisições
2. Tráfego: Volume de requisições (requests per second)
3. Erros: Taxa de requisições com erro
4. Saturação: Quão “cheio” está o sistema (CPU, memória, conexões)

Essas métricas formam a base para dashboards de saúde e alertas de SLOs.

Explosão de Cardinalidade em Métricas

O maior desafio técnico em sistemas de métricas é a explosão de cardinalidade — o crescimento do número de séries temporais quando dimensões com muitos valores únicos são adicionadas.

Em sistemas como Prometheus, o número total de séries temporais ativas (S_total) depende exclusivamente do produto cartesiano das dimensões de metadados (labels):

S_total = ∏(i=1 to n) |C_i|

Onde |C_i| é o número de valores únicos para cada dimensão de label.

Exemplo prático: Se você tem 10 endpoints (|C_1| = 10), 5 métodos HTTP (|C_2| = 5), e 3 ambientes (|C_3| = 3), o número de séries é 10 × 5 × 3 = 150.

Importante: O volume de requisições (V) não afeta o número de séries. Se um único usuário fizer um milhão de requisições idênticas com os mesmos labels, o sistema gerará apenas uma única série temporal. O volume apenas atualiza os valores dos contadores e gauges existentes.

Mitigações para cardinalidade alta:

• Limitar número de labels por métrica (ex: máximo 10)
• Usar top-K aggregation para manter apenas os K valores mais frequentes
• Pré-agregar dados de alta cardinalidade antes de exportar
• Mover dados de alta cardinalidade (user_id, request_id) para logs e traces

Consequência: Adicionar um label como user_id com 1 milhão de valores únicos criaria 1 milhão de séries temporais — geralmente inviável.

Logs

Logs são registros imutáveis e timestamped de eventos discretos que ocorreram no sistema. Cada log entry captura um momento específico com contexto detalhado, respondendo perguntas como “o que aconteceu exatamente às 14h32min?” e “qual foi a stack trace do erro?”.

Características fundamentais:

• Imutáveis: Uma vez escritos, não podem ser alterados
• Timestamped: Cada entrada tem carimbo de tempo preciso (milissegundos)
• High cardinality: Podem conter IDs únicos, mensagens específicas
• Context-rich: Incluem metadados, stack traces, dados do evento
• Auditáveis: Formam trilhas para compliance e investigação

Estrutura de um Log

Log não-estruturado (difícil de parsear):

[2026-06-01 14:32:15] ERROR Payment failed for user 789: timeout

Log estruturado (fácil de buscar e correlacionar):

{
  "timestamp": "2026-06-01T14:32:15.123Z",
  "level": "ERROR",
  "service": "payment-api",
  "trace_id": "abc123def456",
  "span_id": "span456",
  "user_id": "user_789",
  "message": "Payment processing failed",
  "error": "connection timeout",
  "stack_trace": "java.net.ConnectException...",
  "duration_ms": 5432
}

Log Levels (Níveis de Severidade)

• DEBUG: Informação detalhada para debugging durante desenvolvimento
• INFO: Eventos informativos de negócio (request received, order created)
• WARN: Condições potencialmente problemáticas, mas não erros
• ERROR: Erros que não interrompem operação do sistema
• FATAL: Erros críticos que interrompem operação

Melhor prática: Use níveis consistentemente. DEBUG em desenvolvimento, INFO/WARN/ERROR em produção.

Structured Logging

Logs estruturados usam formato de dados estruturado (JSON, protobuf) em vez de texto livre. Isso permite:

• Queries precisas: Buscar por campo específico (level: ERROR AND service: payment)
• Correlação automática: Cruzar trace_id entre logs e traces
• Parsing eficiente: Ferramentas processam automaticamente
• Integração com SIEM: Splunk, Datadog, Elasticsearch entendem nativamente

Benefícios práticos:

• Reduz tempo de debugging de horas para minutos
• Permite dashboards dinâmicos baseados em qualquer campo
• Facilita compliance (PCI-DSS, GDPR exigem trilhas auditáveis)

Correlation IDs

Incluir IDs de correlação em logs permite rastrear requisições através de múltiplos serviços e entradas de log:

{
  "trace_id": "abc123def456",
  "span_id": "span456",
  "parent_span_id": "span123",
  "user_id": "user_789",
  "request_id": "req999",
  ...
}

Esses IDs conectam logs, traces e métricas, criando uma visão unificada do evento.

Context Enrichment

Adicionar contexto enriquece logs para debugging mais eficiente:

• User context: user_id, session_id, tenant_id, account_type
• Request context: request_id, trace_id, http_method, path, query_params
• System context: host, service, version, environment, region
• Business context: order_id, cart_id, transaction_id, payment_method

Quanto mais contexto, mais rápida a investigação.

Traces (Distributed Tracing)

Traces representam o caminho completo de uma requisição através de múltiplos serviços em um sistema distribuído. Eles conectam eventos de diferentes sistemas em uma jornada unificada, respondendo perguntas como “por que essa requisição demorou 2 segundos?” e “quais serviços foram chamados?”.

Características fundamentais:

• End-to-end: Do início ao fim de uma requisição
• Cross-service: Atravessa múltiplos serviços, bancos de dados, caches
• Causal: Mostra relação de causa e efeito entre operações
• Temporal: Cada passo tem timestamp e duração precisos

Trace ID e Span ID

Trace ID é o identificador único para uma requisição completa, compartilhado entre todos os serviços envolvidos. Permite agrupar todos os eventos de uma única jornada.

Span ID é o identificador único para cada operação individual dentro do trace. Cada span representa uma unidade de trabalho.

Parent Span ID conecta spans em uma árvore de dependências, mostrando a hierarquia de chamadas.

Estrutura de um trace:

Trace: abc123def456 [duration: 50ms]
├── Span: span001 (API Gateway) [0ms - 50ms]
│   ├── Span: span002 (Auth Service) [10ms - 25ms]
│   └── Span: span003 (Payment Service) [30ms - 45ms]
│       ├── Span: span004 (Database Query) [35ms - 38ms]
│       └── Span: span005 (Cache Lookup) [40ms - 42ms]

Context Propagation

Context propagation é o mecanismo de passar trace ID, span ID e outros metadados entre serviços para conectar spans em uma jornada unificada.

Mecanismos de propagação:

• HTTP Headers: traceparent, tracestate (padrão W3C Trace Context)
• gRPC Metadata: Chave-valor no metadata do RPC
• Message Headers: Headers em sistemas de mensageria (Kafka, RabbitMQ, SQS)

Exemplo W3C Trace Context:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: vendor=value

O padrão W3C Trace Context garante interoperabilidade entre sistemas e ferramentas de diferentes vendors.

Sampling (Amostragem)

Coletar 100% dos traces é inviável para sistemas de alto volume. Amostragem reduz custo de armazenamento e processamento.

Tipos de sampling:

• Head-based sampling: Decisão tomada no início do trace (mais eficiente, pode perder traces de erros)
• Tail-based sampling: Decisão no fim do trace (mais inteligente, captura erros e latência alta)
• Adaptive sampling: Ajusta taxa dinamicamente baseado em volume e orçamento

Taxas típicas de amostragem:

• 0.1% - 1% para sistemas de alto volume (10k+ RPS)
• 10% - 50% para sistemas médios
• 100% para sistemas críticos ou baixo volume

Dica prática: Sempre capture 100% de traces com erro e latência alta, mesmo em sistemas de alto volume.

Casos de Uso para Traces

• Identificar gargalos de latência (qual serviço está lento?)
• Visualizar dependências entre serviços
• Debuggar falhas em cascata (service A falhou porque service B está down)
• Otimizar caminhos críticos de performance
• Entender fluxo de dados em arquiteturas de microserviços

A Sinergia dos Três Pilares

A correlação entre métricas, logs e traces através de IDs compartilhados é o que transforma dados isolados em observability verdadeira.

Fluxo de Investigação Correlacionado

Cenário: Latência P95 aumentou de 100ms para 2 segundos.

1. Métricas detectam anomalia: Dashboard mostra latência P95 > SLO às 14h32
2. Traces localizam serviço: Trace ID abc123 mostra Payment Service demorou 1.8s
3. Logs diagnosticam causa: Logs com trace_id abc123 revelam timeout na conexão com banco de dados

Correlação via trace_id:

// Métrica agregada
{ "metric": "latency_p95", "value": 2000, "service": "payment", "timestamp": "..." }

// Log correlacionado
{ "trace_id": "abc123", "level": "ERROR", "message": "timeout", "service": "payment" }

// Trace correlacionado
{ "trace_id": "abc123", "spans": [...], "duration_ms": 2000, "service": "payment" }

Quando Usar Cada Pilar

Além dos Três Pilares: OpenTelemetry

O modelo dos três pilares está evoluindo para sinais correlacionados através do OpenTelemetry, o padrão aberto da CNCF para telemetria unificada.

Problemas dos Pilares Isolados

• Logs, métricas e traces em ferramentas separadas
• Correlação manual entre sistemas
• Duplicação de instrumentação de código
• Vendor lock-in com ferramentas proprietárias

Solução OpenTelemetry

OpenTelemetry unifica a coleta dos três pilares em uma única API e SDK:

• Traces API: Coletar traces e spans com context propagation
• Metrics API: Coletar métricas com instrumentação automática
• Logs API: Coletar logs estruturados (em desenvolvimento ativo)
• Baggage: Contexto compartilhado entre todos os sinais

Benefícios:

• Uma instrumentação para todos os sinais: Não duplicar código
• Correlação nativa: Logs, métricas e traces conectados automaticamente
• Vendor-neutral: Funciona com qualquer backend (Prometheus, Jaeger, Datadog, etc.)
• Elimina vendor lock-in: Mesma instrumentação roda localmente, em nuvem, ou em runtimes distribuídos compatíveis com WinterCG

Status do OpenTelemetry:

• Tracing: Generally Available (GA)
• Metrics: Generally Available (GA)
• Logs: Em desenvolvimento ativo (beta)

Padrão W3C Trace Context

O padrão W3C Trace Context garante interoperabilidade entre sistemas:

• Format padronizado para traceparent e tracestate
• Suportado por todos os principais frameworks e ferramentas
• Permite propagar contexto entre sistemas heterogêneos

Isso significa que você pode usar OpenTelemetry para instrumentar seu código e escolher qualquer backend posteriormente sem reescrever instrumentação.

Coleta de Telemetria em Arquiteturas Distribuídas

Em sistemas distribuídos globalmente, coletar métricas, logs e traces de múltiplas regiões introduz latência que pode inviabilizar resposta rápida a incidentes.

Processamento Distribuído de Telemetria

Processar dados de telemetria diretamente na infraestrutura distribuída oferece vantagens significativas:

• Coleta com latência ultrabaixa: Eventos disponíveis em menos de 60 segundos
• Streaming unificado: Logs, métricas e eventos em um único fluxo
• Correlação automática: Trace IDs e request IDs conectados nativamente
• Múltiplos destinos: Splunk, Datadog, BigQuery, S3, Azure Monitor

Protocolos de Transporte Modernos

A ingestão e streaming de telemetria depende criticamente dos protocolos de transporte:

Limitações do TCP:

• Head-of-line blocking: Perda de pacotes paralisa toda a conexão
• Handshake overhead: Três-way handshake adiciona latência
• Congestion control agressivo: Backoff excessivo em redes com perda

Vantagens do QUIC/HTTP3:

O protocolo QUIC (Quick UDP Internet Connections), base do HTTP/3, resolve essas limitações:

• Sem head-of-line blocking: Streams independentes não se afetam mutuamente
• 0-RTT connection resumption: Retomar conexões instantaneamente
• Multiplexação nativa: Múltiplos streams em uma única conexão
• Mudança de rede seamless: Migração de IP sem quebra de conexão

Impacto prático: Streaming de logs e eventos via QUIC/HTTP3 elimina o impacto do head-of-line blocking, garantindo que métricas em tempo real e logs de cibersegurança cheguem aos destinos analíticos (SIEM) em menos de 60 segundos, mesmo sob condições de rede instáveis.

WebSockets para Latência Sub-segundo

Suporte nativo a WebSockets permite que dashboards de monitoramento e sistemas de telemetria interativa atualizem dados em tempo real com latência de sub-segundo, sem polling HTTP.

Cases de Sucesso: Três Pilares na Prática

Netshoes: 385 TB de Logs e Eventos Correlacionados

A Netshoes é o maior e-commerce de lifestyle esportivo da América Latina, com 54 milhões de visitantes únicos por mês.

Uso dos três pilares:

• Métricas: Monitoramento de latência, taxas de erro, throughput em tempo real
• Logs: 385 TB de eventos coletados via Data Streaming em 6 meses
• Traces: Correlação de requisições end-to-end para debugging

Resultados verificados:

• 4 milhões de ameaças bloqueadas automaticamente pelo WAF no primeiro semestre de 2020
• 84% do processamento transferido para infraestrutura distribuída, com 200 bilhões de requisições processadas
• Correlação de logs com métricas de WAF para inteligência de segurança

Magalu: 20 TB/mês Correlacionados em Tempo Real

O Magazine Luiza é uma das empresas de varejo mais inovadoras da América Latina, com R$ 10 bilhões em vendas digitais em 2021.

Uso dos três pilares:

• Métricas: Dashboards de disponibilidade e performance para centenas de aplicações
• Logs: 20 TB/mês via Data Streaming enviados para plataformas SIEM
• Traces: Investigação de incidentes cross-service durante eventos críticos

Resultados verificados:

• Milhões de ameaças bloqueadas automaticamente
• Alta disponibilidade garantida durante Black Friday e Liquidação Fantástica
• Correlação de eventos de WAF com métricas de negócio em tempo real

Comparativo: Métricas vs Logs vs Traces

Perguntas Frequentes sobre os Três Pilares

O que são os três pilares da observabilidade?

Os três pilares são métricas, logs e traces. Métricas são medidas numéricas agregadas ao longo do tempo (como latência, taxa de erro). Logs são registros de eventos discretos com timestamps e contexto detalhado. Traces rastreiam o caminho de requisições através de sistemas distribuídos, conectando múltiplos serviços em uma jornada unificada.

Qual a diferença entre métricas, logs e traces?

Métricas agregam valores numéricos (ex: latência média), sem contexto individual de cada evento. Logs capturam eventos específicos com detalhes ricos (ex: stack trace, user_id). Traces conectam eventos através de múltiplos serviços, mostrando a jornada completa de uma requisição. Use métricas para tendências e alertas, logs para debugging detalhado, e traces para entender fluxo em sistemas distribuídos.

Quando usar métricas, logs ou traces?

Use métricas para dashboards, alertas e análise de tendências (ex: latência P95 > SLO). Use logs para debugging detalhado, auditoria e compliance (ex: quem executou essa ação, qual foi o erro específico). Use traces para investigar latência, dependências e falhas em cascata (ex: qual serviço está lento, como a falha propagou). Idealmente, correlacione os três pilares via trace IDs.

O que é distributed tracing?

Distributed tracing rastreia requisições através de múltiplos serviços em arquiteturas distribuídas. Cada requisição recebe um trace ID único compartilhado entre todos os serviços, e cada operação dentro dela é um span. Isso permite visualizar a jornada completa, identificar gargalos de latência e entender como falhas se propagam entre serviços.

O que são logs estruturados?

Logs estruturados usam formato de dados estruturado (como JSON) em vez de texto livre. Cada campo tem um nome e valor definidos (ex: {"level": "ERROR", "user_id": "123", "message": "timeout"}). Isso permite queries mais rápidas e precisas, correlação automática entre campos, parsing por ferramentas de análise, e integração nativa com SIEM.

Como correlacionar métricas, logs e traces?

Use IDs de correlação compartilhados entre os três pilares. Inclua trace_id, span_id, e request_id em logs e traces. Use trace IDs para agrupar spans em uma jornada. Métricas podem ser filtradas por service name e correlacionadas com traces e logs do mesmo período. Ferramentas como OpenTelemetry facilitam correlação automática.

Qual a ferramenta mais importante: métricas, logs ou traces?

Nenhuma é mais importante — elas são complementares. Métricas detectam que há um problema, logs diagnosticam o que aconteceu, e traces mostram onde e como aconteceu. Sistemas maduros usam os três pilares correlacionados via trace IDs. Comece com métricas (golden signals), adicione logs estruturados, e implemente tracing para sistemas distribuídos.

Conclusão

Os três pilares da observabilidade — métricas, logs e traces — formam a base para investigação de problemas em sistemas distribuídos modernos.

Próximos passos recomendados:

Para iniciantes:

1. Implemente golden signals: latência, tráfego, erros, saturação
2. Use structured logging (JSON) com correlation IDs
3. Comece com métricas, depois adicione logs e traces

Para times intermediários:

1. Adicione distributed tracing em serviços críticos
2. Correlacione logs e traces via trace IDs
3. Defina SLOs baseados em métricas

Para times avançados:

1. Adote OpenTelemetry para instrumentação unificada
2. Implemente correlação automática entre pilares
3. Use Data Streaming para análise em tempo real

Quer correlacionar métricas, logs e traces em tempo real com latência ultrabaixa? Conheça como Data Stream, Real-Time Events e Real-Time Metrics podem transformar sua visibilidade operacional em uma arquitetura distribuída global. Comece grátis.