OpenTelemetry : Atlassian migre sa plateforme de métriques sans toucher aux applications

Remplacer le moteur d'une plateforme de métriques, c'est toucher aux données sur lesquelles se déclenchent les alertes de production. Une erreur, et les équipes d'astreinte deviennent aveugles. C'est pourtant le chantier qu'Atlassian, l'éditeur de Jira et Confluence, mène sur sa plateforme de métriques : ses ingénieurs ont reconstruit le pipeline autour d'OpenTelemetry, le standard open source d'observabilité, sans demander aux équipes applicatives de réinstrumenter leurs services. Il ne leur reste qu'une dernière étape avant un pipeline entièrement OpenTelemetry. Le retour d'expérience a été publié le 17 septembre 2026 sur le blog de la CNCF (Cloud Native Computing Foundation, la fondation open source qui héberge OpenTelemetry), puis repris le 29 septembre par InfoQ, média spécialisé en ingénierie logicielle. Au-delà du cas Atlassian, l'annonce dit beaucoup de ce qu'OpenTelemetry peut apporter à une application web plus modeste.

Ce qu'Atlassian a remplacé, et pourquoi

Pendant l'essentiel de la dernière décennie, la plateforme de métriques d'Atlassian a tourné sur gostatsd, une implémentation open source du protocole StatsD que l'entreprise maintient elle-même. Elle collectait les métriques d'environ 100 000 hôtes répartis sur 14 régions, avec un objectif de disponibilité (SLO) de 99,95 %. Un outil qui faisait son travail, sans histoires.

Le problème est venu de l'écosystème. D'après les trois auteurs du retour d'expérience publié sur le blog de la CNCF, de plus en plus de composants émettaient des données au format OpenTelemetry que la plateforme ne savait pas traiter. gostatsd ne parlait qu'en UDP, n'avait aucune réponse pour les traces ni pour les logs, et chaque nouveauté livrée par la communauté du Collector OpenTelemetry devenait une fonctionnalité à reconstruire à la main. Les ingénieurs d'Atlassian résument la situation sans détour : c'est une course qu'ils allaient perdre, la seule question était de savoir quand.

Garder l'interface, tout reconstruire derrière

