OpenTelemetry a gagné la guerre de l'observabilité — et maintenant ?

Le problème du verrouillage est résolu

Pendant la majeure partie des années 2010, choisir un fournisseur d'observabilité signifiait épouser sa bibliothèque d'instrumentation. Les agents Datadog, les SDK New Relic, les beelines propriétaires de Honeycomb — chacun verrouillait votre code applicatif à un backend spécifique. Changer de fournisseur signifiait réinstrumenter chaque service. Cette époque est révolue.

OpenTelemetry est désormais le standard de facto pour le traçage distribué, les métriques et les logs. AWS, GCP, Azure, Datadog, Honeycomb, Grafana, New Relic, Dynatrace et toutes les grandes plateformes d'observabilité le supportent nativement. Vous instrumentez une fois. Vous acheminez où vous voulez.

Ce qu'est réellement OpenTelemetry

OpenTelemetry est un projet CNCF — diplômé en 2021 — né de la fusion de deux standards concurrents : OpenCensus (Google) et OpenTracing (CNCF). Cette fusion est importante car elle a mis fin à la fragmentation. Avant OpenTelemetry, il fallait choisir un camp ; maintenant il n'y a plus qu'un seul standard.

Le projet définit trois signaux d'observabilité :

Traces : flux de requêtes distribués à travers les frontières des services, représentés sous forme d'arborescence de spans avec timing et attributs.
Metrics : mesures numériques agrégées — compteurs, jauges, histogrammes — pour les tableaux de bord et les alertes.
Logs : enregistrements structurés d'événements pouvant être corrélés aux traces et aux métriques via un contexte partagé (trace ID, span ID).

L'architecture comporte deux composants principaux : le SDK (intégré dans votre application) et le Collector (un binaire autonome qui reçoit, traite et exporte la télémétrie). Comprendre la séparation entre ces deux éléments est la clé que la plupart des équipes manquent.

La spécification vs. le SDK : pourquoi la séparation est importante

OpenTelemetry définit une spécification d'API distincte de l'implémentation du SDK. C'est délibéré. Les auteurs de bibliothèques peuvent instrumenter leur code contre l'API sans prendre de dépendance dure sur un SDK spécifique. Lorsque votre application s'exécute sans SDK configuré, ces appels API deviennent des no-op. Aucun coût.

Lorsque vous configurez un SDK, il se connecte à l'API et commence à exporter. Le SDK gère le batching, la logique de retry, l'échantillonnage et la propagation du contexte. La spécification définit le contrat ; le SDK fournit l'implémentation. C'est cette architecture qui permet à OpenTelemetry de revendiquer une instrumentation sans coût pour les déploiements non instrumentés — une revendication qui compte pour les auteurs de bibliothèques livrant à une large base d'utilisateurs.

L'implication pratique : instrumentez vos bibliothèques contre l'API OTel. Instrumentez vos applications contre le SDK. Ne laissez jamais une bibliothèque prendre une dépendance dure sur le SDK.

Auto-instrumentation vs. spans manuelles

OpenTelemetry fournit une auto-instrumentation spécifique à chaque langage qui patche les frameworks et bibliothèques populaires sans modification de code :

Java : un agent Java (-javaagent:opentelemetry-javaagent.jar) qui instrumente Spring, Tomcat, gRPC, JDBC et des dizaines d'autres bibliothèques via manipulation de bytecode au démarrage.
Python : opentelemetry-instrument python app.py — instrumente Django, Flask, FastAPI, SQLAlchemy, les clients Redis, etc. automatiquement.
Node.js : incluez le package @opentelemetry/auto-instrumentations-node et il se branche sur Express, HTTP, gRPC, MySQL, Postgres et autres via patching de modules.

L'auto-instrumentation vous donne une visibilité au niveau infrastructure immédiatement. Vous verrez les durées des requêtes HTTP, la latence des requêtes base de données, les appels API externes — toute la plomberie mécanique — sans toucher au code applicatif.

Mais l'auto-instrumentation ne sait pas ce que votre code signifie. Elle ne peut pas vous dire que le service de checkout est lent à cause d'une règle spécifique de validation de code promo. Pour la visibilité métier, vous avez besoin de spans manuelles :

