Atlassian ist der Ansicht, dass die Ursachenanalyse von Vorfällen in Microservices-Umgebungen nicht mehr allein auf manueller Prüfung beruhen kann. Wenn Hunderte miteinander verbundene Services über mehrere Regionen hinweg arbeiten, erzeugt ein einzelner Ausfall eine große Menge an Metriken, Protokollen und Tracing-Spuren, während der diensthabende Ingenieur gewöhnlich zwischen separaten Dashboards wechseln und sich eine mentale Hypothese über die Quelle des Problems und seinen Ausbreitungspfad bilden muss.
In einem Beitrag im CNCF-Blog erläutern Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee und Lavender Neesham von Atlassian ein automatisiertes System zur Ursachenanalyse, das die Generierung von Hypothesen automatisieren soll. Dadurch soll das Reaktionsteam schneller zur Überprüfung und Behebung übergehen können, statt die Belege manuell erneut zusammenzutragen.
Die Ursachenanalyse in eine Aufgabe zur Verknüpfung mehrerer Signale umwandeln
Das Design basiert auf der Verknüpfung von drei Beweisebenen: Signaltyp, Zeit und Servicetopologie. Zu den Signalen gehören Metriken, Protokolle und Tracing-Spuren. Die zeitliche Synchronität bestimmt, welche Ereignisse miteinander verbunden sein könnten, während der Graph der Service-Abhängigkeiten dabei hilft, zwischen dem Service, bei dem die Störung begonnen hat, und jenem zu unterscheiden, der später betroffen war.
Der Prozess beginnt mit der Eingrenzung des Suchbereichs durch eine aus OpenTelemetry abgeleitete Servicekarte. Anstatt alle Services der Plattform zu analysieren, identifiziert das System die Services, die im Pfad des beeinträchtigten Nutzererlebnisses liegen, und bildet einen Bereich, der gewöhnlich Dutzende statt Hunderte von Services umfasst. Die Karte spiegelt die tatsächlichen Verbindungen wider, die aus Eltern-Kind-Beziehungen zwischen Zeitspannen im Produktionsverkehr abgeleitet werden, und nicht die in der Dokumentation angenommene Struktur.
Von Monitoringdaten zu priorisierten Hypothesen
Nach der Festlegung des Bereichs arbeiten unabhängige Module daran, Anomalien in den einzelnen Signaltypen zu erkennen. Bei den Metriken überwacht Atlassian RED-Indikatoren – Anfragerate, Fehlerrate und Antwortdauer – mithilfe statistischer Verfahren wie der medianen absoluten Abweichung und Perzentilbereichen. Jeder Anomaliefall liefert einen Schweregrad, den beobachteten Wert und die Baseline, von der er abgewichen ist.
Verteilte Tracing-Spuren werden auf unerwartete Ausnahmen, neue Muster der Fehlerausbreitung und Anstiege der Antwortzeit bei bestimmten Spans untersucht. Für Protokolle werden embeddingsbasierte Clustering-Techniken eingesetzt, um semantisch ähnliche Einträge zu gruppieren und anschließend neue oder seltene Fehlergruppen im Vergleich zur üblichen Verteilung des jeweiligen Services hervorzuheben.
Alle Detektoren wandeln ihre Ergebnisse in Ereignisse mit einem einheitlichen Schema um, das Zeitstempel, Servicename, Signaltyp, Schweregrad und Details umfasst. Diese Ebene ermöglicht es der Verknüpfungs-Engine, Ereignisse unabhängig davon zu analysieren, wie der jeweilige Detektor den Zustand erkannt hat. Außerdem können neue Detektoren hinzugefügt oder ein statistisches Modell durch ein maschinelles Lernmodell ersetzt werden, ohne das gesamte System neu aufbauen zu müssen.
Zeit und Abhängigkeitsgraph zur Bestimmung der Fehlerausrichtung
Die Engine gruppiert zeitlich nahe Ereignisse innerhalb eines konfigurierbaren Zeitfensters, das gewöhnlich plus oder minus fünf Minuten beträgt. Jede Gruppe erhält einen Wert für zeitliche Kohärenz: Je näher die Ereignisse beieinanderliegen, desto höher ist die Wahrscheinlichkeit, dass sie zusammenhängen. Um zu verhindern, dass dieselbe Hypothese Dutzende Male wiederholt wird, verwendet das System Signaturen für Service-Sequenzen und fasst wiederkehrende Fehlerketten in einer Gruppe zusammen, einschließlich der Anzahl der Wiederholungen. So kann ein Fehlermuster, das innerhalb von fünf Minuten 47-mal auftrat, als ein Muster beschrieben werden, statt 47 identische Hypothesen zu erzeugen.
Anschließend bestimmt das System den am stärksten betroffenen Knoten, den es als Downstream-Knoten bezeichnet, und bewegt sich im Abhängigkeitsgraph rückwärts, um nach anomaliebehafteten Services zu suchen, die zeitlich davor auffällig waren. Wenn Service B von Service A aufgerufen wird und das Problem bei B vor dem Problem bei A auftrat, wird B zu einem stärkeren Kandidaten als Fehlerquelle, während das Problem bei A als nachgelagerte Auswirkung behandelt wird. Die endgültige Bewertung kombiniert zeitliche Kohärenz und den Wert des Ausbreitungspfads, um die Hypothesen zu priorisieren.
Das Ergebnis beschränkt sich nicht auf eine Liste von Services und Vertrauenswerten. Jede Hypothese enthält den verdächtigen Service, den Ausbreitungspfad und die Belege an jedem Knoten, etwa Metriken, die ihre Grenzwerte überschritten haben, oder mit dem Fehler verbundene Tracing-IDs. Hinzu kommt eine in menschlicher Sprache formulierte Darstellung, die die Abfolge der Ereignisse erklärt und begründet, warum eine bestimmte Quelle bevorzugt wird.
Warum diese Methodik für Betriebsteams wichtig ist
Der praktische Wert liegt hier nicht darin, den Reaktionsingenieur zu ersetzen, sondern die Zeit bis zum Erreichen einer überprüfbaren Hypothese zu verkürzen. Atlassian verbindet die Engine zur Ursachenanalyse mit einer umfassenderen Plattform zur Vorfallreaktion. Diese umfasst die Ermittlung der Auswirkungen des Ausfalls auf Nutzer, die Bestimmung des verantwortlichen Teams und einen Vorfallassistenten, der auf Grundlage der verfügbaren Belege Maßnahmen wie ein Rollback einer Version oder die Deaktivierung eines Feature-Flags vorschlagen kann. Außerdem erfasst die Plattform, ob Ingenieure eine Hypothese akzeptiert, abgelehnt oder verändert haben, um die Gewichtungen im Laufe der Zeit zu verbessern.
Die Erfahrung zeigt, dass der Beginn mit einfachen, interpretierbaren Verfahren geeigneter sein kann als der Aufbau komplexer Modelle des maschinellen Lernens für jedes Signal. Verfahren wie die mediane absolute Abweichung und Perzentilbereiche reichten aus, um viele Metrikanomalien zu erkennen. Methoden des maschinellen Lernens wurden dagegen beim Clustering von Protokollen und bei der Analyse der Struktur von Tracing-Spuren eingesetzt, wo statistische Verfahren weniger geeignet sind.
Die Methodik beseitigt jedoch nicht alle Einschränkungen. Die Qualität der Hypothesen hängt von der Konsistenz der Monitoringdaten, der Genauigkeit des Graphen der Service-Abhängigkeiten und der Fähigkeit der Detektoren ab, zwischen echten Störungen und Rauschen zu unterscheiden. Außerdem ist ein Vertrauenswert kein endgültiger Beweis für Kausalität. Daher betont Atlassian, wie wichtig es ist, die Quelle jedes Belegs und die Darstellung, die ihn mit dem Ergebnis verknüpft, offenzulegen. Das Unternehmen untersucht später den Einsatz eines auf Sprachmodellen basierenden Formats, das zusätzliche Daten anfordern und Hypothesen anpassen kann, wobei Ratenbegrenzungen, isolierte Ausführung und ein klares Protokoll der Belegquellen vorgeschrieben werden.
Redaktionelle Einschätzung von certi.news: Die tatsächliche Veränderung dieses Ansatzes besteht darin, die Vorfallanalyse von einem manuellen Vergleich zwischen separaten Tools in einen einheitlichen Prozess zu überführen, der Signal, Zeit und Topologie miteinander verbindet. Sein betrieblicher Erfolg wird jedoch von Interpretierbarkeit, Datenqualität und Feedbackschleifen abhängen, nicht allein vom Priorisierungsalgorithmus. Daher erscheinen Modularität, die Beseitigung von Redundanz und die Dokumentation der Belege unmittelbar anwendbarer als das Versprechen einer vollständigen Automatisierung der Ursachenanalyse.