OpenTelemetry comporte de nombreux éléments, et la plupart des confusions viennent du fait de les mélanger. Ce guide les sépare : ce qui s’exécute dans votre application, ce qui s’exécute à côté, et où chacun est configuré. Une fois la carte claire, le reste de la série consiste surtout à remplir du YAML.

Le problème résolu

Avant OpenTelemetry, chaque fournisseur de monitoring livrait son propre agent et son propre format de données. Changer de fournisseur signifiait ré-instrumenter chaque service, et utiliser deux outils signifiait exécuter deux agents. OpenTelemetry sépare les deux préoccupations : l’instrumentation produit une fois des données standard, et un pipeline décide où elles vont.

Les éléments

Élément	Ce que c’est	Où il s’exécute
API	Les interfaces que le code d’instrumentation appelle (démarrer un span, enregistrer une métrique)	Dans votre application
SDK	L’implémentation derrière l’API : échantillonnage, batching, export	Dans votre application
Instrumentation	Code qui crée de la télémétrie pour les bibliothèques (HTTP, bases de données)	Dans votre application, via des bibliothèques ou un agent sans code
OTLP	Le protocole de transport de la télémétrie, via gRPC ou HTTP	Entre les composants
Collector	Un service autonome qui reçoit, traite et exporte la télémétrie	À côté des applications, par nœud, ou en gateway central
Conventions sémantiques	Des noms standard pour les attributs, comme http.request.method	Partout

Les applications peuvent exporter directement vers un backend, mais placer un Collector entre les deux est la recommandation habituelle, car cela permet de changer le traitement et les destinations sans redéployer les applications.

Trois couches de configuration

1. Le SDK de l’application, configuré avec des variables d’environnement OTEL_* ou, de plus en plus, un fichier YAML déclaratif désigné par OTEL_CONFIG_FILE. Il contrôle le nom du service, les attributs de resource, le sampler et la destination d’export.
2. Le Collector, configuré avec un fichier YAML. Il contrôle ce qui est reçu, comment les données sont transformées et où elles vont.
3. La colle de la plateforme : fichiers Docker Compose, values Helm ou ressources Kubernetes de l’OpenTelemetry Operator, qui déploient le Collector et injectent la configuration dans les applications.

Tout dans ces couches est du texte, donc peut vivre dans Git.

Le flux de données en un schéma

┌────────────┐  OTLP   ┌─────────────────────────────┐        ┌───────────┐
│ App + SDK  │────────▶│ Collector                   │───────▶│ Traces    │
│ (variables │ 4317/   │ receivers → processors →    │───────▶│ Métriques │
│  ou YAML)  │ 4318    │ exporters (config.yaml)     │───────▶│ Logs      │
└────────────┘         └─────────────────────────────┘        └───────────┘

Les signaux en un coup d’œil

• Les traces enregistrent le parcours d’une requête à travers les services sous forme de spans. Elles répondent à « où est passé le temps ? »
• Les métriques sont des mesures numériques dans le temps, comme le nombre de requêtes et les histogrammes de latence. Elles répondent à « comment le système évolue-t-il ? »
• Les logs sont des enregistrements horodatés. OpenTelemetry peut les corréler avec les traces, de sorte qu’une ligne de log renvoie au span qui l’a produite.

Chaque signal a son propre pipeline dans le Collector, et son propre provider dans un SDK.

Stabilité : à lire avant d’adopter

OpenTelemetry est vaste et ses parties arrivent à maturité à des rythmes différents. Le protocole OTLP et les API de traces et de métriques sont stables. Les composants du Collector portent leurs propres niveaux de stabilité, et de nombreux composants contrib sont encore en bêta ou en alpha. La configuration déclarative des SDK a atteint un schéma stable en 2026, mais les implémentations des SDK rattrapent leur retard de façon inégale, Java et quelques autres étant en avance. Lorsque vous choisissez un composant ou une fonctionnalité, vérifiez sa stabilité dans la documentation, et épinglez les versions.

Un parcours suggéré à travers cette série

1. Exécutez un Collector et envoyez-lui des données (Docker Compose).
2. Apprenez le modèle de configuration du Collector.
3. Configurez les SDK avec des variables d’environnement et, lorsque c’est pris en charge, un fichier déclaratif.
4. Ajoutez l’instrumentation sans code à une application.
5. Préparez le Collector pour la production : batching, limites mémoire, retries, échantillonnage.
6. Déployez-le sur Kubernetes avec Helm ou l’Operator.
7. Collectez les logs et les métriques d’infrastructure, envoyez vers les backends en toute sécurité, et dépannez.

Pour référence, consultez la documentation OpenTelemetry.