O Que É um Trace? Tracing de Requisições Distribuídas Explicado
Um trace registra a jornada completa de uma única requisição ou operação conforme ela se move pelos componentes de um sistema, costurada a partir de spans individuais.
Em um sistema feito de muitos serviços, uma única ação do usuário pode tocar uma dezena deles. Um trace segue essa única ação por todo o caminho, mostrando onde o tempo foi gasto e onde um erro se originou. O tracing é o sinal de observabilidade construído especificamente para sistemas distribuídos, onde metrics e logs sozinhos não conseguem mostrar como as peças se conectam.
O que um trace representa
Um trace é o registro completo de uma requisição conforme ela se propaga por um sistema. Ele começa no ponto de entrada e segue cada chamada downstream, capturando tempo e resultado em cada salto. O resultado é uma árvore de operações que mostra exatamente o que aconteceu, em que ordem, e quanto tempo cada parte levou.
Traces são feitos de spans
Cada unidade de trabalho em um trace é um span: uma operação nomeada e cronometrada, como uma consulta a banco de dados ou uma chamada HTTP. Spans se aninham para formar uma árvore pai-filho, e compartilham um trace ID para que possam ser montados em uma única imagem. Um trace, então, é a coleção de todos os spans que compartilham esse ID.
Propagação de contexto
O tracing funciona porque cada serviço passa o contexto de trace, tipicamente o trace ID e o parent span ID, ao próximo serviço que ele chama, geralmente em cabeçalhos de requisição. Essa propagação é o que permite que um trace cruze fronteiras de processo e de rede e permaneça um único registro coerente em vez de fragmentos desconectados.
O que os traces revelam
Traces se destacam em encontrar onde latência e erros realmente se originam. Uma requisição que é lenta no geral pode estar esperando por uma chamada downstream; um trace mostra qual. Visualizado como um flame graph, um trace torna o caminho crítico óbvio e aponta a investigação diretamente para o gargalo.
Traces no CI/CD
A mesma ideia se aplica a pipelines. Modele uma execução de pipeline como um trace e cada job ou passo como um span, e você obtém uma visão em flame graph de onde o build gasta seu tempo de relógio. Isso deixa claro se um pipeline lento é dominado por um estágio, pelo tempo de fila, ou por muitos passos pequenos que se somam.
Principais conclusões
- Um trace registra uma requisição de ponta a ponta entre serviços.
- Ele é montado a partir de spans aninhados que compartilham um trace ID.
- A propagação de contexto permite que traces cruzem fronteiras de processo.
- Pipelines podem ser rastreados para revelar para onde vai o tempo de build.