OpenLLMetry : instrumenter une application LLM avec les conventions OpenTelemetry

Le problème : des traces LLM coupées du reste du système

Une application qui appelle un modèle de langage produit deux catégories de signaux. D'un côté les requêtes HTTP, les accès base de données, les files d'attente, déjà couverts par OpenTelemetry. De l'autre les appels à OpenAI, Anthropic ou Bedrock, les recherches dans Chroma, Pinecone, Qdrant ou Weaviate, qui ne remontent nulle part tant que personne n'écrit l'instrumentation correspondante. Le résultat habituel est une plateforme d'observabilité qui montre la latence du service mais pas le coût des tokens, ni le prompt exact qui a produit une réponse fausse.

OpenLLMetry vise cet écart. Le README présente le projet comme un ensemble d'extensions bâties sur OpenTelemetry, maintenues par Traceloop sous licence Apache 2.0. La cible est l'équipe qui exploite déjà un backend compatible OTLP et qui refuse de maintenir un pipeline de télémétrie parallèle pour ses appels LLM. Ce n'est pas un outil d'évaluation hors ligne, ni un registre de prompts : c'est une couche d'instrumentation.

Ce que le dépôt contient réellement

Le dépôt héberge deux choses distinctes. D'abord des instrumentations OpenTelemetry standard, publiées comme paquets séparés. Le badge du README pointe vers opentelemetry-instrumentation-openai, ce qui confirme que chaque fournisseur dispose de son propre paquet installable. Ensuite un SDK, traceloop-sdk, qui regroupe ces instrumentations et les active d'un coup. Le README précise que si OpenTelemetry est déjà en place, il est possible d'ajouter les instrumentations individuellement sans passer par le SDK.

Le projet indique également que ses conventions sémantiques ont été intégrées à OpenTelemetry, avec un lien vers la discussion correspondante dans le dépôt communautaire. C'est un point structurant : les noms d'attributs ne sont pas une invention locale destinée à un seul backend. Une version JavaScript existe dans un dépôt séparé, openllmetry-js, pour les équipes qui n'écrivent pas en Python.

Le mécanisme : des spans OTel, pas un format propriétaire

Le principe est celui d'OpenTelemetry. L'instrumentation s'accroche au client du fournisseur, ouvre un span au moment de l'appel, y attache des attributs, puis le transmet via l'exportateur OTLP configuré. Comme le README le formule, le SDK produit des données OpenTelemetry standard, ce qui permet de les brancher sur une pile existante plutôt que sur un entrepôt dédié.

L'intérêt pratique tient à la propagation du contexte. Un span d'appel modèle créé à l'intérieur d'une requête HTTP se retrouve enfant du span de cette requête. Vous pouvez donc corréler une latence anormale côté API avec l'appel LLM qui l'a provoquée, dans la même trace, sans jointure entre deux systèmes. C'est aussi la limite du modèle : tout ce qu'OpenLLMetry expose est un span, et un span ne sait pas juger si une réponse est correcte. La qualité du contenu reste hors de son périmètre.

Mise en route : deux lignes et une variable d'environnement

L'installation se fait avec pip install traceloop-sdk. L'initialisation tient en deux lignes : importer Traceloop depuis traceloop.sdk, puis appeler Traceloop.init(). Le README donne aussi Traceloop.init(disable_batch=True) pour les exécutions locales, afin que les traces apparaissent immédiatement au lieu d'attendre le vidage du lot.

Ce que le README ne détaille pas dans l'extrait disponible, c'est la configuration de la destination. La variable TRACELOOP_API_KEY n'apparaît pas dans les blocs cités, mais l'export par défaut du SDK pointe vers le service Traceloop, ce qui suppose une clé. Si vous visez Datadog, Honeycomb ou un collecteur OpenTelemetry, la documentation d'intégration est le point d'entrée : le README renvoie explicitement vers la page exporting des docs pour chaque destination. C'est la première chose à lire avant d'écrire du code, parce que le choix de l'exportateur détermine les variables à définir.

Vingt-cinq destinations testées, et ce que cela implique

Le README énumère les destinations supportées et testées : Traceloop, Axiom, Azure Application Insights, Braintrust, Dash0, Datadog, Dynatrace, Google Cloud, Grafana, Highlight, Honeycomb, HyperDX, IBM Instana, KloudMate, Laminar, New Relic, OpenTelemetry Collector, Oracle Cloud, Scorecard, Service Now Cloud Observability, SigNoz, Sentry, Splunk et Tencent Cloud.

