OpenTelemetry a gagné la guerre de l'observabilité. Maintenant vient la partie difficile.

Le problème dont personne ne parle assez

Vous exécutez un système distribué en production. Quelque chose ne va pas — la latence a grimpé, les taux d'erreur ont augmenté, un utilisateur soumet un ticket de support. Votre premier réflexe est de regarder les logs. Mais quel service ? Vous en avez douze. Les logs sont là, quelque part, dispersés dans trois piles d'outillage différentes laissées par des ingénieurs qui sont partis depuis longtemps. Vous grepez. Vous pivotez. Vingt minutes plus tard, vous trouvez la cause racine : une requête de base de données qui a commencé à expirer parce qu'une migration de schéma a été exécutée sur le mauvais hôte.

C'est le problème de l'observabilité. Pas les alertes. Pas les tableaux de bord. Le problème fondamental : comprendre ce qui se passe réellement à l'intérieur de vos systèmes quand les choses tournent mal — et de plus en plus, avant qu'elles ne tournent mal. Les trois signaux canoniques sont les logs (événements discrets), les métriques (mesures numériques dans le temps), et les traces (le parcours d'une requête à travers un système distribué). Avant OpenTelemetry, collecter les trois de manière cohérente et portable était vraiment pénible.

L'ère du verrouillage

Chaque fournisseur d'observabilité — Datadog, New Relic, Dynatrace, Honeycomb, Jaeger — livrait son propre SDK. Son propre agent. Son propre protocole filaire. Si vous instrumentiez votre service Python avec le traceur Datadog et décidiez plus tard d'évaluer Honeycomb, vous deviez réécrire votre couche d'instrumentation. Non pas parce que les fournisseurs étaient malveillants, mais parce qu'il n'y avait pas de standard. La couche de collecte de télémétrie était le fossé.

Ce n'était pas une gêne mineure. Cela signifiait que les équipes prenaient des décisions de fournisseur tôt, avant d'avoir suffisamment de données de production pour savoir ce dont elles avaient réellement besoin. Cela signifiait que les équipes de plateforme passaient des cycles d'ingénierie à maintenir plusieurs pipelines de télémétrie. Cela signifiait que les coûts de changement étaient suffisamment élevés pour que la plupart des équipes ne changent tout simplement pas — même lorsqu'un meilleur outil arrivait.

D'où vient OpenTelemetry

En 2019, deux projets open-source concurrents d'observabilité — OpenCensus (soutenu par Google) et OpenTracing (un projet CNCF) — ont fusionné pour former OpenTelemetry. La fusion a évité ce qui aurait été une fragmentation dommageable de l'écosystème. OpenTelemetry est devenu un projet CNCF, et il a grandi rapidement. Par nombre de contributeurs, c'est désormais le deuxième projet CNCF le plus actif après Kubernetes.

La proposition de valeur était simple : instrumenter une fois, exporter partout. Un SDK par langage. Un protocole filaire — OTLP (OpenTelemetry Protocol). Un collecteur — otel-collector — pour recevoir, traiter et exporter la télémétrie vers n'importe quel backend. Les fournisseurs rivalisent sur l'analyse et la visualisation, pas sur le verrouillage de l'instrumentation.

L'état d'OTel en 2026

Le pari a payé. OpenTelemetry est déployé en production chez Google, Microsoft, Shopify, Uber et des milliers d'autres organisations. Tous les grands backends d'observabilité — Datadog, Grafana, Elastic, Honeycomb, Dynatrace, New Relic, Splunk — acceptent OTLP nativement. La CNCF rapporte qu'OpenTelemetry est utilisé d'une manière ou d'une autre dans 83 % des entreprises du Fortune 500. Ce n'est plus un projet de niche. C'est une infrastructure.

Les SDK Go, Java, Python et JavaScript sont stables et bien maintenus. L'auto-instrumentation pour les frameworks populaires — Django, Express, Spring Boot, Rails — fonctionne de manière fiable. Vous pouvez ajouter une seule dépendance, définir quelques variables d'environnement, et avoir des traces qui circulent vers votre backend sans toucher au code applicatif. Pour les projets greenfield, c'est le point de départ évident.

Ce qui fonctionne réellement

Les traces sont la partie la plus solide de l'histoire d'OTel. La spécification des traces est mature. Les SDK sont stables. L'auto-instrumentation pour HTTP, les appels de base de données et les systèmes de messagerie couvre les besoins d'instrumentation les plus courants. Si vous commencez avec OTel aujourd'hui, commencez ici.

Le otel-collector est puissant et éprouvé en production. Il peut recevoir de la télémétrie de dizaines de sources, appliquer des transformations, filtrer le bruit, et distribuer vers plusieurs backends simultanément. Les équipes qui gèrent des environnements multi-cloud complexes utilisent le collecteur comme une couche de routage de télémétrie — exporter tout vers le collecteur, laisser le collecteur gérer le routage vers le backend.

L'écosystème a également mûri autour du collecteur. Les récepteurs et exportateurs contrib couvrent la plupart des sources de données d'entreprise. L'opérateur pour Kubernetes est solide. Les distributions du collecteur par les fournisseurs (comme la AWS Distro for OpenTelemetry ou le Grafana Agent) fournissent des builds testés et supportés avec des exportateurs spécifiques aux fournisseurs préconfigurés.

Ce qui reste difficile

Les logs ne sont stables que récemment dans la spécification OTel. Le signal de journalisation a pris du retard par rapport aux traces et aux métriques de manière significative, et bien qu'il soit maintenant stable, l'écosystème n'a pas complètement rattrapé son retard. Corréler les logs avec les traces en utilisant TraceId et SpanId — ce qui est tout l'intérêt — nécessite encore un câblage délibéré dans la plupart des frameworks. Cela fonctionne, mais ce n'est pas encore sans effort.

Les conventions sémantiques des métriques sont incohérentes entre les langages. Une métrique nommée d'une certaine manière dans le SDK Java est nommée légèrement différemment dans le SDK Python. Cela est en cours de résolution, mais lentement. Les équipes qui construisent des tableaux de bord multi-langages rencontrent cette friction.

La configuration du collecteur est complexe. La configuration YAML du otel-collector — récepteurs, processeurs, exportateurs, pipelines — est flexible mais verbeuse. À mesure que les topologies grandissent, vous vous retrouvez avec des fichiers YAML qui sont vraiment difficiles à raisonner. Il n'y a pas encore de bonne solution ici. Certaines équipes utilisent jsonnet ou cue pour générer des configurations de collecteur. D'autres écrivent des outils de gestion de configuration. C'est un problème soluble, mais c'est un vrai travail opérationnel.

L'échantillonnage basé sur la fin est puissant mais lourd sur le plan opérationnel. L'échantillonnage basé sur le début (prendre la décision d'échantillonnage au début d'une trace) est simple et sans état. L'échantillonnage basé sur la fin (prendre la décision d'échantillonnage après avoir vu la trace complète) vous permet de conserver 100 % des traces d'erreur et des traces lentes tout en abandonnant les traces de routine — mais cela nécessite une infrastructure avec état. Le processeur tailsampling dans le collecteur OTel fonctionne, mais il nécessite une architecture de déploiement minutieuse pour garantir que toutes les spans d'une trace donnée atterrissent sur la même instance de collecteur.