Encapsulez toute opération pouvant échouer ou sensible à la latence dans une span personnalisée.
Ajoutez des attributs sémantiques : user ID, order ID, variante d'expérience, valeurs de feature flags.
Enregistrez les exceptions explicitement avec span.recordException(err) et span.setStatus({code: ERROR}).

La bonne approche : utilisez l'auto-instrumentation comme base, ajoutez des spans manuelles à chaque point de décision qui compte pour votre métier. Commencez par l'auto, ajoutez du manuel progressivement en apprenant quelles questions vous ne pouvez pas répondre.

Le Collector est le pivot architectural

La plupart des équipes commencent par envoyer la télémétrie directement depuis le SDK de leur application vers un backend. Cela fonctionne mais abandonne la fonctionnalité la plus précieuse de l'architecture OTel : le pipeline du Collector.

Le OTel Collector est un proxy indépendant du fournisseur qui se place entre vos applications et vos backends. Configurez-le avec des receivers (OTLP, Jaeger, Prometheus, Zipkin), des processors (échantillonnage, manipulation d'attributs, nettoyage PII) et des exporters (Datadog, Honeycomb, Tempo, CloudWatch — n'importe quelle combinaison).

Pourquoi cela compte en pratique :

Fan-out : envoyez les traces vers Honeycomb pour l'exploration ET vers Grafana Tempo pour la conservation long terme simultanément. Aucune modification d'application requise.
Nettoyage PII : supprimez ou hachez les attributs sensibles (adresses email, adresses IP, tokens de session) avant qu'ils ne quittent votre périmètre réseau — avant que toute donnée n'atteigne un fournisseur.
Décisions d'échantillonnage : appliquez un tail-based sampling au niveau du Collector, en conservant les traces d'erreur et lentes, en jetant les traces saines et rapides.
Migration de backend : passez de Datadog à Grafana en changeant un fichier de configuration du Collector. Votre instrumentation applicative reste inchangée.

Déployez le Collector en sidecar dans Kubernetes ou en DaemonSet. Pour les environnements à fort trafic, déployez une architecture en couches : des Collectors sidecar par pod qui transfèrent vers des Collectors passerelle gérant le tail sampling sur l'ensemble de la population de requêtes.

Stratégies d'échantillonnage : head-based vs. tail-based

Traquer chaque requête en pleine fidélité coûte cher. À 10 000 requêtes par seconde, stocker chaque trace coûte de l'argent réel. L'échantillonnage n'est pas optionnel à grande échelle — mais la stratégie d'échantillonnage détermine ce que vous pouvez réellement déboguer.

Head-based sampling prend la décision de conserver ou jeter au début d'une requête, avant que les spans en aval ne soient créées. C'est simple à implémenter et a un overhead minimal. Le problème : vous ne pouvez pas échantillonner en fonction de résultats que vous ne connaissez pas encore. Vous pourriez jeter la seule requête qui a échoué. À 1% d'échantillonnage head, vous n'aurez régulièrement aucune trace pour vos bugs les plus intéressants.

Tail-based sampling met en mémoire tampon toutes les spans d'une trace et ne prend la décision qu'une fois la trace entièrement terminée. Cela vous permet de :

Conserver 100% des traces contenant une span d'erreur.
Conserver 100% des traces dépassant un seuil de latence (ex: P99 > 2 secondes).
Conserver un pourcentage configurable de traces saines et rapides (ex: 1% de base).

Le processeur tailsampling du Collector OTel implémente cela. Configurez des policies en YAML : combinez des policies basées sur le statut d'erreur avec des policies de latence et une base probabiliste. Le résultat est un corpus de traces composé de manière disproportionnée des cas intéressants que vous voulez réellement déboguer.

Le coût opérationnel : le tail-based sampling nécessite de mettre en mémoire tampon les spans en vol dans la mémoire du Collector. Pour des décisions significatives, vous avez besoin que toutes les spans d'une trace donnée atteignent la même instance de Collector — typiquement via un load balancing basé sur le trace ID devant un pool de Collectors. C'est plus d'infrastructure à opérer, mais l'amélioration de la capacité de débogage n'est pas marginale. C'est la différence entre voir chaque erreur et n'en voir aucune.

