Wie Atlassian die Zeit zur Erkennung von Vorfällen von über 40 Sekunden auf unter 10 senkte

Atlassian baute die Plattform zur Vorfallerkennung, die sein automatisiertes System zur Erstellung von Vorfällen speist, mit Apache Kafka, Apache Flink auf Kubernetes und OpenTelemetry neu auf. Den veröffentlichten Messungen zufolge sank 18 Monate nach Beginn der Arbeiten die Zeit vom Eintreffen eines Ereignisses bis zu seiner Metrik von über 40 Sekunden auf unter 10 Sekunden. Gleichzeitig stieg die nachhaltige Kapazität bei einer Sampling-Rate von 50 % von etwa 500 Millionen Ereignissen pro Tag auf mehr als eine Milliarde Ereignisse pro Tag.

Das Projekt stellt sich nicht als vollständig abgeschlossene Erfolgsgeschichte dar. Der Recall für Vorfälle innerhalb des Überwachungsumfangs stieg von etwa 60 % auf einen Höchststand von 86 % im Juni 2026, bevor er im August auf 64 % fiel. Auch die Präzision blieb unter dem Zielniveau. Daher trennte das Team die Qualität des Detektors selbst vom Abdeckungsgrad der Produkte und Experimente, die mit Metriken ausgestattet worden waren.

Eine um den Ereignisstrom aufgebaute Plattform

Atlassian betreibt mehr als zehn Cloud-Produkte für Millionen von Mandanten. Diese Produkte erzeugen täglich Milliarden von Ereignissen aus Benutzerinteraktionen. Die Ereignisse enthalten den Beginn und das Ergebnis einer Aufgabe sowie Daten zum Mandanten, Benutzer, Experiment und HTTP-Statuscode. Die Plattform verwendet diese Daten, um schnell drei Fragen zu beantworten: Gibt es ein Problem? Wie groß ist seine Auswirkung? Und welches Team muss mit welchem Schweregrad benachrichtigt werden?

Im neuen Design werden Ereignisse am Apache-Kafka-Bus gefiltert, statt den gesamten Datenstrom innerhalb der Anwendung zu konsumieren. Der etwa 770 Zeilen umfassende Abonnementfilter wird als Teil der Codekonfiguration gespeichert. Anschließend verarbeitet eine einzelne Anwendung auf Basis von Apache Flink 1.20 die Ereignisse auf Kubernetes, reichert sie mit Mandantendaten an, sendet die Metriken über OpenTelemetry und aggregiert die Auswirkungen von Vorfällen in 60-Sekunden-Fenstern.

Das Team verwendete Apache Parquet zur Speicherung der aggregierten Mengen sowie einen regionsübergreifenden Speicher für Schlüsselwerte. Die Impact API liefert Antworten zur Anzahl der betroffenen Benutzer und Mandanten. Die AutoHOT-Engine wandelt Warnungen in Vorfälle um, wendet eine Schweregradmatrix an, unterdrückt kurzzeitige Warnungen und bewertet die Auswirkung jede Minute neu.

Leistungs- und Kostengewinne

• Die Zahl der virtuellen Maschinen sank von etwa 90 Maschinen zuzüglich Warteschlangen- und Caching-Schichten auf vier Kubernetes-Container.
• Die monatlichen Betriebskosten gingen von etwa 20.000 US-Dollar auf rund 650 US-Dollar zurück, was einem Rückgang von ungefähr 97 % entspricht.
• Nach einem Ausfall der Verarbeitung ist eine Wiederherstellung durch die erneute Verarbeitung von Kafka-Ereignissen innerhalb von etwa 20 Minuten ohne Datenverlust möglich.
• Die Abfragezeit des Auswirkungs-Dashboards sank von etwa 10 Sekunden auf ungefähr eine Sekunde.
• Während eines zweiwöchigen Parallelbetriebs erreichte die Übereinstimmung mit dem alten Pfad 99,9 %.

Das Design verwendet HyperLogLog zur Berechnung der Zahl der betroffenen eindeutigen Benutzer, statt Benutzerkennungen zu speichern, mit einem Fehler von etwa 1,5 %. Außerdem wurden idempotente Speicherschlüssel verwendet, damit die erneute Verarbeitung von Kafka ohne eine Verdopplung der Zeilen wiederherstellbar ist. Das Team behielt die alten Metriknamen über einen StatsD-Pfad bei. Dadurch konnten SLO-Dashboards und bestehende Detektoren beim Übergang ohne Änderungen weiterlaufen.

