OpenTelemetry en 2026 : traces, métriques et logs pour vos applications Node.js

Comprendre ce qui se passe à l'intérieur de vos applications en production est devenu aussi important que de les coder correctement. OpenTelemetry — le standard ouvert de la CNCF pour l'observabilité — unifie en 2026 la collecte de traces distribuées, de métriques et de logs sous une API unique, compatible avec Jaeger, Grafana, Datadog, Prometheus et tous les backends d'observabilité du marché. Découvrez comment instrumenter vos applications Node.js, Next.js et Express de A à Z.

Pourquoi l'observabilité est devenue indispensable

Dans une architecture monolithique simple, un log en console suffit souvent à localiser un bug. Mais dès que votre application se distribue en micro-services, fonctions serverless ou containers orchestrés par Kubernetes, la visibilité s'effondre : une requête utilisateur traverse cinq services avant d'échouer, sans qu'il soit possible de retracer son chemin. L'observabilité répond à ce défi avec trois piliers complémentaires : les traces (le parcours complet d'une requête), les métriques (données agrégées sur le temps — latences, taux d'erreur, saturation CPU) et les logs (événements structurés corrélés aux traces). OpenTelemetry standardise la collecte de ces trois signaux dans un SDK unique pour éviter le vendor lock-in avec un fournisseur spécifique comme Datadog ou New Relic.

Instrumenter Node.js avec le SDK OpenTelemetry

L'installation du SDK Node.js se fait en quelques commandes : npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-http. Le package auto-instrumentations-node est particulièrement précieux : il instrumente automatiquement Express, HTTP, gRPC, MongoDB, PostgreSQL, Redis et une quarantaine d'autres bibliothèques sans modifier une seule ligne de votre code métier. Il suffit de créer un fichier tracing.ts qui initialise le NodeSDK avec votre exporter OTLP, puis de le charger en premier avec node --require ./tracing.js. Vos spans apparaissent immédiatement dans Jaeger ou Tempo sans aucune modification de votre logique applicative.

Traces distribuées : suivre une requête à travers plusieurs services

La vraie puissance d'OpenTelemetry s'exprime dans les architectures multi-services. Chaque span porte un trace context propagé automatiquement via les en-têtes HTTP W3C traceparent et tracestate. Lorsqu'un service A appelle un service B, le contexte est transmis et B crée un span enfant rattaché au même traceId. Le résultat est une vue en cascade dans Jaeger ou Grafana Tempo : on voit exactement quelle base de données a mis 800 ms à répondre, quel appel réseau a échoué et où le timeout s'est produit. Pour les spans personnalisés, l'API est minimaliste : tracer.startActiveSpan('nom', span => { /* code */ span.end(); }), avec la possibilité d'ajouter des attributs métier comme l'ID utilisateur ou le montant d'une transaction.

Métriques et logs : compléter le tableau de bord

Les traces révèlent le parcours d'une requête individuelle, mais les métriques agrégées sont nécessaires pour surveiller la santé globale de vos services : latence P95/P99, nombre de requêtes par seconde, taux d'erreur HTTP 5xx. Avec l'API MeterProvider d'OpenTelemetry, vous créez des counters, histograms et gauges qui s'exportent vers Prometheus via l'exporter Prometheus ou vers Grafana Mimir en OTLP. Pour les logs, le LoggerProvider structure vos événements au format OTLP avec corrélation automatique au traceId en cours — ce qui permet, dans Grafana, de passer d'un log d'erreur à la trace correspondante en un clic. L'OpenTelemetry Collector, déployé comme sidecar ou DaemonSet Kubernetes, joue le rôle de proxy central : il reçoit tous les signaux, les enrichit (ajout du nom du pod, de la version de l'app) et les route vers plusieurs backends simultanément.