Cette liste est le vrai argument du projet. Elle signifie qu'une équipe déjà équipée n'a pas à changer d'outil pour observer ses appels LLM. Elle signifie aussi une contrainte : chaque intégration a ses propres instructions, et le README renvoie à une page de documentation par destination. Le collecteur OpenTelemetry figure dans la liste, ce qui ouvre la voie à un routage maison si aucune destination ne convient. En revanche, la présence d'un nom dans cette liste ne dit rien de la profondeur de l'intégration pour ce backend : c'est à vérifier au cas par cas dans les docs.

Le rythme de publication et ce qu'il coûte

Les versions récentes fournies vont de 0.62.1 le 28 juin 2026 à 0.62.3 le 10 août 2026, avec une 0.62.2 le 9 août. Trois publications en six semaines sur une série 0.62.x, donc toujours en zéro majeur. Ce rythme indique un projet actif, pas un projet stable au sens sémantique du terme : une montée en 0.63 ou 1.0 peut casser des noms d'attributs ou des signatures d'initialisation.

La licence Apache 2.0 est permissive. Elle autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions de licence et d'avis. Le README ne mentionne aucun accord de contribution séparé ni clause de propriété sur les contributions, mais ce point mérite une lecture directe du fichier CONTRIBUTING.md si vous prévoyez de modifier les instrumentations. Le projet est maintenu par Traceloop, éditeur commercial du service du même nom : la partie open source et l'offre hébergée avancent ensemble, ce qui est une dynamique à garder en tête pour évaluer la pérennité des paquets gratuits.

Quand OpenLLMetry n'est pas le bon outil

Le cas le plus net est celui d'une équipe sans backend OTLP. Installer traceloop-sdk suppose un endroit où envoyer les spans. Sans collecteur ni plateforme compatible, vous ajoutez une dépendance et de la charge réseau pour des données que personne ne lit. Le disable_batch=True du README est un mode de débogage local, pas une stratégie de production.

Deuxième cas : l'attente d'une fonction d'évaluation. OpenLLMetry trace des appels et des attributs. Il ne juge pas la pertinence d'une réponse, ne compare pas deux versions de prompt, ne calcule pas de score de qualité. Une équipe dont le besoin principal est l'évaluation de sorties trouvera dans ce dépôt une brique de collecte, pas une réponse.

Troisième cas : la contrainte de langage. Le dépôt principal est en Python. Une application Node ou Go doit se tourner vers openllmetry-js pour la partie JavaScript, et le README ne décrit pas d'équivalent pour les autres langages. Si votre service LLM est écrit en Go, l'instrumentation fournie ici ne s'applique pas directement.

Face à une instrumentation maison

L'alternative évidente n'est pas un produit concurrent mais votre propre code d'instrumentation : un décorateur autour de l'appel au modèle, un enregistrement en base, un tableau de bord. La différence porte sur trois points concrets. Une instrumentation maison produit un schéma d'attributs qui n'existe que chez vous, donc aucun outil tiers ne saura l'interpréter sans adaptation. OpenLLMetry s'appuie sur des conventions désormais rattachées à OpenTelemetry, ce qui rend les données lisibles par n'importe quel backend OTLP. Ensuite, la propagation du contexte parent-enfant est déjà résolue par l'API OpenTelemetry, alors qu'elle demande souvent du travail manuel dans une solution maison. Enfin, le suivi des fournisseurs et des bases vectorielles, dont la liste évolue, est maintenu par le projet plutôt que par votre équipe. Le prix à payer est la dépendance à un ensemble de paquets en 0.62.x, mis à jour fréquemment.

Conclusion éditoriale

Adoptez OpenLLMetry si vous avez déjà un backend compatible OTLP et que vous voulez voir les appels OpenAI, Anthropic ou Qdrant dans les mêmes traces que votre base de données. Passez votre chemin si vous attendez une interface d'évaluation ou de gestion de prompts : le dépôt ne contient que de l'instrumentation et un SDK d'export. Avant de vous engager, vérifiez trois choses concrètes : que votre backend figure dans la liste des destinations testées, que la variable TRACELOOP_API_KEY est bien positionnée si vous utilisez Traceloop.init() avec l'export par défaut, et que votre version de Python est couverte par les workflows de la branche main.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. traceloop/openllmetry on GitHub