Warum Leistungszahlen allein nicht ausreichen

Die Ergebnisse der Vorfälle zeigen, dass eine Beschleunigung der Datenpipeline nicht zwangsläufig eine bessere Abdeckung bedeutet. Innerhalb von neun Monaten ereigneten sich 263 größere Vorfälle, doch nur 117 davon, also 44,5 %, betrafen mit Monitoring ausgestattete Experimente. Von diesen Vorfällen wurden 80 erkannt. Das bedeutet, dass das System in diesem Zeitraum nur 30,4 % aller größeren Vorfälle erfasste.

Auch die Präzision unterschied sich je nach Warnungstyp. Die Präzision der vom System automatisch erstellten Sev2-Vorfälle lag im Geschäftsjahr bei etwa 85 %, während die Präzision der weniger schwerwiegenden Frühwarnungen zwischen 70 % und 79 % lag. Die Unterdrückung von Schwankungen trug dazu bei, abgelehnte Tickets für kurzzeitige Warnungen um etwa 80 % zu reduzieren. Wenn das Metriksystem verspätet war, wurde ein Datenrückgang dagegen als null interpretiert, was eine Welle von Fehlalarmen auslöste. Dies wurde durch eine Mindestverzögerung von 120 Sekunden bei Detektoren für sinkendes Volumen behoben.

Offene Einschränkungen

Das größte logische Problem besteht darin, dass Schweigen wie ein gesunder Zustand aussehen kann. Ein vollständig ausgefallenes Datenbanksystem kann das Laden der Seite verhindern, wodurch überhaupt keine Fehlerereignisse entstehen. Auch ein Ausfall der Ereignispipeline selbst kann den Detektor blind machen. Daher fügte das Team Detektoren für sinkendes Datenvolumen und Prüfungen der Aktualität der Metriken hinzu und plant, unabhängige Signale wie 5xx-Fehler an der Edge und synthetische Prüfungen einzubeziehen.

Das Team stellte außerdem fest, dass die Erkennung eines Vorfalls und die Messung seiner Auswirkung zwei getrennte Probleme sind. In einem Vorfall wurde das Ticket früh erstellt, doch das System schätzte die Auswirkung auf etwa 2.000 Benutzer, während die tatsächliche Zahl 80.000 überstieg. Zudem brach die Impact API unter der Last von etwa 100 gleichzeitigen Benutzern zusammen, weil sie HyperLogLog-Skizzen zum Lesezeitpunkt ohne Voraggregation oder Caching zusammenführte.

Die wichtigste Schwachstelle bleibt, dass Ereignis-Gateway, Kafka-Abonnement und Flink-Funktion in einer einzigen Region laufen, obwohl die Entscheidungs-Engine in zwei Regionen im Aktiv-Aktiv-Modus arbeitet. Das bedeutet, dass ein regionaler Ausfall die Verarbeitung intakt lassen, aber die Quelle der Erkennung selbst außer Betrieb setzen kann.

Die redaktionelle Einordnung von certi.news

Der zentrale Wert von Atlassians Erfahrung liegt nicht in der isolierten Wahl von Flink oder Kafka, sondern in der Verbindung von Architekturentscheidungen mit überprüfbaren Betriebsmetriken: Filterung am Bus, idempotente Schlüssel, Überwachung der Plattform mit denselben OpenTelemetry-Werkzeugen und die Unterscheidung zwischen Recall und Coverage. Die Ergebnisse zeigen, dass eine Effizienzsteigerung Kosten und Zeit deutlich senken kann, jedoch Lücken bei der Messung oder Vorfälle, die keine nutzerseitigen Signale erzeugen, nicht automatisch behebt.

Atlassian plant, die Detektoren in einen über OpenTelemetry gespeisten Zeitreihenspeicher zu verlagern, die Flink-Pipeline auf einen Aktiv-Aktiv-Modus zwischen den Regionen zu erweitern und eine tägliche Aggregation sowie Caching vor der Impact API hinzuzufügen. Außerdem sollen innerhalb des mit Monitoring ausgestatteten Umfangs sowohl der Recall als auch die Präzision jeweils über 90 % erreichen, bei einer P90-Zeit zur Erkennung von Sev3-Vorfällen von weniger als 90 Minuten. Dies sind weiterhin zukünftige Ziele und laut dem veröffentlichten Material keine bereits erzielten Ergebnisse.