Distributed tracing: o que é e como usar para depurar sistema

O problema

Quando o sistema é pequeno, investigar costuma ser mais direto.

Tem uma aplicação, alguns logs, poucas dependências e um caminho relativamente curto entre pedido e resposta.

Mas, quando o fluxo passa por:

• gateway
• serviço de autenticação
• serviço de checkout
• fila
• worker
• provedor externo

o debug muda de natureza.

Você para de ter “um erro em um lugar”.

Passa a ter uma história espalhada em vários lugares.

E aí aparecem perguntas difíceis:

• onde esse fluxo começou a degradar?
• qual etapa consumiu mais tempo?
• esse erro nasceu aqui ou foi propagado de outro serviço?
• o problema é geral ou só de um ramo específico do fluxo?

Só com log solto e métrica agregada, às vezes isso fica lento demais para responder.

Modelo mental

Pense assim:

distributed tracing é uma forma de acompanhar a viagem de uma mesma operação através de várias partes do sistema.

Essa é a ideia central.

Você não está olhando para um servidor isolado.

Está olhando para uma trajetória.

Normalmente isso aparece como:

• um trace representando a operação inteira
• spans representando etapas internas
• duração e status de cada etapa
• relação entre chamada pai e chamada filha

Nada muito misterioso.

Tracing serve para reconstruir o caminho de uma execução distribuída.

Quebrando o problema

Logs, métricas e traces não fazem a mesma coisa

Esse é um erro comum.

Muita gente aprende observabilidade como se tudo fosse o mesmo pacote.

Não é.

Uma forma simples de pensar:

• métricas mostram padrão agregado
• logs mostram eventos com contexto
• traces mostram o caminho de uma execução específica

Exemplo:

• métrica pode mostrar aumento de latência
• log pode registrar timeout numa dependência
• trace pode mostrar em qual parte do fluxo esse tempo foi gasto e como isso encadeou o resto

Quando você entende esse papel, para de esperar de tracing o que ele não promete.

Tracing brilha quando a dúvida é “onde no fluxo?”

Esse é o uso mais clássico.

Se o problema principal é:

• qual etapa está lenta
• qual serviço introduziu erro
• onde a cadeia começou a falhar
• por que uma requisição específica ficou tão pior que o normal

tracing costuma ajudar bastante.

Se a dúvida é totalmente local e simples, talvez log ou métrica já bastem.

Ou seja:

não é ferramenta para tudo.

É ferramenta especialmente boa para perguntas de trajetória.

Span é só uma etapa com começo e fim

Muita gente trava nessa palavra.

Não precisa.

Pense em span como:

• uma parte do trabalho
• com início
• com fim
• com duração
• com algum contexto associado

Exemplos:

• chamada HTTP para outro serviço
• query ao banco
• publicação em fila
• processamento de uma etapa interna importante

Quando você vê vários spans ligados, começa a enxergar a operação inteira com muito mais clareza.

Tracing ajuda a separar gargalo real de suspeita intuitiva

Esse ganho é enorme.

Em sistema distribuído, o time costuma ter palpites como:

• “acho que é o banco”
• “parece a fila”
• “deve ser o gateway externo”

Às vezes acerta.

Às vezes não.

Trace reduz essa loteria porque mostra:

• o tempo em cada salto
• qual dependência falhou
• se houve retries
• se o problema veio cedo ou tarde no fluxo

Não resolve tudo sozinho, mas encurta bastante a busca.

Tracing ruim também existe

Vale dizer isso.

Nem todo trace bonito ajuda.

Problemas comuns:

• spans demais sem valor
• nomes confusos
• ausência de contexto útil
• fronteiras importantes sem instrumentação
• dificuldade de ligar trace com log e erro

Tracing útil não é o que gera o gráfico mais colorido.

É o que ajuda alguém a responder uma pergunta operacional de verdade.

Um trace sozinho raramente fecha o diagnóstico

Esse ponto também importa.

Trace pode mostrar:

• onde houve lentidão
• onde a operação falhou
• por onde ela passou

Mas, muitas vezes, você ainda vai precisar:

• de logs para contexto mais detalhado
• de métricas para entender escala do problema
• de leitura de código para validar hipótese

Tracing não substitui o resto.

Ele conecta o resto.

Em entrevista, o melhor caminho é mostrar decisão de uso

Em vez de despejar definição, costuma ser melhor responder assim:

• quando eu usaria tracing
• que pergunta eu tentaria responder
• como ele complementa logs e métricas
• que tipo de decisão isso destrava

Isso soa muito mais maduro do que repetir terminologia.

Exemplo simples

Imagine um checkout que ficou mais lento depois de uma mudança recente.

Você já sabe por métrica que a latência aumentou.

Mas ainda não sabe onde.

Resposta fraca:

“Eu abriria o tracing para ver o que aconteceu.”

Isso ainda é genérico.

Resposta melhor:

“Como o fluxo passa por vários serviços e uma dependência externa, eu usaria tracing para localizar onde a latência cresceu dentro da trajetória da requisição. A pergunta não é só ‘está lento?’, porque isso a métrica já respondeu. A pergunta é ‘em qual etapa o tempo está sendo consumido e se isso começou no nosso serviço, no banco ou numa chamada externa’. A partir daí eu cruzaria o trace com logs e erro da etapa suspeita.”

Essa resposta funciona porque mostra:

• por que tracing entra
• que pergunta ele responde
• como ele se conecta ao resto da investigação

Erros comuns

• Tratar tracing como substituto de logs e métricas.
• Falar de spans e traces sem conseguir dizer que pergunta eles respondem.
• Instrumentar tudo sem critério e gerar ruído demais.
• Olhar um trace isolado e achar que isso já prova a causa raiz.
• Transformar resposta de entrevista em catálogo de vendor.

Como um senior pensa

Quem amadureceu em sistemas distribuídos costuma pensar assim:

“Quando o problema atravessa várias fronteiras, eu preciso de uma forma de ver a trajetória inteira, não só pedaços soltos dela.”

Essa é uma ótima lente.

Porque explica por que tracing existe sem misticismo.

Senioridade aqui não é usar palavra bonita de observabilidade.

É saber qual ferramenta reduz mais incerteza para a pergunta que você tem agora.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador normalmente está tentando entender se você:

• sabe diferenciar papéis de logs, métricas e traces
• entende quando tracing realmente ajuda
• consegue usar tracing para localizar gargalo ou falha num fluxo distribuído
• evita discurso abstrato demais
• pensa em investigação como composição de sinais, não ferramenta única

Resposta forte costuma mostrar:

1. que tipo de sistema ou problema pede tracing
2. qual pergunta ele ajuda a responder
3. como ele conversa com logs e métricas
4. qual decisão prática ele acelera no debug

Se isso aparece, a resposta já sobe bastante.

Tracing não existe para deixar observabilidade mais sofisticada. Existe para tornar um fluxo distribuído legível.

Quando o problema vive entre serviços, olhar só para cada serviço isoladamente quase sempre atrasa o entendimento.