OpenTelemetry : préparer les migrations 2027 sans fragiliser l’observabilité

Deux annonces à distinguer

Le SDK JavaScript 3.0 est disponible depuis le 5 novembre. Cette version apporte notamment de nouveaux exports ESM et CommonJS, regroupe certains packages et stabilise le signal Logs pour JavaScript. Elle implique aussi des changements de compatibilité pour les applications qui intègrent directement le SDK.

Pour le Collector, le calendrier est différent. Le 11 novembre, le projet a annoncé la dépréciation du processeur batch historique. L’activation par défaut du batching dans la plupart des exporters est prévue pour la version 0.171.0, en février 2027. Le retrait du processeur du cœur du Collector est envisagé dans la version 0.177.0, en mai 2027. Ces dates restent prévisionnelles.

JavaScript 3.0 : commencer par les versions de Node.js

Le nouveau SDK exige Node.js 22.15.0 ou une version ultérieure. Une application encore exécutée sous Node.js 18 ou 20 devra donc faire évoluer son environnement avant d’adopter le SDK 3.x. La consolidation de packages, le déplacement de certains types publics et la suppression de modules devenus obsolètes peuvent également demander des adaptations.

Il faut toutefois distinguer les usages. Le package @opentelemetry/api conserve sa compatibilité, et le projet indique que l’instrumentation automatique standard avec @opentelemetry/auto-instrumentations-node ne requiert pas, à elle seule, de changement de configuration. Les SDK stables 2.x restent pris en charge pendant un an à compter de la sortie de la version 3.0. Rien n’impose donc une bascule précipitée sur l’ensemble du parc.

Collector : attention à la capacité des files d’attente

Le changement le plus sensible concerne le traitement des lots. Le batching peut désormais être réalisé dans la sending_queue de l’exporter. Lorsque le traitement doit rester dans un processeur, le nouveau composant queue_batch constitue une alternative.

Le remplacement du processeur batch ne consiste pas à supprimer une ligne de configuration. Jusqu’ici, une file pouvait conserver des requêtes déjà regroupées en lots. Avec le batching placé après la file, elle reçoit des requêtes individuelles, souvent plus petites. À capacité nominale identique, elle peut donc retenir moins de données avant saturation.

Le projet OpenTelemetry recommande d’examiner la taille et l’unité de mesure de la file, le nombre de consommateurs et le comportement en cas de surcharge. Les métriques otelcol_exporter_queue_size et otelcol_exporter_queue_capacity sont particulièrement utiles pour contrôler la situation après migration.

Le risque : des données manquantes sans panne visible

Un changement de pipeline peut laisser les applications fonctionner normalement tout en dégradant la visibilité sur leur activité. Des traces arrivent en retard, des logs ne sont plus exportés ou la file d’attente sature lors d’une indisponibilité du backend. Le problème n’apparaît parfois qu’au moment d’investiguer un incident.

Dans un environnement de production, le contrôle ne doit donc pas se limiter à vérifier que le Collector démarre. Il faut comparer les volumes reçus et exportés, rechercher les données rejetées, mesurer les délais de transmission et observer le comportement lors d’une coupure temporaire de la destination.

Une migration en trois temps : auditer, tester, migrer

Auditer. Recenser les versions de Node.js et des bibliothèques OpenTelemetry côté applications. Relever les versions des Collectors, les exporters utilisés et les pipelines qui déclarent encore le processeur batch. Identifier les services dont la télémétrie est indispensable aux engagements de production.

Tester. Sur un environnement représentatif, comparer les volumes et la qualité des signaux avant et après modification. Simuler un pic de trafic et une indisponibilité de la plateforme cible. Vérifier les files d’attente, les rejets, la mémoire consommée et le retour à la normale.

Migrer. Avancer par lots maîtrisés, avec une configuration précédente conservée pour le retour arrière. Prévoir des seuils de contrôle et faire valider les résultats par les équipes qui utilisent les données pour exploiter les services.

Le regard ADN Consulting

L’enjeu n’est pas de passer au plus vite sur la dernière version. C’est de conserver une chaîne d’observabilité fiable, depuis l’instrumentation des applications jusqu’aux outils d’analyse.

Pour une DSI ou une équipe MCO, le bon point de départ est un inventaire court mais précis : quelles applications sont concernées, quels Collectors utilisent encore batch et quelles données sont critiques pour le diagnostic ? Cet état des lieux permet de fixer un calendrier de migration réaliste et de traiter en priorité les environnements les plus exposés.