Fragen Sie ein Sprachmodell: „Warum ist der Checkout-Service ausgefallen?“, während vierzig Warnmeldungen ausgelöst werden, und es wird Ihnen eine Geschichte erzählen.
Es wird gut strukturiert, überzeugend und plausibel sein. Vielleicht ist es sogar richtig.
Aber Plausibilität ist eine Eigenschaft der Prosa. Korrektheit ist eine Eigenschaft des Systems. Und je mehr das Modell raten muss, desto weiter driften diese beiden Eigenschaften auseinander.
Der Instinkt sagt uns, nach einem besseren Modell zu suchen. Wir halten das jedoch für den falschen Ansatz.
Der bessere Ansatz besteht darin, dem Modell weniger Raum für Spekulationen zu lassen – jede Frage zu beantworten, für die es eine deterministische Antwort gibt, bevor das probabilistische Schlussfolgern beginnt.
Zwei Strukturen übernehmen den Großteil dieser Arbeit: eine Topologiekarte, die zeigt, was derzeit von was abhängt, und ein Wissensgraph, der aufzeigt, was zuvor geschehen ist.
Deterministisch, wo es möglich ist, probabilistisch, wo es sein muss
Betrachten wir einmal die Fragen, die ein Ingenieur während eines Vorfalls tatsächlich stellt:
- Wovon hängt dieser Dienst ab? – Er ist deterministisch. Es handelt sich um eine Abfrage in einem Graphen.
- Was ist noch betroffen, wenn dies fehlschlägt? – deterministisch. Gleicher Graph, entgegengesetzte Richtung.
- Wurde in der letzten Stunde etwas bereitgestellt? – deterministisch. Es handelt sich um eine Ereignisabfrage.
- Ist das schon einmal vorgekommen, und wie wurde das Problem behoben? – deterministisches Abrufen, dann Beurteilung.
- Was ist angesichts all dessen die wahrscheinlichste Ursache? – probabilistisch. Hier kommt das Modell ins Spiel.
Bei den meisten KI-gestützten RCA-Verfahren werden dem Modell alle fünf Fragen sowie die Telemetriedaten des gesamten Clusters übergeben, und es wird aufgefordert, die Sachlage zu klären.
Wir würden die ersten vier Fragen lieber anhand eines Diagramms und einer Datenbank beantworten und dem Modell dann für die fünfte Frage eine kleine, begrenzte und zitierte Auswahl an Kandidaten vorlegen.
Dadurch wird die KI-Untersuchung zielgerichteter – und leichter zu überprüfen.
Die Topologiekarte: Wissen, was von was abhängt
Die Abhängigkeitskarte ist ein Graph aus Entitäten – Clustern, Knoten, Namespaces, Workloads, Pods, Diensten, Datenbanken und externen Endpunkten –, die durch typisierte Kanten wie „enthält“, „hostet“, „führt zu“, „ruft auf“ und „hängt ab von“ miteinander verbunden sind.
Es ist umgebungsspezifisch, mandantenisoliert und bewusst klein gehalten: Hunderte bis wenige Tausend Knoten für einen typischen Kundencluster.
Alles folgt einer einheitlichen Richtungsregel, die einmal festgelegt und überall durchgesetzt wird:
A ──HÄNGT VON──▶ B
A benötigt B, um zu funktionieren.
Für einen Alarm auf A:
- Mögliche Ursachen → ausgehende Kanten verfolgen
- Explosionsradius → eingehende Kanten verfolgen
Das reicht aus, um mögliche Ursachen zu ermitteln und eine begrenzte Graphdurchquerung durchzuführen.
Der Graph ist bewusst so klein gehalten, dass er als rekursive Abfrage gegen die relationale Datenbank ausgeführt werden kann, über die die Plattform bereits verfügt – keine Graphdatenbank, keine zweite Quelle der Wahrheit und nichts Neues, was betrieben werden müsste.
Die meisten Stürme, für die Warnungen ausgegeben werden, verlaufen vertikal und nicht horizontal
Eine Beobachtung hat diesen Entwurf maßgeblich geprägt: Viele Sturmwarnungen beziehen sich auf eine Begrenzung und nicht auf eine Ausbreitung.
Ein Knoten fällt aus. Dies löst Pod-Warnungen, Workload-Warnungen und Namespace-Warnungen aus. Es handelt sich dabei um dasselbe Ereignis, das auf verschiedenen Ebenen der Kubernetes-Objekthierarchie auftritt.
Man benötigt nicht unbedingt einen Service-Call-Graphen, um diese Warnmeldungen zusammenzufassen. Man muss wissen, welcher Pod zu welcher Workload gehört und auf welchem Knoten er gehostet wird.
Diese Informationen werden bereits aus dem Netz abgegriffen.
kube-state-metrics veröffentlicht den Kubernetes- Zugehörigkeitsgraphen als Prometheus -Zeitreihen – Pod zu Eigentümer, ReplicaSet zu Deployment, Pod zu Knoten, Ingress zu Service.
Wenn man diese Beziehungen miteinander verknüpft, ergibt sich die Beziehung „Pod → Deployment“. Das ist wichtig, da Warnmeldungen häufig Pods identifizieren, während Operatoren in Workloads denken.
Die Basistopologie verursacht also keine zusätzlichen Kosten: kein neuer Agent, keine zusätzlichen Berechtigungen und kein separater Mechanismus zur Datenerfassung. Sie wird über denselben Remote-Write-Kanal bereitgestellt, den der Prometheus-Agent der Plattform bereits nutzt.
Erstellung des restlichen Teils der Abhängigkeitskarte
Dienstübergreifende Kaskaden – beispielsweise wenn eine Zahlungs-API langsam wird, weil ihre Datenbank langsam ist – erfordern Beziehungen auf Aufrufebene.
Verschiedene Datenquellen bieten unterschiedliche Transparenzgrade:
| Quelle | Was uns das sagt | Selbstvertrauen |
|---|---|---|
| kube-state-metrics | Eigentumsverhältnisse und Eindämmung | Fakt |
| CoreDNS dnstap | Ein aufgelöstes B, einschließlich externer Abhängigkeiten | Existenz |
| OpenTelemetry | Tatsächliche Serviceeinsätze, Tarife und Fehler | Gemessen |
| eBPF | Aufrufe auf Kernel-Ebene, Volumen und Fehler | Gemessen |
Jede davon weist unterschiedliche Betriebskosten und ein unterschiedliches Maß an Zuverlässigkeit auf.
DNS ist besonders nützlich, da es Abhängigkeiten über die Clustergrenze hinweg aufdecken kann. Aus Traces abgeleitete Graphen zeigen externe Abhängigkeiten nur dann an, wenn der Aufrufer instrumentiert ist, während die Kubernetes-Steuerungsebene diese überhaupt nicht erkennt.
Das Cluster-DNS erhält Auflösungsanfragen von jedem Pod.
Da sie keine Angaben zum Datenverkehrsaufkommen oder zu fehlgeschlagenen Anrufen liefern können, fließen DNS-Edge-Server nicht in die „Blast-Radius“-Gewichtung ein. Sie können jedoch nachweisen, dass eine Abhängigkeit besteht – einschließlich solcher, die noch von niemandem dokumentiert wurden.
Jede Kante ist mit ihrer Herkunft und ihrem Vertrauenswert versehen.
Eine aus dem DNS abgeleitete Kante sieht nicht wie eine aus einer gemessenen Kurve abgeleitete Kante aus, und eine Tatsache aus der Steuerungsebene sieht nicht wie eine Schlussfolgerung aus. Wenn zwei Quellen übereinstimmen, sind beide sichtbar.
Ein beobachteter Aufruf ist nicht unbedingt eine Abhängigkeit.
Das ist ein wichtiger Unterschied.
eBPF und Traces können Ihnen zeigen, dass A B aufgerufen hat. Sie zeigen jedoch nicht unbedingt, dass A fehlschlägt, wenn B fehlschlägt.
Ein Dienst könnte bei jeder Anfrage einen Analytics-Endpunkt aufrufen und die Antwort einfach ignorieren, falls es zu einer Zeitüberschreitung kommt. Es gibt zwar eine Grenze, aber es handelt sich um eine weiche Abhängigkeit.
Wenn man den Explosionsradius so berechnet, als wären alle Kanten hart, überschätzt man die Auswirkungen vieler Vorfälle.
Die Kantenkritikalität – ob „hart“ oder „weich“ – ist also ein eigenständiges Attribut, das die Karte nicht ableiten kann. Sie wird von einem Operator festgelegt.
Die Grafik zeigt Ihnen die Struktur. Sie gibt nicht vor zu wissen, worauf es ankommt.
Der unscheinbare Teil, der über alles entscheidet
All dies funktioniert nur, wenn eine eingehende Warnmeldung einem Knoten im Graphen zugeordnet werden kann.
Die Bezeichnungen der Warnmeldungen sind nicht einheitlich. Ein Exporter verwendet den Begriff „pod“, ein anderer „pod_name“ und wieder ein anderer „kubernetes_pod_name“. „instance“ kann in einem System eine IP-Adresse und einen Port bezeichnen, in einem anderen hingegen einen Hostnamen.
Die Normalisierung der Beschriftungen ist, ehrlich gesagt, das gesamte Design.
Dies wird durch einen datengesteuerten Satz von Extraktionsregeln pro Technologie geregelt, mit kundenspezifischen Ausnahmen – und es wird gemessen.
Die Plattform gibt eine Zahl an:
Wie viel Prozent der Warnmeldungen lassen sich einer Entität auf Workload-Ebene zuordnen?
Ist dieser Wert niedrig, verliert jede nachfolgende Klassifizierung an Zuverlässigkeit. Wir ziehen es vor, diese Kennzahl offenzulegen, anstatt sie zu verbergen.
Der Knowledge Graph: Was zuvor geschah
Die Topologie gibt Aufschluss über die Struktur.
Es vermittelt dir keine historischen Kenntnisse.
Die zweite Ebene ergänzt dieselben Entitäten um betriebliches Wissen:
- Bereitstellungsereignisse aus der GitOps-Pipeline des Kunden – denn „Was hat sich geändert?“ ist oft die erste Frage, die bei einem Vorfall gestellt wird.
- Frühere RCA-Fälle – abgeschlossene Untersuchungen, die als Vorfall, Grundursache, Beweismittel und Abhilfemaßnahme gespeichert sind und dann anhand semantischer Ähnlichkeit abgerufen werden, wenn ein neuer Vorfall einem alten ähnelt.
- Zugehörige Jira-Tickets – gefunden durch eine Freitextsuche im verbundenen Projekt des Kunden.
- Runbooks und SOPs – bereits mit Alarmtypen und Betriebsabläufen verknüpft.
Betrachten Sie den Unterschied zwischen bloßer Geschichte und nützlicher Erinnerung.
„Der Verbindungspool war erschöpft, nachdem bei einer Konfigurationsbereitstellung die maximale Anzahl an Verbindungen gesenkt worden war; der Vorgang wurde rückgängig gemacht und das Problem innerhalb von drei Minuten behoben.“
Das ist für die nächste Untersuchung weitaus nützlicher als eine Datenbank voller zusammenhangloser Telemetriedaten.
Jede Wissensquelle ist von Natur aus umgebungsspezifisch und mandantenisoliert – es gibt einen separaten Index pro Mandant, anstatt eines Laufzeitfilters, dessen Verwendung leicht vergessen werden könnte.
Wie Topologie und Wissensgraphen die KI-gestützte RCA verändern
Führt man diese beiden Strukturen zusammen, verändert sich die Aufgabe des RCA-Mitarbeiters erheblich.
Die Triage wird präziser.
Signale zum Ausbreitungsradius – wie viele Namespaces betroffen sind, ob gemeinsame Infrastruktur beteiligt ist und wie viele nachgelagerte Warnmeldungen ausgelöst werden – lassen sich nun anhand der Topologie berechnen, anstatt nur geschätzt zu werden.
Entsprechende Warnmeldungen können auch nach ihrer Nähe im Diagramm und nicht nur nach dem Zeitfenster gruppiert werden.
Dies ist der topologiebewusste Teil der Triage-Pipeline, den wir im vorherigen Beitrag besprochen haben.
Die Menge der Kandidaten wird kleiner.
Anstatt den gesamten Cluster zu erhalten, erhält das Modell:
- die Entität des Alarms;
- vorgelagerte Abhängigkeiten innerhalb weniger Schritte;
- Vertrauen und kritische Bewertung dieser Abhängigkeiten;
- die jüngsten Einsätze, von denen sie betroffen sind; und
- die jüngsten RCA-Folgen.
Dadurch ergibt sich ein abgegrenzter, genau definierter Untersuchungsumfang.
Die Argumentation lässt sich leichter überprüfen.
Da es sich bei den Eingaben um abrufbare Fakten handelt, können Aussagen in der RCA den Tool-Aufruf zitieren, durch den sie erzeugt wurden. Ein separater Verifizierer kann diese Zitate dann anhand des aufgezeichneten Ausführungsablaufs überprüfen.
Die Schichten haben klar definierte Aufgaben:
Die deterministische Ebene grenzt ein.
Die probabilistische Ebene liefert Erklärungen.
Die Verifikations-Ebene führt Prüfungen durch.
Das Modell hat immer noch mit dem schwierigen Teil zu kämpfen.
Es geht einfach nicht mehr darum, die einfachen Teile schlecht zu machen.
Was die topologische Karte Ihnen nicht verrät
Eine Abhängigkeitsübersicht ist keine vollständige Bestandsaufnahme.
Die Control-Plane-Ebene bildet lediglich das ab, was der Cluster meldet. Das DNS erkennt nur das, was über das Cluster-DNS aufgelöst wird, sodass direkter IP-Verkehr und langlebige Pool-Verbindungen nicht sichtbar sind. Traces decken nur instrumentierte Dienste ab.
Eine Abhängigkeitsübersicht sollte niemals wie folgt dargestellt werden:
„Hier ist alles.“
Es sollte heißen:
„Das können wir beweisen, und zwar mit der entsprechenden Sicherheit.“
Das gleiche Prinzip gilt auch für die Korrelation.
Wenn eine Korrelationsregel einen tatsächlichen Vorfall verbergen könnte, indem sie ein Symptom einem bestehenden Vorfall zuordnet, anstatt einen neuen zu eröffnen, läuft sie zunächst im Schattenmodus.
Es kann wochenlang laufen und Ergebnisse liefern, die mit dem tatsächlichen Verhalten der Betreiber abgeglichen werden, bevor auch nur ein einziger Fahrschein geändert wird.
Wo dies in die ITGix-AIOps-Plattform passt
Topologie und Wissensgraphen sind keine eigenständige Funktion. Sie sind Teil des umfassenderen Workflows zur Störungsbehebung, den wir innerhalb der ITGix AIOps-Plattform aufbauen .
Die Topologieebene liefert den aktuellen Zustand der Umgebung. Die Wissensebene liefert die Betriebshistorie. Zusammen bieten sie dem KI-SRE-Agenten einen überschaubareren und zuverlässigeren Kontext für die Untersuchung.
Das steht auch in direktem Zusammenhang mit den in den vorherigen Beiträgen behandelten Funktionen zur Alarm-Triage und zur Ursachenanalyse (RCA):
Warnmeldungen → Triage → Korrelation → Topologiekontext → KI-Untersuchung → verifizierte Ursacheanalyse (RCA) → Behebung
Das Ziel ist es nicht, die KI dazu zu bringen, bessere Vorhersagen zu treffen.
Damit soll von vornherein sichergestellt werden, dass es weniger zu erraten gibt .
Wo wir sind
Die Topologie wird schrittweise aufgebaut.
Die Entitätsextraktion und die Control-Plane-Karte stehen an erster Stelle, da sie einen überprüfbaren Graphen liefern, ohne dass dabei das Risiko von Fehlalarmen besteht. Es folgen Änderungen an der Streaming-Pipeline und anschließend eine topologiebewusste Triage im Schattenmodus.
Danach folgen DNS, Trace und die eBPF-Anreicherung mit Opt-in.
Die RCA-Speicherfunktion – einschließlich des Abrufs von Episoden und der Suche nach ähnlichen Problemen in Jira – ist ebenfalls in der Roadmap vorgesehen.
Wir geben Bescheid, sobald die einzelnen Beiträge online sind.
In der Zwischenzeit gilt weiterhin der Grundsatz:
Beantworte zuerst alle Fragen, auf die es eine deterministische Antwort gibt, und die KI wird bei der Frage, auf die es keine gibt, deutlich besser.
Behalten Sie die ITGix-Blogs im Auge, um das nächste Kapitel nicht zu verpassen.
