Como filtrar e reduzir a telemetria de agentes de IA com o OpenTelemetry Collector

O texto parte de um problema prático: ligar a telemetria do Claude Code com todas as flags de conteúdo gera volume que ninguém consegue ler. Uma tarefa simples (corrigir dois testes e adicionar testes de borda) produziu 181 registros e 289 KB de JSON. O autor define o critério de corte: se nenhum dashboard, alerta ou consulta lê um campo, ele é só armazenamento pago para indexar.

O volume vem do loop do agente. Com OTEL_LOG_TOOL_CONTENT ligado, cada span de ferramenta ganha um evento tool.output (na Read, o arquivo inteiro), e os logs repetem o conteúdo em tool_parameters. Nas métricas, o problema é cardinalidade: session.id, user.id, user.email e dois ids de conta em cada data point geraram 300 séries para oito métricas em 25 sessões. A solução fica no Collector, com um receiver OTLP alimentando um pipeline raw (controle) e um otimizado, ambos no mesmo Grafana LGTM. Nos logs, o descarte de api_request, a remoção de seis atributos, o hash truncado em 16 caracteres hex e o limite de 256 caracteres em error reduzem os bytes à metade. Nas métricas, 300 séries viram 12, e é preciso somar as sessões antes de converter de delta para cumulativo. Nos traces, o autor trunca em vez de amostrar: descarta tool.execution bem-sucedido (cerca de um quinto dos bytes), apaga atributos duplicados e limita conteúdo a 512 caracteres. Os totais otimizados batem com os raw em até meio por cento. O autor avisa que isso exige um único Collector vendo todas as sessões, então atrás de um load balancer vale um gateway único.

Para quem opera uma frota de agentes, a leitura é que o custo de observability de IA tende a vir de atributos e conteúdo, não do número de chamadas. Tratar o Collector como camada de política (o que entra no backend) é mais barato do que tentar mudar o agente. Já amostragem, nesse caso, pode esconder justamente a execução que alguém quer investigar.