Wie Atlassian seine Metrikplattform in großem Maßstab auf OpenTelemetry umstellte

Atlassian baute seine Metrikplattform um den OpenTelemetry Collector neu auf, ohne die Serviceteams zunächst dazu aufzufordern, ihre Methode zum Senden von Metriken zu ändern. Statt die alte Pipeline zu entfernen und anschließend Tausende von Diensten neu zu konfigurieren, behielt das Unternehmen die StatsD-Schnittstelle über UDP bei und ersetzte die Aggregations-, Verarbeitungs- und Routing-Schichten dahinter schrittweise.

Die frühere Plattform stützte sich während des größten Teils des vergangenen Jahrzehnts auf gostatsd, eine von Atlassian entwickelte Open-Source-StatsD-Anwendung, die sowohl als Sidecar auf den Hosts als auch als Aggregationsschicht am anderen Ende betrieben wurde. Die Plattform verarbeitete Metriken von etwa 100.000 Hosts in 14 Regionen, entsprechend einem Service-Level-Ziel von 99,95 % und niedriger Latenz.

Die Engine ändern und den Vertrag beibehalten

Die Teams von Atlassian waren der Ansicht, dass die erneute Konfiguration jedes Dienstes zur Nutzung des OpenTelemetry SDK vor einer Änderung der Infrastruktur ein mehrjähriger Prozess wäre und das Risiko des Verlusts von Daten bergen würde, von denen Warnungen abhängen. Daher wurde die Schnittstelle der Plattform von ihren internen Komponenten getrennt: Die Dienste kommunizierten weiterhin mit derselben Adresse und im StatsD-Format, während die internen Schichten durch angepasste Distributionen des OpenTelemetry Collectors ersetzt wurden.

Das Design umfasste vier unabhängige Phasen: Sammlung, Empfang, Aggregation und Routing. Außerdem wurde die Sammlungsschicht in die Lage versetzt, StatsD und OTLP gleichzeitig zu empfangen. Dadurch konnte die Migration beginnen, ohne die Teams zum Wechsel ihrer Client-Bibliotheken zu zwingen, und zugleich der Weg für Metriken geöffnet werden, die ursprünglich mit OpenTelemetry erstellt wurden.

Was änderte sich in der Praxis?

In der Sammelphase wurde der gostatsd-Sidecar durch eine OpenTelemetry-Collector-Distribution ersetzt, die zuvor vom Tracing-Team verwendet worden war, während die Anwendungen ihr bisheriges Verhalten beibehielten. Dadurch konnten Metriken und Tracing in einem einzigen Sidecar zusammengeführt werden, anstatt auf jedem Host zwei Agents zu betreiben.

Atlassian zufolge senkte diese Zusammenführung den CPU-Verbrauch bei den kostenintensivsten Micros-Diensten im Durchschnitt um etwa 3,9 % pro Dienst. Dies entspricht einer Verringerung der Kosten für Sidecar-Agents im gesamten Bestand um ungefähr 30 %. Außerdem wurde ein OTLP-Receiver hinzugefügt, sodass die Sammelschicht OpenTelemetry-Metriken empfangen und direkt weiterleiten kann.

In der Empfangsphase hing das zentrale Problem mit dem Zustand der Zeitreihen zusammen. Jeder Datenpunkt einer bestimmten Zeitreihe musste an denselben Aggregator gesendet werden. Das alte System verwendete über einen internen Agenten namens nomad eine Partitionierung anhand des Dienst- und Umgebungspaars. Die unterschiedlichen Dienstgrößen führten jedoch dazu, dass einige Aggregatoren stark ausgelastet und andere nur wenig genutzt wurden.

Atlassian begegnete diesem Problem mit der Komponente loadbalancingexporter aus dem OpenTelemetry-Repository und einer Partitionierung nach streamID, also der Identität der einzelnen Zeitreihe. Dadurch konnten die Daten großer Dienste auf eine Gruppe von Aggregatoren verteilt werden, während eine einzelne Zeitreihe auf demselben Aggregator blieb. Infolgedessen wurde die CPU-Verteilung zwischen den Aggregatoren gleichmäßiger, die Fähigkeit zur automatischen Skalierung verbesserte sich und Warnungen wegen hoher Auslastung gingen zurück.

Daten- und Kostensenkung in der Aggregationsschicht

