Habr analisa a autoinstrumentação em APM: onde se perdem os 4 segundos de uma requisição

A requisição leva 4 segundos. Em um monólito, o desenvolvedor ligaria o profiler e encontraria o método pesado em uma noite. Em um sistema em que a requisição passa por um API Gateway, vários microsserviços, uma fila de mensagens, um banco de dados e uma API externa, o profiler de uma única máquina mostra apenas um pedaço do quadro. O Habr publicou uma análise de como o APM responde à pergunta «para onde o tempo foi» com rastreamento distribuído e instrumentação automática.

Trace e span: como o quadro é montado

No distributed tracing, cada requisição é representada como um trace, isto é, o percurso completo por todos os componentes. O trace se divide em spans: cada chamada individual no front-end, no back-end ou no barramento recebe seu próprio intervalo de tempo. O span tem um identificador, uma referência ao span pai, o horário de início e a duração. É a partir dessas relações que se monta a árvore de chamadas.

Para que os spans de serviços diferentes caiam na mesma árvore, o contexto precisa viajar junto com a requisição. Hoje isso costuma ser feito pelo cabeçalho traceparent, do padrão W3C Trace Context. Ele carrega o identificador do trace (16 bytes), o identificador do span atual (8 bytes) e flags, como a de amostragem. O serviço recebe o cabeçalho, cria um span filho e repassa o contexto adiante.

Como funciona a autoinstrumentação

Na versão manual, o desenvolvedor envolve as chamadas com código de tracing em cada serviço. Em equipes com dezenas de serviços, isso rapidamente vira dívida técnica. A autoinstrumentação elimina esse trabalho: o agente se conecta ao runtime e adiciona sozinho as medições em torno das bibliotecas conhecidas.

Os mecanismos dependem da plataforma:

• Java: o agente, via -javaagent e java.lang.instrument, modifica o bytecode durante o carregamento das classes, muitas vezes com base em ASM ou Byte Buddy.
• .NET: usa-se a Profiling API do CLR.
• Python e Node.js: funções de bibliotecas populares são substituídas (monkey-patching, hooks de carregamento de módulos).
• Go e outras linguagens compiladas: o mais comum é recorrer a eBPF ou a wrappers manuais, porque o runtime é menos flexível.

O agente conhece os pontos típicos: servidores e clientes HTTP, drivers de banco de dados, clientes de fila. Ele não precisa entender a lógica de negócio para medir uma requisição recebida, uma consulta SQL ou a publicação de uma mensagem. Dessas medições nascem os spans, que seguem para o coletor e depois para o armazenamento do APM.

Onde essa abordagem tem limite

A autoinstrumentação enxerga apenas o que foi descrito de antemão. Se o tempo se perde em um algoritmo próprio dentro de um método, em um lock sobre um recurso compartilhado ou em um pool de threads, os hooks padrão mostram só um span longo, sem explicação. Nesses casos ajudam spans adicionais em torno dos trechos críticos e o profiling de threads.

Os custos adicionais (overhead) são um assunto à parte. O agente acrescenta trabalho a cada chamada, por isso o tracing quase sempre é combinado com amostragem. O head-based decide o destino do trace no início da requisição e sai barato. O tail-based decide depois que a requisição termina; por isso preserva as requisições lentas e com erro, mas exige buffering no coletor.

Na prática: por onde começar

Se o sistema tem mais de três ou quatro serviços e os incidentes são investigados manualmente pelos logs, vale começar com um conjunto mínimo de passos:

• Ativar a autoinstrumentação em um único caminho crítico, como o fechamento de pedido, em vez de em toda a infraestrutura de uma vez.
• Verificar a propagação ponta a ponta do traceparent pelo gateway, pelas filas e pelos handlers assíncronos: é nesses pontos que os traces mais se rompem.
• Adicionar spans manualmente em torno dos trechos em que o agente automático mostra uma «caixa-preta».
• Configurar a amostragem para que as requisições lentas (por exemplo, acima do p95) sejam sempre preservadas.
• Cruzar o resultado com métricas e logs pelo trace ID comum, para que a passagem entre os sinais leve segundos.

Essa abordagem transforma o «o sistema está lento» em algo concreto: 3,1 segundos foram para a API externa, 0,6 para a consulta ao banco, e o restante para a fila. É por aí que começa a otimização, e não por palpites.