Distributed tracing vs centralized logging: qual usar primeiro?

Quando uma loja virtual começa a operar com microserviços, o diagnóstico de erros muda de natureza. Um pedido que falha pode passar por cinco serviços diferentes, e cada um registra sua própria versão do problema. Distributed tracing e centralized logging são as duas respostas clássicas para esse caos, mas raramente fica claro qual adotar primeiro. A decisão afeta diretamente o tempo de resposta a incidentes e o custo da infraestrutura de observabilidade.

A diferença central: centralized logging agrega logs de todos os serviços em um só lugar, com busca por texto e filtros por timestamp. Distributed tracing, por outro lado, segue uma requisição específica desde a entrada até a resposta final, marcando o tempo gasto em cada etapa do caminho. Um log centralizado responde "o que aconteceu"; o tracing responde "por onde passou e onde demorou".

Custo de implementação

Centralized logging costuma ser mais barato para começar. Um stack com Elasticsearch, Logstash e Kibana (ELK) ou um serviço gerenciado como Datadog Logs exige apenas que cada serviço envie suas linhas de log para um endpoint comum. A curva de adoção é curta, e a equipe já sabe ler logs.

Distributed tracing exige instrumentação mais profunda. Cada serviço precisa propagar um header de contexto (como o trace-id), e bibliotecas específicas precisam ser adicionadas ao código. Em linguagens como Java ou Go, isso pode ser feito com agentes automáticos, mas em Node.js ou Python, a instrumentação manual é mais comum. O custo inicial de desenvolvimento é maior, e o ganho só aparece quando a maioria dos serviços está instrumentada.

Facilidade de uso no dia a dia

Para o time de suporte ou um desenvolvedor júnior, centralized logging é mais intuitivo. Buscar por order_id ou erro=timeout em uma interface unificada resolve boa parte dos chamados. O treinamento é rápido, e a documentação interna pode ser simples.

Distributed tracing exige um novo modo de pensar. Em vez de buscar por texto, o desenvolista abre uma visão de waterfall, onde cada span representa uma chamada a um serviço ou banco. A leitura é mais visual, mas a interpretação correta depende de entender o fluxo da aplicação. Para times maduros, o ganho é grande: um trace mostra imediatamente que o gargalo está no banco de dados, não no serviço de pagamento.

Diagnóstico de problemas reais

Um cenário comum em e-commerce: o carrinho demora 8 segundos para carregar, mas os logs de cada serviço mostram tempos de resposta normais. Se a equipe só tem logs centralizados, vai investigar serviço por serviço, sem saber que a latência está na comunicação entre o serviço de catálogo e o de inventário. O distributed tracing revela isso em um único trace.

Por outro lado, para erros de negócio, como uma regra de frete que rejeita um CEP, o log centralizado é mais direto. O trace mostra que a requisição passou pelo serviço de frete, mas não explica por que a regra falhou. O detalhe está no log de aplicação, que registra o motivo exato.

Custo operacional e de infraestrutura

Logs centralizados crescem sem limite. Cada serviço que envia logs aumenta o volume armazenado, e o custo de retenção em serviços gerenciados pode surpreender no fim do mês. Uma prática comum é definir níveis de log por ambiente e expirar logs antigos após 30 dias.

Traces também geram dados, mas o volume é proporcional ao número de requisições, não ao número de linhas de log por requisição. Com amostragem (por exemplo, registrar 10% dos traces), o custo fica previsível. A diferença de custo entre as duas abordagens depende muito do tráfego da loja, mas traces tendem a ser mais baratos de manter em escala.

Tabela comparativa

| Critério | Centralized Logging | Distributed Tracing | |---|---|---| | Custo inicial | Baixo | Médio a alto | | Facilidade de adoção | Alta | Média | | Diagnóstico de latência | Fraco | Forte | | Diagnóstico de erros de negócio | Forte | Fraco | | Volume de dados | Alto | Controlável com amostragem | | Curva de aprendizado | Curta | Longa |

Quando usar cada um

Se a equipe ainda está sem uma visão unificada dos logs, comece pelo centralized logging. Ele resolve o problema mais básico: encontrar erros sem acessar servidor por servidor. Essa base também facilita a adoção futura do tracing, porque os logs podem incluir o trace-id, criando uma ponte entre as duas ferramentas.

Se os erros de latência já são frequentes e a arquitetura de microserviços está consolidada, o distributed tracing deve vir primeiro. Um exemplo prático: uma loja que processa 200 mil requisições por dia e tem picos de lentidão em horários de promoção. Os logs mostram que o serviço de checkout responde em 200ms, mas o usuário espera 5 segundos. O trace revela que o tempo está na chamada ao gateway de pagamento, não no serviço em si.

Veredito: qual usar primeiro?

Para quem busca resolver erros de negócio e ter uma visão centralizada de incidentes, o centralized logging é a escolha. Ele entrega valor imediato com baixo custo de implementação. Para quem busca entender o fluxo de requisições e otimizar a latência em microserviços, o distributed tracing é a prioridade, mesmo com o custo de instrumentação.

Na prática, a maioria das operações de e-commerce precisa das duas ferramentas, mas a ordem importa. Comece com logs centralizados se o time ainda não tem nem isso. Se já tem, o próximo passo é instrumentar o tracing nos serviços mais críticos, como checkout e pagamento.

Perguntas frequentes

Distributed tracing substitui centralized logging?

Não. Eles são complementares. O tracing mostra o caminho de uma requisição, mas não substitui o detalhe dos logs de aplicação, que registram mensagens de erro, dados de negócio e parâmetros. Uma estratégia sólida usa os dois, com o trace-id presente nos logs para permitir a correlação.

Qual a diferença entre tracing e logging?

Logging registra eventos discretos, como um erro ou uma ação do usuário, em cada serviço. Tracing registra o fluxo de uma requisição específica através de todos os serviços, com o tempo gasto em cada etapa. O log responde "o que aconteceu"; o trace responde "por onde passou e onde demorou".

Preciso de distributed tracing se tenho poucos serviços?

Se a aplicação tem poucos serviços e o fluxo é simples, os logs centralizados podem ser suficientes. O tracing ganha valor quando uma requisição atravessa muitos serviços e o gargalo não é óbvio. Para um monolito, o tracing é desnecessário.

Como escolher entre Datadog, Grafana e Elastic para tracing?

A escolha depende do orçamento e da stack existente. Datadog é robusto, mas caro. Grafana Tempo é open source e integra bem com Prometheus. Elastic APM é uma opção se você já usa ELK. Avalie o custo por volume de dados e a facilidade de instrumentação na sua linguagem.

O que é um trace-id?

É um identificador único gerado no início de uma requisição e propagado por todos os serviços que ela toca. Com o trace-id, é possível correlacionar logs de diferentes serviços e montar o fluxo completo da requisição. Incluir o trace-id nos logs é a ponte entre centralized logging e distributed tracing.