Atlassian stellt Metriken ohne Client-Änderung auf OpenTelemetry um
Victoria Shinder1 Min. LesezeitAtlassian hat beschrieben, wie es seine Metrikplattform umgebaut hat, die Daten von rund 100.000 Hosts in 14 Regionen empfängt, und die gostatsd-basierte Pipeline durch OpenTelemetry ersetzte. Darüber berichtet InfoQ auf Basis eines Beitrags dreier Atlassian-Ingenieure im CNCF-Blog. Für den Dienst galt ein Verfügbarkeitsziel von 99,95 %, der Umbau durfte also keine Metriken stören, auf denen Produktionsalarme beruhen.
Laut den Ingenieuren lief gostatsd jahrelang zuverlässig, konnte mit seinem reinen UDP-Design aber weder Traces noch Logs transportieren, und immer mehr Dienste erzeugten bereits OpenTelemetry-Daten. Statt tausende Dienste zum Wechsel von StatsD-Clients zum OpenTelemetry-SDK zu bewegen, behielt das Team die Schnittstelle StatsD über UDP bei und baute alles dahinter neu. So wurde aus einer unternehmensweiten Migration eine Migration des Plattformteams.
Die neue Pipeline nutzt eigens gebaute Distributionen des OpenTelemetry Collector für vier Stufen: Erfassung, Aufnahme, Aggregation und Weiterleitung. Bei der Erfassung ersetzte die Collector-Distribution, die das Tracing-Team schon betrieb, den gostatsd-Sidecar; Anwendungen senden StatsD-Pakete weiter an dieselbe Adresse, neuere Dienste können OpenTelemetry-Metriken direkt schicken. Die Zusammenlegung mit dem Tracing-Sidecar sparte im Schnitt 3,9 % CPU bei jedem der teuersten Dienste, und das Team schätzt die Einsparung bei den Sidecar-Kosten auf rund 30 % über die gesamte Flotte. Eine OpenTelemetry-Erweiterung für Lambda erhält dieselbe Schnittstelle für Serverless-Workloads.
Was das bedeutet
Übertragbar ist die Reihenfolge: die Schnittstelle, die Clients nutzen, einfrieren und die Technik dahinter stufenweise ersetzen. Die zustandsbehaftete Aggregation, bei der jeder Punkt einer Zeitreihe beim selben Aggregator ankommen muss, nennt der Bericht als schwierigste Stufe, und diesen Teil sollte man vollständig lesen, bevor man das Design übernimmt.