Atlassian migre 100 000 hôtes vers OpenTelemetry

Atlassian migre le pipeline de métriques d’environ 100 000 hôtes de gostatsd vers l’OpenTelemetry Collector, sans qu’aucun service n’ait à modifier son interface. La nouvelle étape d’agrégation se contente d’environ la moitié du CPU pour le même trafic. Les anciens agrégateurs gostatsd et le proxy nomad continuent de tourner pour l’instant.

L’essentiel en bref

Les limites du pipeline existant

Le pipeline de métriques d’Atlassian collecte la télémétrie d’environ 100 000 hôtes dans 14 régions. Jusqu’ici, il fonctionnait avec gostatsd, une implémentation open source du protocole StatsD maintenue par l’entreprise.

Le pipeline fonctionnait avec un SLO de 99,95 %, un objectif interne de niveau de service. De plus, gostatsd n’acceptait les métriques que par UDP et ne proposait aucune solution pour les traces ni les logs. Chaque nouveauté de la communauté OpenTelemetry aurait dû être recréée à la main par l’équipe.

Qu’est-ce que l’OpenTelemetry Collector ? L’OpenTelemetry Collector est un logiciel modulaire conçu pour recevoir, traiter et acheminer les données de télémétrie. Il accepte des protocoles comme OTLP ou StatsD et exporte vers des backends comme SignalFx ou S3. Nouvelles tentatives, files d’attente et limitation de débit font partie des fonctionnalités livrées en standard, et de nombreux composants sont développés en commun par la communauté OpenTelemetry.

Une refonte en quatre étapes

Atlassian a déployé une distribution du Collector propre à chacune des quatre étapes, collecte, ingestion, agrégation et acheminement, et a ainsi pu refondre chaque étape séparément. Rien n’a changé du côté de l’interface avec les applications. Les services continuent d’envoyer leurs métriques StatsD par UDP à la même adresse, tandis que la nouvelle distribution du Collector accepte en parallèle OTLP, le protocole natif d’OpenTelemetry.

La simple fusion du sidecar StatsD et du sidecar de tracing, ces processus auxiliaires présents sur chaque hôte, a déjà permis des économies. Pour les services les plus coûteux, elle a permis d’économiser en moyenne environ 3,9 % de CPU par service, et à l’échelle du parc, les coûts des sidecars ont baissé d’environ 30 %.

Une répartition uniforme de la charge

Un agrégateur doit voir tous les points de données d’une série temporelle pour les condenser. L’ancien proxy maison nommé nomad le garantissait en affectant par hachage la paire service-environnement à un shard, c’est-à-dire une part fixe du pool d’agrégateurs. Comme la charge de métriques se concentre sur quelques grands services, leurs shards se retrouvaient sous une charge permanente.

Dans la nouvelle architecture, le loadbalancing exporter de l’OpenTelemetry Collector assure cette tâche. Avec la clé de routage streamID, un hachage de toutes les caractéristiques d’une série temporelle, il répartit un grand service uniformément sur le pool, chaque série temporelle restant sur le même shard. La charge CPU par shard est passée de pics isolés et de réplicas inactifs à une répartition uniforme. Depuis, le pool peut être réduit en dehors des heures de pointe.

Une agrégation à la moitié de l’effort

L’étape d’agrégation reçoit environ 4,8 milliards de points de données par minute et en transmet environ 220 millions après condensation. Chez Atlassian, la plupart des métriques se présentent sous forme de deltas, c’est-à-dire de variations depuis la dernière remontée. Aucun composant existant ne totalisait ces deltas comme les utilisateurs s’y attendent.

Atlassian a donc écrit l’Atlassian Aggregation Processor et l’a publié en open source. Il s’appuie sur un composant standard de la communauté OpenTelemetry, totalise les valeurs delta toutes les 60 secondes par défaut et transmet les autres types de métriques inchangés.

Pour le même trafic, la nouvelle étape d’agrégation se contente d’environ la moitié du CPU. Les agrégateurs n’ont plus à parser le format gostatsd, la charge est mieux répartie et l’équipe adopte les optimisations de la communauté.

Acheminement et prochaine étape

Jusqu’ici, un forwarder développé en interne assurait l’acheminement. Il fonctionne désormais sous la forme d’une distribution du Collector sans état nommée metrics-gateway, qui distribue les données vers SignalFx, S3 et d’autres backends. Nouvelles tentatives, files d’attente et limitation en cas de surcharge sont fournies d’office par le Collector.

Pour les fonctions serverless, où aucun sidecar ne peut tourner, une extension OTel pour Lambda développée en interne remplace l’extension gostatsd. Elle conserve l’adresse StatsD et les variables d’environnement, aucune modification de code n’est nécessaire.

Les anciens agrégateurs gostatsd et nomad continuent de tourner pour l’instant. À eux deux, ils représentent encore environ 38 % des requêtes CPU dans les clusters de métriques, nomad à lui seul environ 13 % des ressources totales. Une fois ceux-ci démantelés, le pipeline fonctionnera intégralement sur OpenTelemetry.

Iris Grace Endozo, Farzad Vazirnia et Albert Kerr, d’Atlassian, voient l’étape suivante dans le déplacement de l’instrumentation vers le SDK OpenTelemetry. Jusqu’ici, les services sont instrumentés via des bibliothèques clientes fournies par des éditeurs ou développées en interne, c’est-à-dire dotés de points de mesure dans le code, notamment DogStatsD de Datadog et des bibliothèques StatsD.

Questions fréquentes

Source de l’image : générée par IA (septembre 2026)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.