L'état actuel des trois signaux

Les signaux d'OpenTelemetry ont mûri à des rythmes différents :

Traces : GA et stable depuis 2021. Le signal le plus mature. Les conventions sémantiques pour HTTP, gRPC, base de données, systèmes de messagerie sont bien établies et stables. Utilisez-le en premier.
Metrics : GA et stable depuis 2022. Le protocole OTLP pour les métriques est prêt pour la production. Les conventions sémantiques couvrent les métriques serveur et client HTTP, les métriques runtime (JVM, Python runtime) et les métriques système.
Logs : Stable depuis 2023. Le modèle de données des logs et le protocole OTLP logs permettent aux logs structurés de porter le contexte de trace (trace ID, span ID), permettant la corrélation entre logs et traces dans les backends qui le supportent. La corrélation Grafana Loki + Tempo est l'implémentation la plus mature aujourd'hui.

Les conventions sémantiques sont ce qui fait fonctionner la corrélation entre signaux. Quand votre span HTTP et votre métrique HTTP utilisent les mêmes noms d'attributs (http.request.method, http.response.status_code, server.address), les backends peuvent les joindre. Respectez les conventions sémantiques publiées — n'inventez pas vos propres noms d'attributs pour des opérations standard.

Paysage des fournisseurs en 2026

Avec une instrumentation désormais indépendante du fournisseur, le choix du backend repose sur le modèle de requêtage, le coût et la préférence opérationnelle :

Honeycomb : Le produit le plus tranché et sans doute le meilleur pour l'exploration de traces. BubbleUp pour la découverte automatique de corrélations, support des colonnes à haute cardinalité, et un modèle de requêtage construit autour d'événements de largeur arbitraire. Meilleur pour les équipes qui veulent faire de l'analyse de traces sophistiquée et sont prêtes à payer pour un produit managé.
Stack Grafana (LGTM) : Loki (logs) + Grafana (tableaux de bord) + Tempo (traces) + Mimir (métriques). Entièrement open source, auto-hébergeable, ou disponible en version managée via Grafana Cloud. La stack LGTM est le bon choix pour les équipes qui veulent posséder leur infrastructure et éviter tout verrouillage fournisseur. Les corrélations trace-à-logs et trace-à-métriques de Tempo fonctionnent bien quand tout utilise les conventions sémantiques OTel.
Datadog : Excellent support d'ingestion OTel via l'agent Datadog (qui parle OTLP). Meilleur pour les équipes déjà sur Datadog pour l'APM et la surveillance d'infrastructure qui veulent standardiser sur l'instrumentation OTel tout en conservant l'interface utilisateur et les alertes Datadog. Le coût monte fortement avec le volume de données.
AWS CloudWatch : L'AWS Distro for OpenTelemetry (ADOT) fournit des Collectors OTel managés par AWS et une intégration profonde avec CloudWatch, X-Ray et Amazon Managed Grafana. Choix pratique pour les équipes AWS-first qui veulent minimiser la surface opérationnelle. La visualisation des traces de X-Ray est fonctionnelle mais moins expressive que Honeycomb ou Tempo.

Ce qui reste difficile

OpenTelemetry n'a pas tout résolu. Soyons honnêtes sur ce qui reste rugueux :

Signal de profiling : La spécification de profiling (profilage continu CPU et mémoire corrélé aux traces) est en développement mais pas encore stable à mi-2026. Attendez-vous à ce qu'elle atteigne GA en 2026 ou 2027. En attendant, le profiling reste spécifique au fournisseur.
Corrélation des métriques métier : Relier une requête base de données lente à son impact sur le chiffre d'affaires nécessite de joindre les données d'observabilité avec les données d'événements métier. OpenTelemetry ne définit pas comment faire cela. Vous devez ajouter des attributs métier à vos spans (valeur de commande, palier utilisateur, chemin générateur de revenus) et construire l'analyse vous-même dans votre backend.
Complexité de configuration du Collector : Une configuration de Collector OTel en production avec tail sampling, multiples exporters, nettoyage PII et transformations d'attributs peut atteindre des centaines de lignes de YAML. Le Collector a un modèle de pipeline étendu, mais la courbe d'apprentissage pour les configurations complexes est réelle. Utilisez l'OTel Collector Builder et testez les configurations localement avec l'exporter file avant de déployer.

