Labs OpenTelemetry

OpenTelemetry est le standard ouvert qui définit comment une application produit et transmet ses données d’observabilité. Au centre de beaucoup d’installations, on trouve le Collector : un programme qui joue le rôle d’un centre de tri postal. Il reçoit les données, les trie, les enrichit et les réexpédie vers le bon stockage.

Sur la forge, les labs consacrés à OpenTelemetry ont leur propre groupe. Il en contient trois aujourd’hui et chacun répond à une question différente : comment piloter une flotte de Collectors, comment instrumenter une application d’IA, comment prouver ce qui sort du Collector.

Le groupe otel sur la forgeLes trois dépôts, publics, à cloner sans compte.

Les trois labs en un coup d’œil

Lab	La question	Ce qu’on manipule	Prérequis	État au 10 octobre 2026
REVERSOTEL	Peut-on changer de stockage d’observabilité sans reconfigurer chaque agent ?	OpAMP, Collector, dépôt Git de flotte	Docker avec Compose v2 (12 Go de mémoire alloués), Go 1.26, Git	publié, avec le rapport de référence du banc
GENAIOTEL	Que voit-on d’une application RAG avec le seul standard OpenTelemetry ?	conventions sémantiques GenAI, Collector, OTTL	Docker avec le plugin Compose	publié ; la dernière version n’a pas encore été rejouée de bout en bout sous Docker
OTELAUDITEXP	Comment prouver quelles données sont sorties du Collector, pour qui et sans altération ?	exporter sur mesure, OpenTelemetry Collector Builder	Go 1.25 ou plus récent	publié

Les chiffres et les prérequis de cette page viennent du README.md de chaque dépôt, relu le 10 octobre 2026. Quand un lab annonce un résultat mesuré, je dis de quel rapport il vient.

REVERSOTEL : changer de stockage par un commit

Imaginez que vous changiez de fournisseur d’électricité et qu’il faille pour cela recâbler chaque prise de la maison. C’est souvent la situation de l’observabilité. OpenTelemetry a rendu la collecte ouverte : les agents, les protocoles et les formats sont standard. La gestion de la flotte d’agents ne l’est pas. Leur configuration, les tableaux de bord et les alertes restent souvent liés à un éditeur, si bien que changer de stockage devient un projet à part entière.

REVERSOTEL est un plan de contrôle, une sorte de tour de contrôle pour les Collectors. Il les pilote à distance par le protocole OpAMP à partir d’un dépôt Git. Il ne stocke lui-même ni traces, ni métriques, ni logs. Les destinations, les rôles, le contrat de données et les contenus (tableaux de bord, alertes) sont des fichiers texte versionnés. Changer de stockage revient à modifier une ligne et à enregistrer ce changement dans Git, ce qu’on appelle un commit.

Le lab vous apprend à piloter des Collectors à distance, sans intervenir sur les machines. Vous y écrivez un contrat de données que chaque Collector applique. Vous y pratiquez aussi la double écriture : on envoie les données vers l’ancienne et la nouvelle destination à la fois avant de retirer l’ancienne, pour ne rien perdre.

Le dépôt fournit un banc d’essai qu’on peut rejouer. Il bascule une flotte de 21 Collectors d’Elastic vers VictoriaMetrics et VictoriaLogs, puis revient. Le rapport de référence publié dans le dépôt, daté du 30 septembre 2026, indique 27 mesures conformes sur 27, dont une bascule des 21 agents en 5,1 secondes et aucune perte sur le flux témoin. Ce sont les résultats de ce banc : le dépôt explique comment le rejouer pour obtenir les vôtres.

Pour les équipes techniques : lancer REVERSOTEL

git clone https://forge.erythix.tech/labstraining/otel/reversotel.git
cd reversotel
demo/run.sh

Le scénario dure environ 20 à 30 minutes, plus la construction des images au premier lancement. Les fichiers de configuration de la flotte sont en YAML.

Suivre la flotte depuis Grafana

Une tour de contrôle a besoin d’écrans. Un dépôt compagnon, Reversotel-app, ajoute à Grafana trois pages pour suivre la flotte pilotée par REVERSOTEL. La première liste chaque Collector avec sa version, sa santé et l’état de sa configuration. La deuxième détaille un Collector, jusqu’à sa configuration effective. La troisième montre les écarts : les Collectors dont la configuration appliquée diffère de ce que demande Git, avec la différence ligne à ligne.

L’application est en lecture seule par construction. Git reste la seule source de vérité : elle ne modifie jamais une configuration, elle renvoie seulement vers le commit ou le fichier concerné dans la forge. Elle fonctionne aussi dans un environnement isolé d’Internet, sans rien charger de l’extérieur.

Pour les équipes techniques : prérequis et limites

L’application demande Grafana 11.6 ou plus récent ; le dépôt indique des tests sur les versions 11.6.16 et 13.2.4. Un backend en Go interroge l’API REST de REVERSOTEL avec un jeton, en TLS. Certains champs (nom du service, version du contrat par agent, arbre de santé des composants) sont des ajouts proposés à l’API de REVERSOTEL qui n’existent pas encore : en leur absence, l’application affiche « non renseigné ».

GENAIOTEL : tracer une application RAG sans SDK propriétaire

