Como funciona o rastreamento distribuído e o que ele revela sobre uma aplicação?
Em uma aplicação moderna, um clique do usuário pode passar por um gateway, quatro serviços, duas filas e três bancos de dados. Quando a resposta demora, logs e métricas de cada componente isolado raramente mostram onde o tempo foi gasto. O rastreamento distribuído reconstrói o caminho completo daquela requisição.
Trace e span
Um trace representa uma requisição de ponta a ponta. Ele é composto por spans, cada um representando uma operação: a chamada a uma API, uma consulta ao banco, a publicação em uma fila. Cada span registra início, duração, status, o serviço que o executou e atributos como a rota, o código de resposta ou a tabela consultada.
Os spans formam uma árvore: o span de entrada é a raiz, e as chamadas que ele dispara são filhas. Em uma linha do tempo, essa árvore mostra quais operações rodaram em sequência, quais em paralelo e qual concentrou o atraso.
Propagação de contexto
Para que spans de serviços diferentes pertençam ao mesmo trace, cada chamada precisa levar adiante o identificador do trace e do span pai. Esse repasse é a propagação de contexto. Em chamadas HTTP, o padrão W3C Trace Context usa o cabeçalho traceparent para isso; em filas e mensagens, o contexto viaja nos metadados da mensagem.
Basta um componente no meio do caminho que não propague o contexto, como um proxy antigo ou uma biblioteca sem instrumentação, para que o trace se parta em pedaços desconexos. Por isso, a cobertura da instrumentação importa tanto quanto a ferramenta.
O que os traces revelam
- O gargalo real: qual serviço ou dependência consome a maior parte do tempo.
- Consultas repetidas: como o problema N+1, em que uma tela dispara dezenas de consultas iguais ao banco, uma para cada item de uma lista.
- Chamadas em série que poderiam ser paralelas.
- Dependências escondidas: o mapa de serviços gerado a partir dos traces mostra quem chama quem, inclusive integrações que ninguém documentou.
- A origem dos erros: em que ponto da cadeia a falha nasceu e como se propagou.
Amostragem: head e tail
Guardar todos os traces de um sistema com alto volume é caro e, na maior parte, inútil, já que a grande maioria das requisições é normal. A amostragem decide o que guardar.
Na amostragem head-based, a decisão é tomada no início da requisição, por exemplo, mantendo 10% dos traces. É simples e barata, mas pode descartar justamente o trace do erro raro. Na amostragem tail-based, a decisão é tomada depois que o trace termina, o que permite guardar todos os traces com erro ou acima de um limite de latência e só uma fração dos normais. É mais útil, mas exige um componente que mantenha os spans em memória até a decisão, como o Collector do OpenTelemetry.
Correlação com logs e métricas
O trace mostra onde e quanto; o log da requisição mostra o porquê. Gravar o identificador do trace em cada linha de log permite ir de um span lento direto às mensagens daquela execução. No sentido inverso, alguns sistemas de métricas aceitam exemplares (exemplars), que ligam um ponto do gráfico de latência a um trace concreto.
Para aproveitar isso, use nome de serviço e ambiente padronizados em todos os sinais e cuide para que atributos dos spans não carreguem dados pessoais nem segredos.
O rastreamento distribuído reconstrói o caminho de uma requisição por spans ligados pela propagação de contexto. Revela gargalos, consultas repetidas e dependências escondidas. Amostragem por cauda e o identificador do trace nos logs tornam os dados úteis sem explodir o custo.
Este conteúdo foi útil?
Revisão técnica VIPER IT — última atualização em 10 de outubro de 2026.