Qu’est-ce que OpenTelemetry Collector ?
L'OpenTelemetry Collector est un service placé entre vos applications et la destination de la télémétrie. Les applications lui envoient traces, métriques et logs, le plus souvent via OTLP, le protocole propre à OpenTelemetry ; le Collector les regroupe, supprime ou réécrit ce que vous lui indiquez, et transmet des copies à un ou plusieurs backends. Tout se configure dans un pipeline YAML de receivers (entrées), processors (filtrage, échantillonnage, masquage), exporters (sorties) et connectors (qui relient des pipelines).
Pour les équipes d'agents, c'est là que se recompose une trace qui traverse un planificateur, trois workers d'outils et deux fournisseurs de modèles, et là que l'on découvre où est passée la latence de bout en bout. Les spans LLM suivent les conventions sémantiques GenAI d'OpenTelemetry, un ensemble commun de noms comme gen_ai.request.model et gen_ai.usage.input_tokens, si bien qu'un Collector peut envoyer les mêmes spans à Langfuse ou Arize Phoenix pour le débogage LLM et à Grafana ou Datadog pour le reste de la pile.
Le dépôt principal contient le framework et un petit ensemble de composants ; la plupart des receivers, processors et exporters se trouvent dans opentelemetry-collector-contrib. Les deux sont des projets de la CNCF sous Apache 2.0. Cinq distributions officielles sont publiées, dont une version de base, une version contrib et une version Kubernetes, et le Collector Builder (ocb) compile une version sur mesure avec les seuls composants nécessaires.
OpenTelemetry Collector vaut-il le coup ?
Le Collector est ce qui garde le traçage d'un système d'agents portable. On instrumente une fois avec OpenTelemetry, on dirige chaque service vers un Collector, et décider si les traces vont à Langfuse, Phoenix, Datadog ou aux trois devient une modification YAML plutôt qu'une modification de code. Rien d'autre en observabilité n'a une telle portée : le dépôt principal compte environ 7 700 étoiles sur GitHub et contrib environ 5 000, les versions arrivent toutes les quelques semaines, et la 0.165.0 est sortie le 6 novembre 2026.
Il fait aussi des tâches qu'un backend LLM ne peut pas faire. Un processor de masquage ou de transformation peut retirer les données clients des attributs de prompt avant qu'elles ne quittent votre réseau, ce qui compte parce que les conventions GenAI placent les messages d'entrée et de sortie complets dans les attributs des spans et préviennent qu'ils peuvent contenir des données personnelles. L'échantillonnage réduit la facture : conserver chaque trace d'un agent bavard coûte cher, et le tail sampling peut ne garder que les traces lentes ou en échec. La documentation de Langfuse montre elle-même un Collector qui reçoit l'OTLP en gRPC et le transmet en HTTP, car Langfuse n'accepte pas encore gRPC.
La couche GenAI bouge encore. Aucune des conventions GenAI n'a atteint le statut Stable, elles ont migré vers leur propre dépôt en 2026, et des attributs ont déjà été renommés (gen_ai.system est devenu gen_ai.provider.name). Les backends suivent avec retard : Langfuse mappe encore les attributs obsolètes gen_ai.prompt et gen_ai.completion. Figer les versions d'instrumentation et vérifier ce que lit votre backend fait partie du travail. Le filtrage demande aussi de la prudence, puisque Langfuse a besoin du span racine d'une trace et que le supprimer laisse une trace incomplète.
Le numéro de version dit honnêtement le reste. Le binaire est toujours en 0.x, la stabilité varie d'un composant à l'autre, et les changements incompatibles figurent dans les notes de version ; la 0.165.0 a supprimé quatre réglages HTTP obsolètes. Contrib porte l'essentiel du risque de sécurité : parmi les avis de 2026 figurent un contournement d'authentification dans l'extension d'authentification Azure et un receiver GitHub qui ignorait l'authentification configurée. Une équipe avec un seul service d'agents et un seul backend y gagne peu, la documentation jugeant l'envoi direct suffisant pour les petites installations ; son intérêt commence au deuxième service ou à la deuxième destination.
Là où il fait la différence
Une équipe plateforme dans une fintech qui fait tourner un agent de support sur six services
Suivre de bout en bout une réponse lente et garder les numéros de compte hors du stockage des traces
Chaque service exporte en OTLP vers une passerelle Collector ; un processor de masquage cache les motifs de numéros de compte dans gen_ai.input.messages avant l'export vers un Langfuse auto-hébergé. Le Collector lui-même ne coûte que les pods sur lesquels il tourne.
Un SRE chez un distributeur qui paie Datadog au span ingéré
Garder le détail pour le débogage LLM sans payer chaque étape d'agent
Tous les spans vont à Phoenix ou Langfuse pour l'équipe IA, et seules les traces lentes ou en échec retenues par tail sampling vont à Datadog. Le tail sampling exige que tous les spans d'une trace arrivent sur le même Collector, il faut donc d'abord une couche de répartition de charge.
Un CTO dans une start-up de 15 personnes qui choisit un outil d'observabilité LLM
Ne pas rester enfermé dans le premier outil de traçage
Instrumenter avec OpenTelemetry et passer par un Collector dès le départ ; tester un second backend revient à ajouter un exporter et à faire tourner les deux en parallèle pendant un mois, sans changer de SDK.
Avant de vous engager
- Mise en route
- Lancez l'image Docker ou le binaire otelcol-contrib avec une configuration YAML listant receivers, processors et exporters ; Langfuse publie un exemple de configuration prêt à l'emploi pour lui transmettre les données. Kubernetes dispose d'une distribution dédiée, et ocb produit un binaire allégé.
- Intégrations
- Entrée OTLP en gRPC et HTTP ; exporters vers la plupart des backends d'observabilité via contrib. Langfuse n'accepte l'OTLP qu'en HTTP sur /api/public/otel ; Phoenix et OpenLLMetry émettent et lisent des spans OpenTelemetry.
- Données et confidentialité
- Auto-hébergé ; il ne stocke rien d'autre que des tampons en mémoire sauf configuration contraire, et n'envoie des données qu'aux exporters que vous déclarez. Les spans GenAI peuvent contenir les prompts et sorties complets, c'est donc ici que le masquage a sa place. Apache 2.0. Le dépôt principal recense deux avis de sécurité, contrib plusieurs en 2026.
- Coût à grande échelle
- Ni licence ni édition payante ; le coût correspond au calcul des Collectors en mode agent ou passerelle, plus les tarifs d'ingestion des backends. Aucun chiffre de dimensionnement pour les charges LLM n'est publié.
- Limites
- Versions 0.x avec changements incompatibles ; conventions GenAI au statut Development ; le tail sampling exige une couche de répartition de charge ; supprimer un span racine casse les traces dans Langfuse. Environ 690 tickets et pull requests ouverts dans le cœur et 1 060 dans contrib.
Les points forts
- Neutre vis-à-vis des éditeurs : changer ou ajouter des backends sans toucher au code
- Masquage, filtrage et tail sampling avant que les données ne quittent votre réseau
- Fait le pont entre protocoles, par exemple gRPC en entrée et HTTP en sortie vers Langfuse
- Les builds sur mesure avec ocb gardent le binaire léger
Les points faibles
- Toujours en 0.x, avec des changements incompatibles dans les notes de version
- Conventions GenAI pas encore Stable et toujours renommées
- Composants contrib de maturité inégale, qui concentrent la plupart des avis
- Un service de plus à exploiter, dimensionner et surveiller
Idéal pour
Les équipes d'agents avec plusieurs services ou plus d'un backend de télémétrie qui veulent des traces LLM qu'elles peuvent masquer, échantillonner et rerouter sans changer le code.
Alternatives à OpenTelemetry Collector
OpenTelemetry Collector : questions fréquentes
- OpenTelemetry Collector vaut-il le coup ?
- L'endroit standard pour collecter, nettoyer et router les traces d'agents dès que plus d'un service ou d'un backend entre en jeu, et une pièce mobile de trop avant cela. Nous lui donnons 4.4 sur 5.
- Combien coûte OpenTelemetry Collector ?
- Gratuit et open source sous Apache 2.0, sans édition payante du projet. Les coûts sont les machines qui l'exécutent et les backends vers lesquels il envoie ; les distributions commerciales viennent des éditeurs d'observabilité.
- Quels sont les inconvénients de OpenTelemetry Collector ?
- Toujours en 0.x, avec des changements incompatibles dans les notes de version; conventions GenAI pas encore Stable et toujours renommées; composants contrib de maturité inégale, qui concentrent la plupart des avis; un service de plus à exploiter, dimensionner et surveiller.
- À qui s’adresse OpenTelemetry Collector ?
- Les équipes d'agents avec plusieurs services ou plus d'un backend de télémétrie qui veulent des traces LLM qu'elles peuvent masquer, échantillonner et rerouter sans changer le code.
- Combien coûte OpenTelemetry Collector pour une équipe ou en production ?
- Ni licence ni édition payante ; le coût correspond au calcul des Collectors en mode agent ou passerelle, plus les tarifs d'ingestion des backends. Aucun chiffre de dimensionnement pour les charges LLM n'est publié.
- OpenTelemetry Collector est-il sûr pour les données de l’entreprise ?
- Auto-hébergé ; il ne stocke rien d'autre que des tampons en mémoire sauf configuration contraire, et n'envoie des données qu'aux exporters que vous déclarez. Les spans GenAI peuvent contenir les prompts et sorties complets, c'est donc ici que le masquage a sa place. Apache 2.0. Le dépôt principal recense deux avis de sécurité, contrib plusieurs en 2026.
- Quelles sont les meilleures alternatives à OpenTelemetry Collector ?
- Les alternatives les plus proches que nous avons testées sont OpenLLMetry.
Réponses vérifiées le 9 nov. 2026.
Vous éditez OpenTelemetry Collector ? Affichez cette note sur votre site