Une application RAG est un assistant qui va chercher des documents dans une base avant de demander à un modèle de langage de rédiger la réponse, comme un étudiant qui consulte ses notes avant de répondre à l’examen. Les outils d’observabilité de l’IA arrivent souvent avec leur propre bibliothèque de code à intégrer dans l’application (un SDK). La question du lab est simple : que peut-on obtenir avec le seul standard ?

L’application du lab n’émet que des signaux standard. Ce sont des spans (les étapes d’une trace) et des métriques qui suivent les conventions sémantiques GenAI d’OpenTelemetry, c’est-à-dire les noms communs que le standard donne aux données de l’IA générative. Tout l’enrichissement se fait ensuite dans la plateforme, avec des composants courants : le Collector calcule le coût de chaque étape et un connecteur produit la latence et le taux d’erreur par modèle. Le modèle de langage et le calcul des embeddings (la traduction des textes en vecteurs de nombres) sont simulés et donnent toujours le même résultat. Il n’y a ni clé d’API ni modèle à télécharger. Ce qui est réel, ce sont les traces et les métriques.

Le lab vous apprend à instrumenter un pipeline RAG avec les attributs standard, y compris les nouvelles tentatives et le repli vers un autre modèle. Il propose des scénarios qui répondent à des questions de production : une mauvaise journée, ce que le cache fait gagner, un index qui se dégrade sans erreur ni hausse de latence. Il sépare enfin deux choses qu’on confond souvent : l’observabilité pendant que l’application tourne et l’évaluation de la qualité des réponses, faite à part sur un jeu de référence.

Les conventions GenAI sont encore au statut Development, autrement dit susceptibles de changer. Le lab suit leur texte courant et isole chaque nom d’attribut dans une constante, pour qu’un renommage reste un changement d’une ligne.

Pour les équipes techniques : lancer GENAIOTEL

Le coût par span est calculé dans le Collector avec OTTL ; la latence et le taux d’erreur par modèle viennent du connecteur spanmetrics. Les attributs suivent l’espace de noms gen_ai.*.

git clone https://forge.erythix.tech/labstraining/otel/genaiotel.git
cd genaiotel
make build
make demo

make demo fait tourner l’application seule. make up, make demo-load puis make verify ajoutent la pile d’observabilité et contrôlent la chaîne maillon par maillon.

Dernière version pas encore rejouée

La version publiée le 10 octobre 2026 a été relue, mais je ne l’ai pas encore rejouée de bout en bout sous Docker. Si make verify signale un maillon cassé, écrivez-moi.

OTELAUDITEXP : prouver ce qui sort du Collector

Pensez à un envoi en recommandé : le destinataire sait qui l’a envoyé et quand, avec la garantie que l’enveloppe n’a pas été ouverte en route. Dans un contexte régulé, avec plusieurs clients sur la même plateforme, une équipe doit pouvoir apporter ce genre de preuve pour ses données : quels logs, métriques et traces sont sortis du Collector, pour quel client et sans altération. Les exporters OTLP, ces composants qui envoient les données vers leur destination avec le protocole standard d’OpenTelemetry, transmettent les données brutes sans aucune attestation.

Le lab est un exporter sur mesure pour le Collector. Il met chaque lot de données dans une enveloppe avant de l’envoyer vers un point de collecte. L’enveloppe porte l’identifiant du client, la version du schéma, un numéro de séquence qui augmente à chaque envoi, une empreinte du contenu (un calcul qui change dès qu’un seul caractère change), l’heure d’émission et le nombre d’éléments. Le destinataire recalcule l’empreinte pour détecter une altération et suit les numéros pour repérer un envoi manquant ou rejoué.

Vous y apprenez à écrire un composant du Collector sur ses interfaces officielles, puis à le construire. Vous y apprenez aussi quand un composant sur mesure se justifie : à mon avis, seulement quand le besoin ne s’exprime pas avec les composants existants. Le lab montre enfin les limites d’une preuve, que le dépôt documente : les compteurs de séquence repartent de zéro au redémarrage et un lot qui mélange plusieurs clients est attribué au premier trouvé.

Pour les équipes techniques : construire OTELAUDITEXP

Chaque lot de logs, de métriques ou de traces est sérialisé en OTLP JSON, enveloppé, puis posté vers un point de collecte HTTP. L’empreinte est un SHA-256 et la séquence est tenue par signal. Le composant se construit avec l’OpenTelemetry Collector Builder.

git clone https://forge.erythix.tech/labstraining/otel/otelauditexp.git
cd otelauditexp
go install go.opentelemetry.io/collector/cmd/builder@v0.155.0
builder --config examples/builder-config.yaml

Pour le raisonnement complet sur la preuve par les journaux, voir Intégrité des journaux.

Par lequel commencer ?

1. Vous découvrez OpenTelemetry : je recommande GENAIOTEL. Il ne demande que Docker et l’application tourne seule avant qu’on ajoute la pile d’observabilité.

2. Vous exploitez déjà des Collectors : REVERSOTEL, pour voir ce que change un pilotage par OpAMP.

3. Vous travaillez dans un contexte régulé ou vous développez pour le Collector : OTELAUDITEXP.

Les articles correspondants sont dans la rubrique OpenTelemetry. Les autres labs du site sont sur la page Labs.