Come ridurre la valanga di telemetria degli agenti AI con OpenTelemetry

Una singola esecuzione di Claude Code ha generato 181 record di telemetria e 289 KB di JSON. Il task: correggere due test falliti e aggiungere test di boundary, con tutti i flag di contenuto attivi. Il problema non è raccogliere, è decidere cosa tenere e cosa scartare¹.

Le domande operative erano poche e precise. Bastavano contatori e attributi corti per rispondere. Prompt, corpi di file e diff non servivano a dashboard, alert o query. Pesano, si indicizzano male, non aggiungono segnale¹.

Per capire da dove arriva il volume, basta guardare il ciclo dell’agente: prompt, chiamata al modello, chiamata a uno strumento, risultato, nuova decisione, ripeti. La telemetria lo mappa così: uno span per l’interazione (claude_code.interaction), figli per i turni del modello (llm_request) e per le chiamate agli strumenti (tool). Se attivi OTEL_LOG_TOOL_CONTENT, ogni span tool aggiunge un evento tool.output con il contenuto restituito dallo strumento. Nell’esperimento si trattava di un elenco di directory¹.

Il punto di forza è che tutto parla già OpenTelemetry. Si può filtrare e modellare nel Collector prima di inviare a un backend. La regola pratica: tenere solo ciò che risponde a domande concrete, scartare contenuti lunghi che nessuno interroga. Se nessuna dashboard, nessun alert e nessuna query leggono un campo, non è osservabilità, è solo costo¹.

Questo disegno dei dati guida i tagli. Le interazioni restano in claude_code.interaction. I turni del modello in llm_request. Le chiamate agli strumenti in span tool. Gli eventi tool.output e i campi testuali lunghi gonfiano i payload e spesso non servono, perché le risposte operative vivono in contatori e attributi brevi¹.

Serve un punto di decisione a monte. Il Collector fa questo lavoro: elimina campi che non rispondono a domande, conserva il minimo informativo, normalizza gli attributi utili. Così i team vedono subito ciò che conta e non pagano per il resto¹.

Tradurre tutto in pratica è diretto. Nel Collector si applicano tre mosse: primo, se lo span.name è tool, si rimuovono gli eventi tool.output quando non servono a una domanda specifica; secondo, si tolgono attributi con testo lungo come prompt, contenuti di file e diff; terzo, si preservano contatori e attributi corti che alimentano dashboard, alert e query, per esempio esito dell’azione, durata, numero di turni del modello e numero di chiamate agli strumenti¹.

La chiusura è operativa. Definire 5-10 domande a cui la telemetria deve rispondere e mappare ogni domanda a contatori e attributi corti. Mantenere nomi degli span e gerarchie che spiegano il flusso, per esempio claude_code.interaction, llm_request, tool. Tagliare sistematicamente contenuti non interrogati nel Collector, inclusi prompt, file, diff ed eventi tool.output quando non servono¹.

L’effetto è immediato: payload più leggeri, query più semplici, costi sotto controllo. Con meno rumore, gli incident playbook diventano più rapidi, perché le risposte stanno già nei numeri che contano¹.