Pour commencer : instrumentez un service en 5 étapes

Pour un service Node.js (le même modèle s'applique à Python avec des packages équivalents) :

Étape 1 — Installez les packages : npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-http
Étape 2 — Créez un fichier d'instrumentation (tracing.js) : Initialisez le NodeSDK avec le nom de votre service, le plugin d'auto-instrumentations, et un exporter OTLP HTTP pointant vers votre endpoint Collector ou directement vers une URL d'ingestion OTLP d'un fournisseur.
Étape 3 — Démarrez le SDK avant votre app : Dans votre point d'entrée, appelez sdk.start() avant de require les autres modules. Pour Node.js, utilisez --require ./tracing.js dans votre commande de démarrage.
Étape 4 — Ajoutez des spans manuelles pour la logique métier : Encapsulez le checkout, le traitement des paiements, les requêtes de recommandations — tout ce qui a une signification métier — dans des spans personnalisées. Ajoutez des attributs pour order ID, segment utilisateur et flags d'expérience.
Étape 5 — Déployez un Collector sidecar : Exécutez le Collector OTel aux côtés de votre service, configuré pour recevoir OTLP sur localhost:4318 et exporter vers le backend choisi. Cela découple la configuration du backend du déploiement de l'application.

Cadre de décision actionnable

Voici comment prendre les décisions clés sans trop les réfléchir :

Priorité des signaux : Implémentez les traces en premier, puis les métriques, puis les logs. Les traces vous donnent le plus de levier de débogage par unité d'effort d'instrumentation. Les logs sont précieux mais vous les avez probablement déjà — concentrez-vous sur leur connexion aux traces via l'injection de contexte de trace.
Sélection du backend : Si vous auto-hébergez, utilisez la stack Grafana LGTM. Si vous voulez du managé avec une excellente UX pour l'analyse de traces, utilisez Honeycomb. Si vous êtes déjà sur Datadog pour la surveillance infra, standardisez sur l'instrumentation OTel et gardez Datadog comme backend. N'optimisez pas trop tôt le choix du backend — l'intérêt d'OTel est que vous pouvez changer d'avis.
Collector dès le premier jour : Même si vous n'avez qu'un seul backend aujourd'hui, déployez le Collector. Le coût est minime ; le gain de flexibilité lorsque vous ajoutez un deuxième backend ou devez changer de fournisseur est significatif.
Politique d'échantillonnage : Commencez par un head-based sampling à 10-20% si vous devez contrôler les coûts immédiatement. Prévoyez de migrer vers le tail-based sampling une fois que vous avez un pool de Collectors — l'amélioration de la visibilité des erreurs vaut la complexité opérationnelle.
Conventions sémantiques : Faites-les respecter. Ajoutez une étape de lint ou un check CI qui valide que les noms d'attributs de vos spans personnalisées sont conformes au registre des conventions sémantiques OTel. La cohérence maintenant signifie une corrélation entre signaux plus tard, et signifie que tout nouveau backend que vous adopterez comprendra vos données sans transformation.

Les guerres des fournisseurs d'observabilité sont terminées. Le problème de l'instrumentation est résolu. Ce qui reste, c'est la discipline opérationnelle pour le déployer correctement, configurer votre pipeline pour le coût et la fidélité, et construire les habitudes organisationnelles autour du débogage piloté par les traces. Ces habitudes — aller aux traces en premier quand quelque chose est lent, annoter les déploiements comme attributs de trace, écrire des runbooks qui référencent des attributs de spans spécifiques — sont ce qui sépare les équipes qui tirent de la valeur de l'observabilité de celles qui ont juste des tableaux de bord.