Le problème de cardinalité qu'OTel n'a pas résolu

OpenTelemetry facilite l'ajout d'attributs à votre télémétrie. C'est une fonctionnalité. C'est aussi un piège. Ajouter des attributs à haute cardinalité — identifiants utilisateur, identifiants de requête, jetons de session — aux métriques est une erreur classique qui provoque des explosions de coûts sur les backends qui facturent par série de métriques (ce qui est le cas de la plupart).

OTel ne vous protège pas de cela. Il transmet fidèlement tous les attributs que vous attachez. L'explosion de cardinalité est un problème de backend, mais OTel est le mécanisme par lequel vous le créez. Les équipes qui adoptent OTel doivent comprendre cela tôt : la gouvernance de la cardinalité des métriques n'est pas optionnelle, c'est une hygiène opérationnelle. Utilisez les attributs à haute cardinalité sur les spans et les logs, là où ils appartiennent. Gardez les dimensions des métriques faibles et délibérément limitées.

Le quatrième signal : le profilage

OpenTelemetry travaille sur un quatrième signal d'observabilité : le profilage continu. Les données de profilage — graphiques de flamme CPU, traces d'allocation mémoire — ont historiquement vécu dans des outils séparés (pprof, async-profiler, py-spy) sans format standard ni corrélation avec les trois autres signaux.

Le signal de profilage OTel est encore expérimental, mais Grafana, Elastic et plusieurs autres fournisseurs parient déjà dessus. L'objectif est le même que pour les autres signaux : un format standard, un protocole filaire standard, une corrélation avec les traces. Lorsqu'il se stabilisera, il comblera la dernière lacune majeure dans l'histoire de l'observabilité d'OTel.

Conseils pratiques pour les équipes adoptant OTel aujourd'hui

• Commencez par les traces. Le signal de traçage est le plus mature. Utilisez d'abord l'auto-instrumentation — n'instrumentez pas manuellement avant d'avoir vu ce que l'auto-instrumentation vous donne.
• Choisissez votre backend avant de configurer le collecteur. La configuration du pipeline du collecteur dépend de l'endroit où vous exportez. Ne construisez pas une topologie de collecteur complexe avant de connaître votre backend. Un seul exportateur suffit pour commencer.
• Ne déployez pas une topologie de collecteur personnalisée prématurément. Les points de terminaison OTLP gérés par la plupart des fournisseurs sont suffisants pour la plupart des équipes. Le collecteur ajoute une surcharge opérationnelle. Ajoutez-le lorsque vous avez besoin de distribution, de filtrage ou d'enrichissement — pas avant.
• Comprenez la cardinalité avant d'ajouter des attributs de métriques. Ayez une conversation avec le responsable de la facture d'observabilité avant d'expédier votre première métrique personnalisée. Définissez explicitement votre ensemble d'étiquettes autorisé.
• Utilisez les SDK, pas l'API directement. L'API OTel est le contrat stable ; le SDK est l'implémentation. Dans le code applicatif, dépendez du SDK. Ne dépendez directement de l'API que si vous écrivez une bibliothèque qui ne doit pas imposer un choix de SDK aux consommateurs.

La guerre est gagnée. Le travail n'est pas terminé.

OpenTelemetry a accompli quelque chose de vraiment rare dans les logiciels d'infrastructure : il a tué le problème du verrouillage de l'instrumentation. Les fournisseurs rivalisent sur la qualité de leur analyse, leurs langages de requête, leurs alertes, leur UX — pas sur le fait de vous piéger dans leur SDK. C'est un monde meilleur.

Mais "le standard a gagné" est le début de l'histoire, pas la fin. La partie difficile — des conventions cohérentes entre langages, une configuration de collecteur accessible, des logs stables, une gouvernance de la cardinalité, le profilage — est encore en cours de résolution. Les équipes qui adoptent OTel aujourd'hui le font dans un écosystème mature mais encore en évolution. C'est bien. Les fondations sont solides. Construisez dessus délibérément.