O Modelo de Correlação de Observabilidade
Cada página nesta seção pode parecer uma lista de compras de ferramentas - structlog para logs, prometheus_client para métricas, OpenTelemetry para traces, Sentry para erros - cada uma com sua própria biblioteca e seus próprios passos de configuração.
Noções Básicas de Observabilidade já aborda essa sintaxe em todos os quatro.
O que os une em uma prática coerente, em vez de quatro integrações não relacionadas, é um modelo: os mesmos eventos subjacentes são observados de diferentes ângulos, correlacionados por identificadores compartilhados, e cada ângulo tem sua própria estrutura de custo que decide quanto dele você pode pagar para manter.
Entender esse modelo muda para qual pilar você recorre primeiro quando algo quebra, e por que "apenas registrar tudo" ou "apenas rastrear tudo" eventualmente param de funcionar como estratégia.
Resumo
- Logs, métricas e traces são três visualizações diferentes da mesma requisição ou tarefa, conectadas por identificadores de correlação compartilhados, não três fontes de verdade independentes.
- Por que Importa: Sem um identificador compartilhado que percorra os três, uma investigação de incidente degenera em adivinhar quais linhas de log, qual pico no dashboard e qual trace lento pertencem ao mesmo evento.
- Conceitos Chave: ID de correlação, cardinalidade, sinal vs. ruído, liveness vs. readiness, as três perguntas (o que aconteceu, com que frequência e quão rápido, onde o tempo foi gasto).
- Quando Usar Este Modelo: Para decidir em qual pilar adicionar instrumentação, projetar o que uma linha de log ou atributo de span deve carregar, e estruturar um runbook de resposta a incidentes.
- Limitações / Trade-offs: Cada pilar tem um custo real - logs custam armazenamento e tempo de consulta, métricas custam cardinalidade, traces custam decisões de amostragem - então "instrumentar tudo" não é uma estratégia gratuita em qualquer escala não trivial.
- Tópicos Relacionados: logging estruturado, métodos RED e USE, tracing distribuído, sondas de saúde e prontidão.
Fundamentos
Uma pergunta inicial útil não é "qual ferramenta de observabilidade devo usar", mas sim "qual pergunta estou realmente tentando responder".
Logs respondem "o que especificamente aconteceu" - um evento discreto e com timestamp, com detalhes arbitrários, como "pedido 4821 falhou na validação: endereço de entrega ausente".
Métricas respondem "com que frequência e quão rápido, em agregado" - um número rastreado ao longo do tempo, como uma contagem de requisições ou uma latência p99, sem detalhes específicos de uma única requisição.
Traces respondem "onde o tempo foi realmente gasto, para esta requisição, em todos os serviços que ela tocou" - o caminho causal e hierárquico de uma operação.
Um quarto pilar, menor - verificações de integridade - responde a um tipo de pergunta completamente diferente: não "o que aconteceu", mas "esta instância está apta a servir tráfego agora", uma pergunta operacional no tempo presente que os outros três não respondem diretamente.
Nenhum desses quatro é um substituto para outro; uma métrica pode dizer que a taxa de erros aumentou às 14:02, mas apenas um log ou trace correlacionado pode dizer por que esse pico específico aconteceu.
Mecanismos e Interações
O mecanismo que transforma quatro sinais separados em uma investigação coerente é o identificador de correlação - mais comumente um request_id gerado na borda de uma requisição e um trace_id propagado por um sistema de tracing.
from contextvars import ContextVar
request_id: ContextVar[str] = ContextVar("request_id", default="-")
# cada linha de log emitida durante esta requisição inclui o request_id,
# então uma busca de log por um ID reconstrói a história completa da requisiçãoUma vez que esse identificador é anexado a cada linha de log de uma requisição, presente como um atributo nos spans de trace relevantes e disponível como um rótulo (cuidadosamente, dadas as limitações de cardinalidade abaixo) para pelo menos métricas de nível de erro, uma resposta a incidentes segue um caminho previsível: um alerta de métrica diz que algo está errado e aproximadamente quando, uma busca de log com escopo para a janela de tempo afetada e request_id diz especificamente o que aconteceu, e um trace para o mesmo ID diz onde o tempo ou a falha realmente ocorreram entre os serviços.
Cardinalidade é o maior fator de custo em todos os três pilares, e é fácil de raciocinar incorretamente sobre ela.
Um rótulo de métrica com valores ilimitados - um ID de usuário bruto, uma URL completa com parâmetros de consulta, um UUID - multiplica o número de séries temporais distintas que um backend de métricas precisa armazenar, muitas vezes transformando um contador barato em um problema de armazenamento e consulta; a mesma lógica se aplica a atributos de span em um backend de tracing.
É por isso que métricas no estilo Prometheus usam um conjunto pequeno e limitado de valores de rótulo (method, status_code, endpoint) em vez de identificadores por requisição, e por que detalhes de alta cardinalidade pertencem a logs e atributos de trace, onde são esperados e precificados de forma diferente.
A amostragem existe pela mesma razão subjacente no lado do tracing: registrar cada span para cada requisição em tráfego de produção real é caro para armazenar e consultar, então a maioria das configurações de tracing mantém apenas uma fração dos traces, geralmente com viés para manter aqueles que falharam ou foram lentos.
Considerações Avançadas e Aplicações
Os métodos RED (Rate, Errors, Duration - Taxa, Erros, Duração) e USE (Utilization, Saturation, Errors - Utilização, Saturação, Erros) são duas lentes comuns para decidir quais métricas rastrear, e escolher a errada para um determinado componente produz dashboards que parecem ocupados, mas não respondem a perguntas operacionais.
RED se encaixa bem em serviços orientados a requisições, já que taxa, taxa de erros e duração por endpoint mapeiam diretamente para o que um chamador experimenta.
USE se encaixa melhor em recursos como pools de conexão, filas e workers, já que utilização e saturação capturam problemas (um pool a 95% de capacidade) antes que eles apareçam como erros.
Verificações de integridade interagem com os outros três pilares principalmente na fronteira de um orquestrador, não dentro de uma investigação de incidente: uma falha na sonda de prontidão é frequentemente o primeiro sinal semelhante a métrica (taxa de falha da sonda) que aciona uma investigação mais profunda de log e trace - veja Saúde e Prontidão para a distinção entre liveness e readiness na qual isso depende.
Ferramentas de rastreamento de erros como Sentry ficam em uma interseção interessante de logs e métricas: elas agregam eventos de exceção (semelhantes a logs, com detalhes completos) em problemas agrupados com contagens de ocorrência e tendências (semelhantes a métricas), que é por que elas tendem a se tornar o primeiro lugar onde os engenheiros procuram após um alerta de métrica disparar, antes de logs brutos.
À medida que um sistema escala além de um punhado de serviços, o próprio modelo de correlação se torna algo que vale a pena investir deliberadamente - um nome de campo consistente para o ID de correlação em cada serviço, formatador de log e biblioteca de tracing, decidido uma vez, economiza muito mais tempo de incidente do que qualquer escolha de ferramenta única.
| Sinal | Força | Fraqueza | Melhor Uso |
|---|---|---|---|
| Logs | Detalhe arbitrário, barato de adicionar por evento | Caro para pesquisar em escala, logs não estruturados resistem à correlação | Raiz de um evento específico conhecido |
| Métricas | Barato para armazenar e alertar em agregado, ótimo para dashboards | Sem detalhes por requisição, cardinalidade limita o que pode ser um rótulo | Detectar que algo está errado e aproximadamente quanto |
| Traces | Mostra o caminho causal e o tempo exato entre serviços | Amostragem significa que algumas requisições nunca são capturadas; requer propagação em todos os lugares | Encontrar onde o tempo ou a falha ocorreu em uma chamada distribuída |
Conceitos Errôneos Comuns
- "Mais logging é sempre melhor observabilidade." Além de um ponto, logs não estruturados de alto volume se tornam caros para armazenar e lentos para pesquisar, escondendo ativamente o sinal que o levou a adicionar mais logging em primeiro lugar.
- "Métricas e traces são redundantes quando você tem um deles." Uma métrica mostra uma tendência em todas as requisições; um trace mostra o caminho específico de uma requisição - nenhum substitui o outro, eles respondem a perguntas diferentes em granularidades diferentes.
- "Uma verificação de integridade e um dashboard de métricas dizem a mesma coisa." Uma verificação de integridade é um sim/não no tempo presente sobre uma instância específica agora; um dashboard de métricas mostra tendências agregadas ao longo do tempo em todas as instâncias, razão pela qual uma instância pode estar "não íntegra" por segundos antes que qualquer tendência do dashboard a reflita.
- "A amostragem de traces significa que você perderá incidentes importantes." A amostragem bem projetada mantém deliberadamente uma fração maior de traces com erro ou lentos do que os de rotina, então os traces mais úteis durante um incidente são exatamente aqueles com menor probabilidade de serem descartados.
- "Cardinalidade só importa para métricas." O mesmo problema de rótulos ilimitados infla o custo em backends de tracing também - um atributo de span que contém um ID de usuário bruto ou corpo de requisição completo carrega o mesmo custo de cardinalidade que um rótulo de métrica teria.
FAQs
Qual pergunta cada pilar de observabilidade realmente responde?
- Logs: o que especificamente aconteceu, com detalhes arbitrários
- Métricas: com que frequência e quão rápido, em agregado, ao longo do tempo
- Traces: onde o tempo foi gasto, para uma requisição, em todos os serviços
- Verificações de integridade: esta instância pode servir tráfego agora
Por que os IDs de correlação são tão importantes para a resposta a incidentes?
Sem um identificador compartilhado conectando uma linha de log, um trace e um pico de métrica, não há como confirmar de forma confiável que eles descrevem o mesmo evento subjacente, em vez de uma coincidência não relacionada na mesma janela de tempo.
O que é cardinalidade, em termos simples?
O número de combinações distintas de valores de rótulo ou atributo que uma métrica ou trace pode ter; um rótulo com valores ilimitados (como um ID de usuário bruto) multiplica esse número e aumenta o custo de armazenamento e consulta muito mais rápido do que os mesmos dados adicionados como um campo de log fariam.
Por que não posso simplesmente colocar um request_id em cada rótulo de métrica?
Um rótulo de métrica deve ter um conjunto pequeno e limitado de valores possíveis para que um backend possa pré-agregar eficientemente; um request_id é efetivamente ilimitado, o que transforma um contador barato em uma série temporal por requisição e frustra o propósito de uma métrica.
Como RED e USE diferem, e quando devo usar cada um?
RED (Rate, Errors, Duration) se encaixa em serviços orientados a requisições onde a experiência do chamador se mapeia diretamente para esses três números; USE (Utilization, Saturation, Errors) se encaixa em recursos como pools, filas e workers, capturando saturação antes que ela se torne erros visíveis.
A amostragem em tracing é a mesma ideia da amostragem em logging?
Elas resolvem um problema de custo semelhante, mas geralmente de maneiras diferentes - a amostragem de tracing decide quais traces inteiros manter (frequentemente com viés para erros e alta latência), enquanto a amostragem de log, quando usada, geralmente apenas reduz o volume de linhas de log de rotina e de baixo valor.
Por que uma verificação de integridade precisa ser separada de um dashboard de métricas?
Uma verificação de integridade responde a uma pergunta no tempo presente sobre uma instância específica para a decisão de roteamento imediata de um orquestrador, enquanto um dashboard de métricas agrega tendências em todas as instâncias ao longo do tempo - útil para humanos investigando, não para um balanceador de carga decidindo se envia a próxima requisição.
Quando devo adicionar uma nova métrica versus um novo campo de log?
Adicione uma métrica quando precisar de agregação e alertas baratos e sempre ativos sobre muitos eventos; adicione um campo de log quando o valor for de alta cardinalidade ou só for útil ao investigar um evento específico conhecido.
Por que rastreadores de erros como Sentry parecem diferentes de logs e métricas?
Eles agregam eventos de exceção individuais (detalhes semelhantes a logs) em problemas agrupados com tendências de ocorrência (estrutura semelhante a métricas), que é por que eles frequentemente se tornam a primeira parada após um alerta de métrica, antes de logs brutos.
Adotar tracing distribuído torna o logging estruturado desnecessário?
Não - traces mostram bem o tempo e a estrutura causal, mas logs ainda carregam os detalhes de negócios arbitrários ("qual campo falhou na validação") que os spans estruturados de um trace não são projetados para conter.
Qual é o maior erro que as equipes cometem ao escalar a observabilidade?
Instrumentar mais de tudo sem primeiro concordar com um identificador de correlação consistente e nomenclatura de campos em todos os serviços, o que torna difícil conectar os sinais quando há o suficiente deles para importar.
Existe tal coisa como instrumentação demais?
Sim - além de um ponto, volume excessivo de logs, cardinalidade de métricas ou criação de spans adiciona custo real de armazenamento e consulta sem um aumento proporcional no que você pode realmente aprender de um incidente.
Relacionados
- Noções Básicas de Observabilidade - exemplos práticos em logs, métricas, traces e saúde
- Logging Estruturado - a implementação do lado do log de identificadores de correlação
- Métricas - métricas RED/USE e os limites de cardinalidade descritos nesta página
- Tracing Distribuído - propagação de trace e amostragem em profundidade
- Saúde e Prontidão - a questão liveness versus readiness que esta página separa dos outros três pilares
- Melhores Práticas de Observabilidade - a lista de verificação de sinal acionável destilada deste modelo
Versões de Stack: Esta página é conceitual e não está vinculada a uma versão específica de stack.