Le plan évident (arracher l'ancien pipeline, faire réinstrumenter chaque service avec le SDK OpenTelemetry, puis basculer) aurait représenté des années de chantier à l'échelle de toute l'organisation. Atlassian a choisi une voie plus étroite. Pour les équipes produit, le contrat restait le même : on envoie du StatsD en UDP à une adresse donnée, et les métriques apparaissent dans le backend. Tout ce qui se trouve entre ce paquet et le stockage long terme a été reconstruit. « Nous avons gardé l'interface et tout reconstruit derrière, ce qui a transformé une migration à l'échelle de l'organisation en migration de l'équipe plateforme », écrivent les auteurs.

Concrètement, des distributions du Collector OpenTelemetry ont été placées sur quatre étages : collecte, ingestion, agrégation et transfert. L'étage de collecte parle à la fois StatsD et OTLP, le protocole natif d'OpenTelemetry, si bien qu'aucune équipe n'a dû changer de client avant le début de la migration. Pour l'ingestion, la répartition de charge ne se fait plus par service mais par série temporelle (le streamID, via le loadbalancingexporter du dépôt communautaire), ce qui a donné une charge CPU homogène entre les répliques et mis fin aux alertes de « shards chauds » saturés par les plus gros services. Le transfert final alimente plusieurs backends sans intégration sur mesure : ajouter une destination devient une modification de configuration. Même les fonctions serverless, qui ne peuvent pas embarquer de sidecar, ont reçu une extension Lambda OpenTelemetry qui reprend la même adresse StatsD, sans modification de code.

Pour la bascule, les auteurs s'imposent une règle de progressivité : commencer par les environnements de développement et de recette et par les services les moins critiques, puis monter le trafic à 1 %, 10 %, 50 % puis 100 %. L'objectif affiché : trouver les problèmes là où ils coûtent peu, pas sur le chemin le plus critique.

Les chiffres publiés par Atlassian

L'agrégation est l'étage qui rend ces volumes supportables. Il reçoit environ 4,8 milliards de points de données par minute et n'en conserve qu'environ 220 millions, une réduction d'environ 96 % selon les auteurs. Pour y parvenir, Atlassian a écrit son propre processeur d'agrégation des métriques en mode delta, publié en open source sous son organisation atlassian-labs. À trafic égal, cet étage tourne désormais sur environ la moitié du CPU qu'il consommait avant.

Côté hôtes, l'économie vient de la fusion de deux agents. Chaque machine faisait tourner un sidecar StatsD et un sidecar de tracing ; les métriques passent maintenant par le second. Résultat annoncé : environ 3,9 % de CPU en moins en moyenne par service sur les services les plus coûteux d'Atlassian, et environ 30 % de coût de sidecar en moins à l'échelle de la flotte. Reste une dernière étape : les agrégateurs gostatsd et nomad, le proxy maison chargé de répartir le trafic entre eux, représentent encore ensemble environ 38 % des demandes de CPU des clusters de métriques. Leur retrait est, selon les auteurs, la dernière marche avant un pipeline entièrement OpenTelemetry. Ces chiffres sont déclarés par Atlassian et repris par InfoQ dans son compte rendu du 29 septembre 2026.

Ce que ça change pour une application web classique

Une PME n'a ni 100 000 hôtes ni une équipe plateforme dédiée. L'intérêt du cas Atlassian est ailleurs : il montre qu'OpenTelemetry sert de socle commun pour trois signaux (traces, métriques et logs), et qu'on peut l'adopter progressivement. Pour une application web, l'apport tient en une idée : relier ce qui se passe sur le serveur, dans la base de données et chez les services tiers au sein d'une même requête. Quand une page met huit secondes à s'afficher, une trace distribuée montre la durée de chacune des étapes instrumentées de la requête, et les logs émis pendant cette requête peuvent y être rattachés pour en donner le détail.

OpenTelemetry s'appuie sur les logs existants. La documentation officielle d'OpenTelemetry sur les logs précise que le projet est conçu pour fonctionner avec les logs déjà produits : quand un SDK ou une instrumentation automatique est actif, les logs émis pendant une trace active peuvent être corrélés avec la trace et le span en cours grâce aux champs TraceId et SpanId. Autrement dit, les logs gardent leur rôle, et ceux qui sont émis au cours d'une requête tracée y sont directement rattachés. En PHP, l'envoi des logs Monolog vers OpenTelemetry passe par un handler dédié, présenté plus bas.

Côté architecture, le projet recommande en général de faire passer les données par le Collector OpenTelemetry, présenté comme une façon indépendante des éditeurs de recevoir, traiter et exporter la télémétrie ; la même documentation admet qu'en développement ou à petite échelle, un envoi direct sans Collector donne des résultats corrects. Les applications envoient leurs données en OTLP au Collector (port 4317 en gRPC, 4318 en HTTP selon la spécification OTLP), et c'est lui qui les transmet au backend choisi. Changer de backend de supervision ne demande alors pas de modifier le code applicatif : comme chez Atlassian, ajouter une destination devient une modification de configuration. Cette brique s'intègre naturellement à une démarche cloud et DevOps existante.

Côté Symfony et PHP

Pour une application Symfony, la journalisation passe en général par Monolog, que la documentation Symfony présente comme la bibliothèque de logs PHP la plus populaire. La documentation OpenTelemetry pour PHP prévoit justement un handler Monolog (paquet open-telemetry/opentelemetry-logger-monolog) qui envoie ces logs vers un récepteur compatible OpenTelemetry : on conserve Monolog, auquel on ajoute une sortie OpenTelemetry. Pour les traces, deux voies existent sans modifier le code applicatif, d'après la page consacrée à l'instrumentation sans code : l'auto-instrumentation (paquets Composer et extension PECL, sous Linux, macOS ou Windows) et la distribution PHP Distro (paquets deb, rpm ou apk, Linux uniquement, avec des réglages par défaut orientés production). Côté maturité, le SDK PHP est annoncé stable sur les trois signaux.

Côté Node.js et Next.js

En Node.js, le guide officiel de démarrage s'appuie sur le SDK Node et le paquet @opentelemetry/auto-instrumentations-node, qui génère automatiquement des spans pour les bibliothèques courantes ; le fichier d'instrumentation est chargé avant l'application avec l'option --import. Next.js va plus loin : sa documentation officielle recommande OpenTelemetry et indique que le framework est déjà instrumenté nativement (requêtes, rendu des routes, appels fetch). La mise en route passe par le paquet @vercel/otel et un fichier instrumentation.ts, ou par une configuration manuelle avec NodeSDK, non compatible avec le runtime edge. En auto-hébergement, la documentation Next.js indique de monter son propre Collector, tout en précisant qu'un exporteur personnalisé permet de s'en passer.

Maturité : ce qui est stable, ce qui ne l'est pas encore

Tout n'est pas au même niveau selon le langage et le signal. D'après le tableau de statut des SDK consulté le 30 septembre 2026, PHP est stable pour les traces, les métriques et les logs. JavaScript est stable pour les traces et les métriques, mais ses logs restent en statut Development, et la documentation JavaScript qualifie l'instrumentation côté navigateur d'expérimentale. Côté protocole, OTLP est stable pour les trois signaux, le profilage restant en développement. Le Collector lui-même affiche un statut « mixed » : ses composants de base n'ont pas tous le même niveau de stabilité, à vérifier composant par composant.

Le projet ajoute une mise en garde utile : quel que soit le statut d'un SDK, une instrumentation qui s'appuie sur des conventions sémantiques expérimentales (les noms normalisés des attributs) peut subir des changements cassants. Pour une équipe qui construit des tableaux de bord et des alertes sur ces données, c'est un point à vérifier avant de s'y fier en production.

La vraie leçon : une méthode de migration

Au-delà des chiffres, le retour d'Atlassian décrit une méthode transposable à bien des projets. Choisir des premiers utilisateurs qui ont le plus à gagner, en commençant par les environnements de développement et de recette. Profiler en continu en production, parce que le vrai coût d'un composant n'apparaît qu'en charge réelle. Garder les mêmes réflexes d'exploitation pendant la période, souvent longue, où l'ancien et le nouveau système cohabitent. Et monter en charge par paliers.

Cette logique vaut aussi pour une application en maintenance : on peut commencer par instrumenter un seul service ou un seul parcours critique, brancher un Collector, puis étendre. La prochaine étape annoncée par Atlassian va d'ailleurs dans ce sens : faire migrer l'instrumentation elle-même vers le SDK OpenTelemetry, maintenant que la plateforme est prête à la recevoir. Pour une équipe qui hésite sur le périmètre, un audit et une étude de cadrage permettent de choisir le premier service à instrumenter et le backend cible avant d'écrire la moindre configuration.

Pour aller plus loin

• Cloud et DevOps : infrastructure, CI et supervision des applications en production.
• TMA et maintenance applicative : faire évoluer une application existante sans rupture de service.
• Audit et étude de cadrage : prioriser les chantiers techniques avant de les lancer.
• Symfony 8 : la nouvelle version majeure du framework PHP : les évolutions à connaître côté PHP.
• Next.js 16.3 en preview : les nouveautés du framework côté JavaScript.

Sources

• OpenTelemetry everywhere: Migrating a metrics platform at scale (blog de la CNCF, ingénieurs Atlassian, 17 septembre 2026)
• Atlassian Rebuilds Metrics Pipeline Around OpenTelemetry at Massive Scale (InfoQ, 29 septembre 2026)
• OpenTelemetry : statut des SDK par langage (documentation officielle)
• OpenTelemetry : SDK JavaScript (documentation officielle)
• OpenTelemetry : le signal Logs (documentation officielle)
• Spécification OTLP (documentation officielle)
• OpenTelemetry : prise en main Node.js (documentation officielle)
• Next.js : guide OpenTelemetry (documentation officielle)