So funktioniert die Root-Cause-Analyse mit ilert AI SRE
Es ist 3 Uhr morgens und Sie erreicht eine Kundenbeschwerde: Die Produktbewertungen werden in einem Onlineshop nicht mehr angezeigt. Systemabstürze sind nicht feststellbar, keine der Alarmierungen liefert einen brauchbaren Hinweis. Irgendwo in Ihrer IT-Infrastruktur versagt ein Service – und wahrscheinlich ist es nicht derjenige, bei dem der Fehler sichtbar wird. Bevor Sie das Problem beheben können, müssen Sie die Ursache finden. Und genau diese Suche kostet Sie den Großteil der Nacht.
Stellen Sie sich nun vor, Sie öffnen Ihren Laptop, geben einen einzigen Satz ein und holen sich einen Kaffee. Wenn Sie zurückkommen, liegt die Ursache bereits auf dem Tisch – inklusive der entsprechenden Belege. Sie müssen die Ergebnisse nur noch überprüfen.
Genau darum geht es in diesem Artikel. Wir zeigen Schritt für Schritt, wie ilert AI SRE einen Fehler in unserem Demo-Onlineshop untersucht hat. Anschließend gehen wir einen Schritt zurück und erklären, welche Voraussetzungen wir dafür schaffen mussten.
Sie schauen lieber ein Video (auf Englisch)? Hier sehen Sie die gesamte Root-Cause-Analyse in weniger als vier Minuten. Die Einrichtung wird im Video nicht behandelt – die entsprechenden Schritte erklären wir weiter unten.
Das Problem
EWER ist ein kleiner Onlineshop, den wir zum Testen des AI-Agenten entwickelt haben. Im Hintergrund laufen 15 Rust-Services mit Logs, Metriken und Traces, die wie in einer produktiven Umgebung eingerichtet sind.
Öffnet man die Produktseite eines T-Shirts, werden zunächst alle Inhalte korrekt geladen, einschließlich der sechs Kundenbewertungen. Einige Zeit später zeigt dieselbe Seite weiterhin den Preis und die Produktbeschreibung an. Anstelle der Bewertungen erscheint jedoch die Meldung: „Die Bewertungen konnten gerade nicht geladen werden. Bitte versuchen Sie es später erneut.“ Bei anderen Produkten funktioniert alles einwandfrei.
Kein Pod wird neu gestartet und keine Alarmierung weist auf einen Ausfall hin. Der Service, bei dem der Fehler sichtbar wird, gibt lediglich einen Fehler weiter, der an anderer Stelle entsteht. Zudem sind nur bestimmte Produkte betroffen, ohne dass sich von außen eine erkennbare Ursache feststellen lässt. Alle Systeme, die man normalerweise überprüfen würde, scheinen einwandfrei zu funktionieren.
Diesen Fehler haben wir nicht eigens für die Demo eingebaut. Er gelangte unbeabsichtigt mit der Funktion zur Rückerstattung von Bestellungen in die Anwendung.
Die Untersuchung
Wir gaben dem AI-Agenten dieselbe Information, die wir vom Support erhalten hatten, und tippten folgende Anweisung in den Chat des Agenten ein: „Kunden beschweren sich, dass sie ihre Bewertungen nicht sehen können. Untersuche das Problem.“
Der Agent begann mit den Informationen, die ilert bereits vorlagen: offene Alarmierungen im Zusammenhang mit den Bewertungen, kürzlich erfolgte Deployments und die Servicetopologie, aus der hervorging, von welchen anderen Services der Bewertungsservice abhängig ist. Anschließend untersuchte er den Cluster und die Logs. Diesen Teil der Untersuchung führt der Agent in einer isolierten Sandbox aus – einer separaten Umgebung, die automatisch für die jeweilige Untersuchung eingerichtet wird und ausschließlich über die angebundenen Tools auf die Systeme zugreifen kann.
Da die Pods des Bewertungsservice fehlerfrei liefen, verfolgte der Agent die Anfragen entlang der nachgelagerten Services: vom Bewertungsservice zum Bestellservice und von dort zum Zahlungsservice. In den Logs des Zahlungsservice fand er schließlich den Fehler.
Wenige Minuten nach der Eingabe veröffentlichte der Agent sein Untersuchungsergebnis und kennzeichnete es mit einer hohen Konfidenz. Die Ursache: Um das Badge „Verifizierter Kauf“ anzuzeigen, fragt die Bewertungsseite für jede einzelne Bewertung den Bestellservice ab. Dieser wiederum fragt den Zahlungsservice ab. Der Zahlungsservice konnte eine erstattete Bestellung jedoch nicht korrekt verarbeiten und gab einen Fehler zurück. Keiner der beteiligten Services fing diesen Fehler ab. So führte eine einzige Rückerstattung dazu, dass die Bewertungen des betreffenden Produkts für alle Besucher nicht mehr angezeigt wurden.
Die Analyse war korrekt. Wir kannten die Ursache bereits im Voraus und das Ergebnis des Agenten stimmte damit überein.
Bei einer manuellen Untersuchung hätten wir wahrscheinlich beim Bewertungsservice begonnen, da dort der Fehler sichtbar wurde. Dessen Logs hätten uns zum Bestellservice geführt, die Logs des Bestellservice wiederum zum Zahlungsservice. Dort hätten wir schließlich die erstattete Bestellung gefunden. Das bedeutet, drei Services zu untersuchen – ein Aufwand von schätzungsweise 30 bis 45 Minuten, vorausgesetzt, wir hätten direkt beim richtigen Service angesetzt.
Wahrscheinlich wäre uns das jedoch nicht gelungen: Bei den Pods des Bewertungsservice waren in der Vergangenheit bereits Out-of-Memory-Alarmierungen aufgetreten. Diesen wären wir vermutlich zuerst nachgegangen. Der Agent überprüfte auch diese Alarmierungen und konnte sie als Ursache ausschließen.
Entscheidend für die Verwertbarkeit des Ergebnisses waren die Belege. Jede Erkenntnis ist mit der entsprechenden Logzeile, der Alarmierung oder dem Tool-Aufruf verknüpft, auf dem sie basiert. Eine Ursachenanalyse, die lediglich plausibel klingt, ist um 3 Uhr morgens wenig wert. Schließlich müsste man ohnehin jede Aussage selbst überprüfen. In unserem Fall reichte es aus, die verknüpften Belege durchzugehen. Das dauerte nur wenige Minuten.
Allerdings verlief auch diese Untersuchung nicht ganz reibungslos. Zwei Suchanfragen in den Logs des Zahlungsservice lieferten keine Ergebnisse, obwohl der Fehler die ganze Zeit vorhanden war. Mit einer breiter angelegten Suche konnte der Agent ihn schließlich doch finden.
Am Ende schlug der Agent acht Maßnahmen vor, darunter die Behebung des Fehlers im Zahlungsservice, einen zusätzlichen Test für erstattete Bestellungen und eine Anpassung der Bewertungsseite, damit Bewertungen auch dann angezeigt werden, wenn die Überprüfung für das Badge „Verifizierter Kauf“ fehlschlägt.
Eine dieser Aufgaben bot der Agent an, selbst zu übernehmen: zu überprüfen, ob andere Komponenten, die Zahlungsstatus auslesen, ebenfalls von diesem Fehler betroffen sind. Ein Klick auf „Execute with agent“ genügt, um die Untersuchung zu starten. Welche weiteren Aufgaben der Agent übernehmen kann, hängt von den angebundenen Tools und den erteilten Berechtigungen ab.
Was benötigt der Agent für die Root-Cause-Analyse?
Der Agent kann nur auf die Systeme und Daten zugreifen, die angebunden sind. Deshalb entscheidet die Einrichtung maßgeblich darüber, wie gut eine Untersuchung durchgeführt werden kann. Bei EWER waren dafür drei Schritte erforderlich:
- AI-Funktionen aktivieren: Aktivieren Sie die AI-Funktionen in Ihren Kontoeinstellungen und erstellen Sie einen Agenten für ein bestimmtes Team oder für alle Teams.
- Logs anbinden: Ohne Zugriff auf Logs kann der Agent nicht aktiviert werden. Wir haben Grafana angebunden. Dadurch erhielt der Agent Zugriff auf unsere Logs in Loki und unsere Traces in Tempo. Ein Service-Account mit der Rolle „Viewer“ reicht dafür aus.
- Kubernetes anbinden: Verbinden Sie die Umgebung, in der Ihre Services ausgeführt werden. Wir haben den ilert-kube-agent in unserem Cluster installiert. Dadurch konnten wir den Kubernetes MCP mit unserem AI SRE verbinden. So kann der Agent auf Pods, deren Status und Logs zugreifen.
Bei der Einrichtung des Agenten erstellt ilert anhand der Tracing-Daten automatisch eine Servicetopologie. Sie bildet ab, welche Services miteinander kommunizieren und voneinander abhängig sind. Dank dieser Informationen konnte der Agent den Anfragen gezielt vom Bewertungsservice über den Bestellservice bis zum Zahlungsservice folgen, anstatt die Ursache auf Verdacht zu suchen.
Für jede Verbindung werden anschließend die verfügbaren Tools aufgelistet. Sie entscheiden, welche davon der Agent verwenden darf.
Bei der Einrichtung stießen wir auf zwei Probleme. Erstens kann der Agent nicht auf Systeme zugreifen, die nicht erreichbar sind. Als unser EWER-Cluster ausgefallen war, musste der Agent bei jedem Zugriffsversuch auf einen Timeout warten, wodurch sich die Untersuchung erheblich verlangsamte.
Zweitens kann eine Datenbankverbindung deaktiviert sein, ohne dass es sofort auffällt. Als wir eine solche Verbindung hinzufügten, schlugen sämtliche Abfragen fehl, bis wir die entsprechende Einstellung entdeckten. Wenn eine ganze Gruppe von Tools nicht funktioniert, sollten Sie daher zunächst die Verbindung überprüfen, bevor Sie den Fehler beim Agenten suchen.
Würden wir EWER noch einmal neu einrichten, würden wir GitHub von Anfang an anbinden. Der Agent konnte den fehlerhaften Codepfad zwar allein anhand der Logs identifizieren. Mit Zugriff auf das Repository hätte er jedoch zusätzlich auf den Pull Request verweisen können, durch den der Fehler eingeführt wurde.
Was der Agent nicht macht
- Der Agent startet keine Untersuchungen von sich aus. Sie stellen eine Anfrage und der Agent führt die Untersuchung durch.
- Er nimmt auch keine eigenständigen Änderungen an Ihren Systemen vor. Stattdessen schlägt er Maßnahmen vor und Sie entscheiden, ob Sie diese genehmigen oder nicht.
- Der Agent hat ausschließlich Zugriff auf die angebundenen Systeme und Daten. Sie können für jedes Tool einzeln festlegen, ob der Agent es verwenden darf. Tools mit Schreibberechtigungen können vollständig deaktiviert bleiben.
Diese Untersuchung zeigt auch, wo wir derzeit die Grenzen für den Einsatz des Agenten ziehen würden. Einer seiner Vorschläge war eine Übergangslösung: Der Zahlungsservice sollte erstattete Zahlungen beim Auslesen aus der Datenbank überspringen. Dadurch wären die Produktbewertungen wieder angezeigt worden.
Allerdings hätte dies einen kurzfristigen Eingriff in den Code des Zahlungsservice bedeutet – unter Zeitdruck und mit dem Risiko, dass sich die Änderung später nur schwer sauber rückgängig machen lässt. Deshalb sollten alle Eingriffe, die Geld oder Kundendaten betreffen oder nicht rückgängig gemacht werden können, weiterhin von Menschen durchgeführt werden.
Fragen und Antworten
Was muss angebunden sein, damit ilert AI SRE sinnvoll eingesetzt werden kann?
Mindestens die Logs. In der Praxis empfiehlt es sich, zusätzlich Traces und den Zugriff auf die Umgebung einzurichten, in der Ihre Services laufen, beispielsweise Kubernetes. Traces erfüllen dabei zwei Funktionen: Sie liefern Belege für die Ursachenanalyse und ermöglichen es ilert, die Abhängigkeiten zwischen den einzelnen Services zu erkennen.
Wie lange dauert die Einrichtung?
Die Einrichtung in ilert selbst dauert nur wenige Minuten: Sie erstellen einen Agenten und verbinden die gewünschten Tools. Der größere Zeitaufwand entsteht auf Ihrer Seite, beispielsweise durch das Anlegen eines Grafana-Kontos mit Leseberechtigung oder die Installation des Kubernetes-Agenten und die Einrichtung des Zugriffs durch ilert.
Nimmt der Agent eigenständig Änderungen an Produktivsystemen vor?
Nein. Für die Untersuchung benötigt der Agent lediglich Leseberechtigungen und schlägt anschließend geeignete Maßnahmen vor. Tools mit Schreibberechtigungen bleiben deaktiviert, sofern Sie diese nicht ausdrücklich freigeben. Änderungen werden erst vorgenommen, wenn ein Engineer sie genehmigt.
Auf welche Daten kann der Agent zugreifen und wo wird er ausgeführt?
Der Agent kann ausschließlich auf die angebundenen Systeme und Daten zugreifen. Zugangsdaten mit reinen Leseberechtigungen reichen dafür aus. Jede Untersuchung wird in einer eigenen, isolierten Sandbox ausgeführt, die nur über diese Verbindungen auf Ihre Systeme zugreifen kann.
Für Kunden in der EU erfolgt die gesamte AI-Verarbeitung auf dedizierten Servern in Frankfurt und Stockholm. Dabei verlassen keine Daten die EU. Ihre Daten werden nicht zum Trainieren von AI-Modellen verwendet.
Für welche Arten von Incidents eignet sich ilert AI SRE besonders?
Den größten Zeitgewinn bietet ilert AI SRE, wenn das sichtbare Problem und seine eigentliche Ursache in unterschiedlichen Services liegen – beispielsweise, wenn Produktbewertungen aufgrund eines Fehlers im Zahlungsservice nicht angezeigt werden.
Der Agent kann auch Incidents untersuchen, bei denen die Ursache direkt in dem Service liegt, der den Fehler anzeigt. Solche Probleme hätten Sie allerdings wahrscheinlich auch selbst schnell gefunden. Die entscheidende Grenze ist die verfügbare Telemetrie: Wenn Ihre Logs, Metriken oder Traces das Problem nicht erfassen, kann auch der Agent die Ursache nicht finden.
Erstellen Sie ein kostenloses ilert-Konto, verbinden Sie Ihre Logs und starten Sie Ihre erste Untersuchung anhand einer bereits vorhandenen Alarmierung.
Wenn Sie ilert AI SRE lieber zunächst in einem Live-System erleben möchten, vereinbaren Sie eine Demo. Wir führen Sie Schritt für Schritt durch die Funktionen.