Die Aggregationsschicht verarbeitet etwa 4,8 Milliarden Datenpunkte pro Minute, speichert jedoch nur ungefähr 220 Millionen Punkte, was einer Reduzierung von etwa 96 % entspricht. Da die meisten Metriken Delta-Temporality verwenden und die früheren Komponenten diese Differenzen nicht auf die von den Benutzern erwartete Weise aggregierten, entwickelte Atlassian einen eigenen Prozessor zur Aggregation von Metrik-Deltas und veröffentlichte ihn unter dem Bereich atlassian-labs als Open Source.

Nach der Umstellung benötigt die Aggregationsschicht ungefähr halb so viel CPU wie zuvor. Die Quelle führt diese Verbesserung auf mehrere Faktoren zurück, darunter den Wegfall der Analyse des gostatsd-Formats, eine bessere Lastverteilung und Verbesserungen aus der OpenTelemetry-Community.

In der letzten Phase wurde ein eigens entwickelter interner Router durch eine zustandslose Collector-Distribution ersetzt, die das Unternehmen metrics-gateway nannte. Diese Distribution nutzt Upstream-Exporter, um die Übertragung an mehrere Ziele wie SignalFx und S3 zu unterstützen, einschließlich Wiederholungsversuchen, Warteschlangen und Rückdrucksteuerung. Nach dem veröffentlichten Design wird das Hinzufügen eines neuen Ziels zu einer Konfigurationsänderung statt zu einem eigenständigen Integrationsprojekt.

Lehren aus der schrittweisen Migration

• Mit den richtigen Teams beginnen: Atlassian wählte Entwicklungs- und Testumgebungen sowie Dienste aus, die besonders stark von den Problemen betroffen waren, um in einem weniger sensiblen Bereich frühzeitig Feedback zu erhalten.
• Die Produktion kontinuierlich beobachten: Profiling unter Produktionslast zeigte das Verhalten und die Kosten der Komponenten auf eine Weise, die kleine Tests oder synthetische Benchmarks nicht sichtbar machten.
• Den Betriebsmodus vereinheitlicht halten: Da die Migration bei Parallelbetrieb beider Systeme Monate oder Jahre dauern kann, empfahl das Unternehmen, gemeinsame Tools und Betriebsverfahren so weit wie möglich beizubehalten.
• Den Umfang schrittweise erweitern: Die Bereitstellung erfolgte in abgestuften Anteilen, beginnend mit 1 %, anschließend 10 % und 50 % bis hin zu 100 %. Probleme wurden zunächst in weniger sensiblen Diensten getestet, bevor kritische Pfade einbezogen wurden.

Warum ist dieser Ansatz wichtig?

Die Erfahrung zeigt, dass die Einführung eines neuen Standards in der Infrastruktur nicht zwangsläufig eine gleichzeitige Änderung der Schnittstellen aller Verbraucher erfordert. Durch die Beibehaltung des externen Vertrags wurde die Migration von einem organisatorischen Projekt für alle Teams zu einem von der Infrastrukturplattform geleiteten Projekt, während gleichzeitig schrittweise Raum für OTLP und OpenTelemetry-Komponenten geschaffen wurde.

Atlassian zufolge machten gostatsd und nomad zusammen etwa 38 % der CPU-Anforderungen in den Metrik-Clustern aus, während nomad allein ungefähr 13 % der gesamten Ressourcen beanspruchte. Die Auswirkungen der Umstellung beschränken sich daher nicht auf die Vereinheitlichung der Tools; sie stehen auch mit der Entfernung kostenintensiver eigener Komponenten und der Verringerung der Anzahl intern zu wartender Teile in Verbindung.

Das bedeutet jedoch nicht, dass die Migration der Instrumentierung der Dienste abgeschlossen ist. Der nächste von dem Unternehmen genannte Schritt besteht darin, auch die Instrumentierungs-Tools selbst auf das OpenTelemetry SDK umzustellen und Datadog- und DogStatsD-Clients sowie interne StatsD-Bibliotheken, die weiterhin verwendet werden, schrittweise aufzugeben. Die hier genannten Leistungsresultate und Zahlen beschreiben außerdem Atlassians Erfahrung mit seiner eigenen Umgebung und sind keine Garantie dafür, dass sich dieselben Werte in jeder Monitoring-Infrastruktur wiederholen.