Atlassian stellt 100.000 Hosts auf OpenTelemetry um
Atlassian stellt seine Metrik-Pipeline auf OpenTelemetry um, ohne dass Dienste ihren Code ändern. Die Aggregation braucht nur noch halb so viel CPU.
Atlassian stellt die Metrik-Pipeline für rund 100.000 Hosts von gostatsd auf den OpenTelemetry Collector um, ohne dass ein Dienst seine Schnittstelle ändern muss. Die neue Aggregationsstufe kommt bei gleichem Traffic mit etwa der Hälfte der CPU aus. Die alten gostatsd-Aggregatoren und der Proxy nomad laufen vorerst weiter.
Das Wichtigste in Kürze
- Die StatsD-Schnittstelle bleibt bestehen, dahinter arbeitet der OpenTelemetry Collector. Die Dienste senden über UDP an die gewohnte Adresse, die neue Collector-Distribution nimmt parallel OTLP an.
- Ein neuer Shard-Schlüssel verteilt große Dienste gleichmäßig über den Pool. Der Schlüssel streamID im Loadbalancingexporter hält dabei jede Zeitreihe auf demselben Shard.
- Die Aggregation verdichtet rund 4,8 Milliarden Datenpunkte je Minute auf rund 220 Millionen. Bei gleichem Traffic kommt die Stufe mit etwa der Hälfte der CPU aus.
Grenzen der bisherigen Pipeline
Die Metrik-Pipeline von Atlassian sammelt Telemetrie von rund 100.000 Hosts in 14 Regionen ein. Bislang lief sie über gostatsd, eine vom Unternehmen gepflegte Open-Source-Implementierung des StatsD-Protokolls.
Die Pipeline arbeitete mit einem SLO von 99,95 Prozent, einem internen Service-Level-Ziel. Zudem nahm gostatsd Metriken ausschließlich über UDP an und hatte keine Lösung für Traces oder Logs. Jede Neuerung der OpenTelemetry-Community hätte das Team von Hand nachbauen müssen.
Was ist der OpenTelemetry Collector? Der OpenTelemetry Collector ist eine modular aufgebaute Software zum Empfangen, Verarbeiten und Weiterleiten von Telemetriedaten. Er nimmt Protokolle wie OTLP oder StatsD an und exportiert zu Backends wie SignalFx oder S3. Wiederholungen, Warteschlangen und Drosselung gehören zum Standardumfang, viele Komponenten entwickelt die OpenTelemetry-Community gemeinsam.
Umbau in vier Stufen
Atlassian setzte an jeder der vier Stufen Sammlung, Ingest, Aggregation und Weitergabe eine eigene Collector-Distribution ein und konnte so jede Stufe einzeln umbauen. An der Schnittstelle zu den Anwendungen änderte sich nichts. Die Dienste senden weiterhin StatsD-Metriken über UDP an dieselbe Adresse, während die neue Collector-Distribution parallel OTLP annimmt, das native Protokoll von OpenTelemetry.
Schon das Zusammenlegen von StatsD- und Tracing-Sidecar, den Hilfsprozessen auf jedem Host, brachte Einsparungen. Bei den teuersten Diensten sparte es im Durchschnitt etwa 3,9 Prozent CPU je Dienst, im Flottenmaßstab sanken die Sidecar-Kosten um rund 30 Prozent.
Gleichmäßige Lastverteilung
Ein Aggregator muss alle Datenpunkte einer Zeitreihe sehen, um sie zu verdichten. Der bisherige Eigenbau-Proxy namens nomad sicherte das, indem er das Paar aus Dienst und Umgebung auf einen Shard hashte, also auf einen festen Teil des Aggregator-Pools. Weil sich die Metrik-Last auf wenige große Dienste konzentriert, gerieten deren Shards unter Dauerlast.
Im neuen Aufbau übernimmt der Loadbalancingexporter des OpenTelemetry Collector diese Aufgabe. Mit dem Routing-Schlüssel streamID, einem Hash über alle Merkmale einer Zeitreihe, verteilt er einen großen Dienst gleichmäßig über den Pool, während jede Zeitreihe auf demselben Shard bleibt. Die CPU-Last je Shard ging von einzelnen hohen Ausschlägen und untätigen Replikaten zu einer flachen Verteilung über. Seitdem lässt sich der Pool außerhalb der Spitzenzeiten verkleinern.
Aggregation mit halbem Aufwand
Die Aggregationsstufe nimmt rund 4,8 Milliarden Datenpunkte je Minute an und gibt nach der Verdichtung rund 220 Millionen weiter. Die meisten Metriken bei Atlassian liegen als Deltas vor, also als Veränderung seit der letzten Meldung. Keine vorhandene Komponente fasste solche Deltas so zusammen, wie die Nutzer es erwarten.
Atlassian schrieb deshalb den Atlassian Aggregation Processor und stellte ihn als Open Source bereit. Er baut auf einer Standardkomponente der OpenTelemetry-Community auf, fasst Delta-Werte im Standard alle 60 Sekunden zusammen und gibt andere Metriktypen unverändert weiter.
Bei gleichem Traffic kommt die neue Aggregationsstufe mit etwa der Hälfte der CPU aus. Die Aggregatoren müssen das gostatsd-Format nicht mehr parsen, die Last liegt gleichmäßiger und das Team übernimmt Optimierungen der Community.
Weitergabe und nächster Schritt
Die Weitergabe übernahm bisher ein selbstgebauter interner Forwarder. Heute läuft sie als zustandslose Collector-Distribution namens metrics-gateway, die die Daten an SignalFx, S3 und weitere Backends verteilt. Wiederholungen, Warteschlangen und Drosselung bei Überlast bringt der Collector ab Werk mit.
Für Serverless-Funktionen, auf denen kein Sidecar laufen kann, ersetzt eine selbstgebaute OTel-Lambda-Erweiterung die gostatsd-Erweiterung. Sie behält die StatsD-Adresse und die Umgebungsvariablen bei, Codeänderungen entfallen.
Die alten gostatsd-Aggregatoren und nomad laufen vorerst weiter. Zusammen machen sie noch rund 38 Prozent der CPU-Requests in den Metrik-Clustern aus, nomad allein rund 13 Prozent der Gesamtressourcen. Nach ihrem Abbau läuft die Pipeline durchgehend auf OpenTelemetry.
Iris Grace Endozo, Farzad Vazirnia und Albert Kerr von Atlassian sehen als nächsten Schritt, die Instrumentierung auf das OpenTelemetry-SDK zu verlagern. Bisher sind die Dienste über Client-Bibliotheken von Anbietern und aus eigener Entwicklung instrumentiert, also mit Messpunkten im Code versehen, darunter DogStatsD von Datadog und StatsD-Bibliotheken.
Häufige Fragen
Was ist gostatsd bei Atlassian?
gostatsd ist eine von Atlassian gepflegte Open-Source-Implementierung des StatsD-Protokolls. Sie nimmt Metriken ausschließlich über UDP an und deckt Traces und Logs nicht ab. Die gostatsd-Aggregatoren binden zusammen mit dem Eigenbau-Proxy nomad noch rund 38 Prozent der CPU-Requests in den Metrik-Clustern.
Warum war der Shard-Schlüssel ein Problem?
Der frühere Proxy hashte das Paar aus Dienst und Umgebung auf einen Shard. Weil sich die Last auf wenige große Dienste konzentriert, gerieten genau deren Shards unter Dauerlast. Der Schlüssel streamID verteilt einen Dienst gleichmäßig über den Pool und hält jede Zeitreihe auf demselben Shard.
Was ändert sich für Dienstteams?
Im laufenden Betrieb ändert sich nichts, die Dienste senden weiter StatsD über UDP an dieselbe Adresse. Für Serverless-Funktionen übernimmt eine Lambda-Erweiterung mit gleicher Adresse und gleichen Umgebungsvariablen diese Rolle. Als nächsten Schritt will Atlassian die Instrumentierung auf das OpenTelemetry-SDK verlagern.
Lesetipps der Redaktion
cloudmagazinOpenTelemetry: einmal instrumentieren, das Backend frei wählencloudmagazinHohe Kubernetes-Requests bezahlen leere KnotencloudmagazinAWS lässt bei Störungen einen KI-Agenten mitsuchenBildquelle: KI-generiert (September 2026)
