Un câble USB-C noir, enroulé, posé sur une surface de béton poli sous un éclairage dramatique.

OpenTelemetry JS passe en version 3.0 avec des changements majeurs

L’annonce de la sortie des SDK OpenTelemetry JavaScript 3.0 marque un tournant pour les développeurs qui intègrent la télémétrie dans leurs applications Node.js. Cette nouvelle génération, avec les paquets stables à partir de la version 3.0.0, apporte des changements structurels importants, notamment en ce qui concerne la gestion des modules et la consolidation des outils. Selon les directives OpenTelemetry, les versions 2.x des SDK stables bénéficieront d’un an de support après la sortie de la 3.0.0.

Ce passage au 3.x s’accompagne d’un durcissement des exigences d’environnement. Pour être compatible avec cette mise à jour, l’environnement Node.js doit désormais être au minimum la version 22.15.0. Cela signifie que le support pour Node.js 18 et 20 est abandonné. Ce changement, bien que technique, impose une vérification immédiate des environnements de production.

Mutations techniques et refonte des APIs

Plusieurs bibliothèques ont été fusionnées ou remplacées. Par exemple, les anciens packages de tracing comme @opentelemetry/sdk-trace-node ont été remplacés par le package unique @opentelemetry/sdk-trace. Cette consolidation vise à homogénéiser les interfaces et à éliminer des API ambiguës. De même, des implémentations antérieures, telles que le shim d’OpenTracing ou les exportateurs Jaeger, ont été retirées, car la spécification OpenTelemetry privilégie désormais les protocoles standards comme l’OTLP.

Le changement le plus perceptible pour les utilisateurs avancés concerne la manière dont les packages sont structurés. Tous les paquets livrent désormais des exports ESM et CJS corrects, ce qui devrait être plus amical pour les utilisateurs de bundlers. Cependant, ceci est assorti d’une contrainte stricte : les importations profondes (deep imports) dans la structure interne des packages ne sont plus supportées. Les développeurs habitués à importer des sous-chemins spécifiques dans le node_modules devront adapter leur code pour se référer aux points d’entrée officiels définis dans les fichiers package.json.

Illustration en collage de papier découpé montrant des blocs de code s'organisant en couches superposées.

L’impact sur les schémas d’instrumentation

La stabilisation du signal Logs est notable. Le package @opentelemetry/api-logs a été intégré directement dans @opentelemetry/api, signifiant que les trois signaux principaux (Traces, Métriques, Logs) sont désormais considérés comme stables en JavaScript. Parallèlement, la capacité à gérer des attributs complexes, conformément à OTEP 4485, est ajoutée à certaines parties de l’API, bien que certains domaines, comme les métriques, limitent encore le support aux attributs simples.

L’interface publique a subi des modifications : des types et des noms de classes ont été renommés ou déplacés. Bien que l’API elle-même ne présente pas de rupture de compatibilité pour les utilisateurs qui ne font que de l’instrumentation automatique via @opentelemetry/auto-instrumentations-node, la migration manuelle des SDKs nécessite une lecture attentive du guide d’évolution. Les détails précis des changements sont disponibles dans le guide de migration. Pour ceux qui doivent surveiller l’évolution, il est conseillé de garder un œil sur les discussions au sein de la communauté OTel JS sur le canal Slack CNCF.

Sources