Atlassian a reconstruit sa plateforme de métriques autour d’OpenTelemetry Collector sans demander dans un premier temps aux équipes de services de modifier leur méthode d’envoi des métriques. Au lieu de supprimer l’ancien pipeline puis de reconfigurer des milliers de services, l’entreprise a conservé l’interface StatsD via UDP et remplacé progressivement les couches d’agrégation, de traitement et de routage en arrière-plan.
Durant la majeure partie de la dernière décennie, l’ancienne plateforme reposait sur gostatsd, une application StatsD open source développée par Atlassian, qui fonctionnait comme agent sidecar sur les hôtes et comme couche d’agrégation à l’autre extrémité. La plateforme traitait les métriques provenant d’environ 100 000 hôtes répartis dans 14 régions, selon un objectif de niveau de service de 99,95 % et avec une faible latence.
Changer le moteur tout en conservant le contrat
Les équipes d’Atlassian ont estimé que reconfigurer chaque service pour utiliser l’OpenTelemetry SDK avant de modifier l’infrastructure serait un processus s’étalant sur plusieurs années et comporterait un risque de perte des données dont dépendent les alertes. L’interface de la plateforme a donc été séparée de ses composants internes : les services ont continué à communiquer avec la même adresse et au format StatsD, tandis que les couches internes ont été remplacées par des distributions personnalisées d’OpenTelemetry Collector.
La conception reposait sur quatre étapes indépendantes : collecte, réception, agrégation et routage. La couche de collecte a également été conçue pour recevoir simultanément StatsD et OTLP. Il a ainsi été possible de commencer la migration sans contraindre les équipes à remplacer les bibliothèques clientes, tout en ouvrant la voie aux métriques produites nativement avec OpenTelemetry.
Qu’est-ce qui a changé concrètement ?
Au niveau de la collecte, l’agent sidecar gostatsd a été remplacé par une distribution d’OpenTelemetry Collector déjà utilisée par l’équipe chargée du tracing, tout en conservant le comportement antérieur des applications. Cela a permis de regrouper les métriques et le tracing dans un seul agent sidecar au lieu d’exécuter deux agents sur chaque hôte.
Atlassian affirme que cette consolidation a réduit la consommation de CPU de près de 3,9 % en moyenne par service parmi les services Micros les plus coûteux, ce qui équivaut à une réduction d’environ 30 % du coût des agents sidecar à l’échelle du parc. Un récepteur OTLP a également été ajouté afin que la couche de collecte puisse recevoir les métriques OpenTelemetry et les réacheminer directement.
Au niveau de la réception, le principal problème concernait l’état des séries temporelles. Chaque point de données appartenant à une même série devait être envoyé à un seul agrégateur. L’ancien système, par l’intermédiaire d’un agent interne appelé nomad, utilisait un partitionnement fondé sur le couple service-environnement. Toutefois, les différences de taille entre les services entraînaient l’apparition d’agrégateurs surchargés et d’autres peu utilisés.
Atlassian a résolu ce problème en utilisant le composant loadbalancingexporter du dépôt OpenTelemetry, avec un partitionnement selon le streamID, c’est-à-dire l’identité de chaque série temporelle. Cette méthode a permis de répartir les données des services volumineux entre plusieurs agrégateurs, tout en maintenant une même série sur le même agrégateur. La répartition du CPU entre les agrégateurs est ainsi devenue plus équilibrée, la capacité de mise à l’échelle automatique s’est améliorée et les alertes de charge élevée ont diminué.
Réduire les données et les coûts au niveau de l’agrégation
La couche d’agrégation traite environ 4,8 milliards de points de données par minute, mais n’en stocke qu’environ 220 millions, soit une réduction proche de 96 %. Comme la plupart des métriques utilisent la delta temporality et que les composants précédents n’agrégeaient pas ces deltas de la manière attendue par les utilisateurs, Atlassian a développé un processeur personnalisé pour agréger les deltas des métriques et l’a publié en open source sous l’espace de noms atlassian-labs.
Après la migration, la couche d’agrégation n’avait plus besoin que d’environ la moitié du CPU utilisé auparavant. La source attribue cette amélioration à plusieurs facteurs, notamment la suppression de l’analyse du format gostatsd, une meilleure répartition de la charge et l’exploitation des améliorations apportées par la communauté OpenTelemetry.
Lors de la dernière étape, un routeur interne personnalisé a été remplacé par une distribution sans état de Collector baptisée metrics-gateway par l’entreprise. Cette distribution s’appuie sur les exportateurs upstream pour prendre en charge l’envoi vers plusieurs destinations telles que SignalFx et S3, avec des fonctionnalités de nouvelle tentative, de files d’attente et de contrôle de la contre-pression. Selon la conception annoncée, l’ajout d’une nouvelle destination devient une modification de configuration plutôt qu’un projet d’intégration indépendant.
Leçons d’une migration progressive
- Commencer par les bonnes équipes : Atlassian a sélectionné les environnements de développement et de test ainsi que les services qui rencontraient le plus de problèmes, afin d’obtenir rapidement des retours dans un périmètre moins sensible.
- Surveiller continuellement la production : le profiling réalisé sous des charges de production a révélé le comportement et le coût des composants d’une manière que n’avaient pas permis les petits tests ou les benchmarks synthétiques.
- Conserver une exploitation similaire : comme la migration peut durer des mois ou des années avec les deux systèmes exécutés en parallèle, l’entreprise a recommandé de conserver autant que possible les outils et les procédures opérationnelles communs.
- Élargir le périmètre par étapes : le déploiement a suivi des pourcentages progressifs, en commençant par 1 %, puis 10 % et 50 %, jusqu’à 100 %, les problèmes étant testés sur les services les moins sensibles avant les parcours critiques.
Pourquoi cette approche est-elle importante ?
Cette expérience montre que l’adoption d’un nouveau standard d’infrastructure ne nécessite pas forcément de modifier simultanément les interfaces de tous les consommateurs. La conservation du contrat externe a transformé la migration : au lieu d’être un projet organisationnel impliquant toutes les équipes, elle est devenue un projet piloté par la plateforme d’infrastructure, tout en ouvrant progressivement la voie à OTLP et aux composants OpenTelemetry.
Atlassian indique que gostatsd et nomad représentaient ensemble environ 38 % des requêtes CPU dans les clusters de métriques, tandis que nomad représentait à lui seul environ 13 % des ressources totales. L’impact de la transition ne se limite donc pas à l’unification des outils ; il est également lié à la suppression de composants personnalisés coûteux et à la réduction du nombre d’éléments nécessitant une maintenance interne.
Cela ne signifie toutefois pas que la migration de l’instrumentation des services est terminée. La prochaine étape mentionnée par l’entreprise consiste à transférer les outils d’instrumentation eux-mêmes vers l’OpenTelemetry SDK et à abandonner progressivement les clients Datadog et DogStatsD ainsi que les bibliothèques StatsD internes encore utilisées. Les résultats de performance et les chiffres présentés ici restent par ailleurs une description de l’expérience d’Atlassian dans son environnement et ne garantissent pas que les mêmes valeurs se reproduiront dans toutes les architectures de supervision.