Réduire les coûts de télémétrie des agents IA grâce à OpenTelemetry Collector

Adnan Rahic, de Bindplane by Dynatrace, a publié le 22 octobre 2026 un guide pratique détaillant l'optimisation des pipelines OpenTelemetry pour les agents IA. L'article aborde un problème courant en production : le volume excessif de données de télémétrie généré par des outils comme Claude Code, entraînant des coûts de stockage élevés et une cardinalité ingérable.

Ce qui s'est passé

L'activation de la télémétrie pour un agent de codage IA génère souvent un volume massif de données, coûteux à stocker et difficile à interpréter. Dans un cas de test où Claude Code corrigeait deux tests échoués et ajoutait des tests aux limites, une seule exécution a produit 181 enregistrements de télémétrie et 289 Ko de JSON. Ces données incluent des prompts complets, des corps de fichiers et des diffs, dont la plupart sont inutiles pour la surveillance opérationnelle continue.

Le problème fondamental est que l'instrumentation par défaut est conçue pour le débogage de sessions individuelles de développeurs, et non pour la gestion d'une flotte d'agents. À grande échelle, par exemple avec 200 sessions par jour, cette approche devient intenable. Les métriques portent des attributs à haute cardinalité tels que l'ID de session et l'adresse e-mail de l'utilisateur, créant des centaines de séries temporelles uniques qui n'expirent jamais. De plus, le contenu des outils est dupliqué entre les traces et les logs, gonflant encore davantage les besoins en stockage.

Rahic démontre que l'objectif n'est pas de collecter arbitrairement moins de données, mais de ne conserver que ce qui répond à des questions opérationnelles spécifiques. En façonnant les données dans OpenTelemetry Collector avant qu'elles n'atteignent le backend, les équipes peuvent réduire considérablement les coûts sans perdre la visibilité sur les métriques critiques de performance et de coût.

Comment cela fonctionne

La solution consiste à configurer OpenTelemetry Collector pour répartir chaque signal dans deux pipelines distincts : un pipeline brut et un pipeline optimisé. Les deux pipelines reçoivent une entrée identique au niveau des octets provenant d'un seul récepteur OTLP, garantissant une comparaison honnête. Le pipeline brut sert de groupe témoin, contenant uniquement un nom de service et un processeur de lot (batch processor), tandis que le pipeline optimisé applique des filtres et transformations spécifiques.

Dans le pipeline optimisé, les processeurs suppriment les dimensions à haute cardinalité et le contenu redondant. Par exemple, le contenu complet des fichiers issus des sorties d'outils est retiré des spans et des logs, ne laissant que les métadonnées essentielles. Les métriques sont pré-sommées ou ajustées pour supprimer les identifiants par session qui provoquent des explosions de cardinalité. Cela garantit que les données envoyées au backend sont légères et axées sur des informations exploitables.

La configuration utilise Grafana LGTM pour les deux pipelines afin de visualiser les différences. Des tableaux de bord comparent la cardinalité, les octets par minute et le nombre d'enregistrements côte à côte. Dans un environnement de production, le pipeline brut pourrait être dirigé vers un stockage objet pour des débogages approfondis occasionnels, ou supprimé entièrement, tandis que le pipeline optimisé alimente le backend de surveillance principal.

Détails clés

• Une seule exécution de Claude Code a généré 181 enregistrements de télémétrie et 289 Ko de JSON avec tous les indicateurs de contenu activés.
• Les métriques par défaut incluent des attributs à haute cardinalité tels que session.id et user.email, créant 300 séries pour seulement huit métriques sur 25 sessions.
• Le contenu des outils est dupliqué dans les traces et les logs, les contenus de fichiers étant stockés sous forme d'événements de span et d'attributs de log.
• Le pipeline optimisé réduit le nombre de séries de métriques de 300 à 12 en supprimant les dimensions par session.
• Six questions clés guident l'optimisation : coût par modèle, utilisation des tokens, taux d'échec des outils, rejet des modifications, latence et erreurs.
• La métrique otelcol_exporter_enqueue_size_bytes n'existe qu'au niveau détaillé lorsque la file d'attente d'envoi est activée.

Pourquoi c'est important

Pour les équipes d'ingénierie développant avec des agents IA, les coûts de télémétrie peuvent rapidement sortir de contrôle s'ils ne sont pas gérés. Une forte cardinalité dans les métriques entraîne une augmentation des coûts de stockage et de requêtes dans les plateformes d'observabilité, tandis que les charges utiles volumineuses des traces et des logs consomment la bande passante et les ressources d'indexation. En filtrant ces données au niveau du collector, les organisations peuvent maintenir une visibilité complète sans supporter le coût prohibitif du stockage de chaque prompt et diff de fichier.

De plus, se concentrer sur des questions opérationnelles spécifiques améliore le rapport signal/bruit pour les développeurs et les SRE. Au lieu de fouiller dans des murs de texte, les équipes peuvent surveiller des indicateurs clairs de la performance des agents, tels que l'utilisation des tokens par type, les taux de succès des outils et la latence. Ce passage de la collecte brute de données à une observabilité ciblée permet un dépannage plus rapide et une gestion des coûts plus efficace.

Ce que vous pouvez faire

• Identifiez les six questions clés auxquelles votre équipe doit répondre concernant la performance des agents IA, telles que le coût par modèle et les taux d'échec des outils.
• Configurez votre OpenTelemetry Collector pour créer des pipelines bruts et optimisés séparés pour la télémétrie des agents IA.
• Supprimez les attributs à haute cardinalité tels que les ID de session et les adresses e-mail des utilisateurs des métriques pour éviter l'explosion des séries temporelles.
• Retirez les contenus complets de fichiers et les prompts des spans de trace et des logs, en ne conservant que les métadonnées essentielles et les informations d'erreur.
• Utilisez des métriques pré-sommées lorsque possible pour réduire le nombre de points de données envoyés à votre backend.
• Visualisez la différence entre les flux bruts et optimisés pour valider les économies de stockage et garantir qu'aucune donnée critique n'est perdue.