Agentengestützte Kubernetes-Untersuchungen mit Elastic Observability und MCP

Monitor clusters, pods, and nodes with full application context across EKS, GKE, AKS, and OpenShift. 

Join our on-demand webinar: Kubernetes management with Elastic & agentic AI to level up your skills. You can also start a free cloud trial, or run Elasticsearch locally.

Agentengestützte Kubernetes-Beobachtbarkeit ist jetzt in Elastic Observability verfügbar. Ganz gleich, ob Sie die Benutzeroberfläche von Elastic Observability oder Ihre eigenen agentischen Workflows nutzen: Elastic bietet eine Reihe von Funktionen, mit denen Sie das jeweilige Kubernetes-Problem untersuchen können. Wir haben eine MCP-App (Model Context Protocol) veröffentlicht, mit der KI-Agenten wie Claude und Cursor Elastic Observability abfragen können, um K8s-Fehler zu verstehen und ML-Anomalien aufzudecken, ohne Ihre Chat-Schnittstelle zu verlassen.

In Teil 1 haben wir behandelt, wie die Kubernetes-Integration von Elastic Telemetriedaten über den EDOT Collector in Elasticsearch versendet. In diesem Beitrag gehen wir noch einen Schritt weiter mit einem MCP-App-Server (Model Context Protocol), der diese Telemetriedaten als von KI aufrufbare Tools bereitstellt – komplett mit interaktiven React-Benutzeroberflächen, die inline gerendert werden. Wir behandeln außerdem, wie Sie mit Elastic Workflows noch weiter gehen können: automatisierte Runbooks, die den gesamten Ursachenanalyse-Ablauf vom Alert bis zum Behebungsvorschlag übernehmen.

Observability MCP-App, die dort rendert, wo Sie arbeiten

Die Elastic Observability MCP-App (technische Vorschau) liefert sechs Ansichten, jeweils eine pro Tool. Jede wird inline gerendert, wenn das Tool eine Antwort zurückgibt, und jede stellt konkrete Prompts für die nächsten Schritte als anklickbare Schaltflächen bereit, sodass Sie nicht raten müssen, wie Sie richtig fortfahren. MCP-Apps gehen über eigenständige Agenten-Workflows hinaus – sie rendern interaktive Live-Ansichten direkt in Ihrem Chat oder Ihrer IDE, inline im Gespräch, ohne einen Kontextwechsel zu Kibana.

Cluster-Health-Rollup

Fragen Sie „Was ist defekt?“ oder „Gib mir einen Statusbericht“ und erhalten Sie eine Übersicht auf einen Blick: allgemeiner Zustand, beeinträchtigte Dienste mit Begründungen, die größten Pod-Speicher-Verbraucher, Aufschlüsselung des Schweregrads der Anomalien und der Service-Durchsatz – alles in einer einzigen Inline-Ansicht.

Die Ansicht passt sich an die Gegebenheiten Ihres Deployments an. APM liefert Ihnen Service-Health-Informationen. Kubernetes-Metriken fügen Pod- und Knoten-Kontext hinzu. ML-Jobs integrieren Anomalien. Wenn ein Signal nicht vorhanden ist, teilt Ihnen die Ansicht mit, was fehlt, anstatt fehlzuschlagen. Wir beginnen mit einem Statusbericht des Kubernetes-Clusters:

Kombinierte Berichte wie die Statusübersicht bieten eine kompakte Datendarstellung mit Detailerweiterung, sodass Sie selbst bestimmen können, wie viele Informationen Sie auf einmal anzeigen lassen möchten. Vorgeschlagene Untersuchungsaktionen bieten sowohl Hilfestellung zu spezifischen zurückgegebenen Informationen als auch eine Orientierung für Nutzer bezüglich weiterer auszuführender Tools.

Dienstabhängigkeitsgraph

Fragen Sie „Welche Services kommunizieren mit Checkout?“ oder „Zeig mir die Topologie“ und Sie erhalten einen geschichteten Abhängigkeitsgraphen – vorgelagerte Aufrufer, nachgelagerte Abhängigkeiten, Protokolle, Anrufvolumen und Latenz pro Edge. Fahren Sie mit dem Mauszeiger über einen Edge, um den vollständigen Aufrufpfad hervorzuheben. Bitten wir Claude, uns die Serviceabhängigkeiten des Frontends zu zeigen („Zeig mir die Serviceabhängigkeiten des Frontends“):

Zoomen Sie, schwenken Sie und bewegen Sie den Mauszeiger, um alle Details zu sehen, die Sie zum Verständnis der komplexen Servicebeziehungen benötigen:

Anomaliedetails

Fragen Sie „Was ist anomal?“ oder „Gibt es in Checkout etwas Ungewöhnliches?“ und erhalten Sie automatisch eine von zwei Ansichten. Wenn mehrere Entitäten betroffen sind, zeigt der Überblicksmodus Anzahlen nach Schweregrad, betroffene Entitäten und eine Aufschlüsselung nach Jobs. Wenn eine einzelne Entität im Fokus steht, zeigt der Detailmodus den Score, Ist- und typische Werte mit einem Vergleichsbalkendiagramm, die prozentuale Abweichung und, sofern verfügbar, eine Zeitreihe. Sehen wir uns den Frontend-Service an:

Dies ist keine ESQL-Abfrage, sondern eine Erläuterung der Ergebnisse eines zuvor definierten Anomalieerkennungsjobs. Wie in Teil 1 dieser Blogreihe erläutert, bringt die Kubernetes-Integration einige davon mit, die Sie aktivieren können. Dieses Tool hilft Ihnen, das Beste aus ihnen herauszuholen.

Observe

Observe ist das primäre Zugriffsprimitiv des Agenten für Elastic – ein Tool mit zwei Modi für drei verschiedene Bedürfnisse. Fragt man „Wie hoch ist der Netzwerkdurchsatz jedes meiner Kubernetes-Cluster?“, erhält man eine Tabelle oder ein Diagramm mit den Ergebnissen. Sagt man „Sag mir, wenn der Speicher unter 80 MB fällt“ oder „Achte für die nächsten 10 Minuten auf alles Ungewöhnliche beim Frontend-Speicher“, blockiert es, bis die Bedingung erfüllt ist oder das Zeitfenster abläuft.

Die Ansicht passt sich an den jeweiligen Modus an: eine Ergebnistabelle für einmalige Abfragen, ein Live-Trenddiagramm mit aktuellen, Spitzen- und Baseline-Statistiken für Stichproben- und Schwellenwertbedingungen sowie eine Triggerkarte mit Schweregradbewertung für den Anomalienmodus. Wir nutzen sie hier, um den am stärksten ausgelasteten Kubernetes-Knoten zu ermitteln:

Risiko mit einem Schadensradius bewerten

Fragen Sie „Was passiert, wenn dieser Knoten ausfällt?“ und erhalten Sie ein radiales Auswirkungsdiagramm: der Ziel-Knoten in der Mitte, vollständig ausgefallene Deployments in Rot, beeinträchtigte in Gelb und unbeeinflusste in Grau. Eine schwebende Übersichtskarte zeigt gefährdete Pods und die Machbarkeit der Neuplanung an. Single-Replica-Deployments werden als Single Points of Failure markiert. Was würde passieren, wenn unser stark ausgelasteter Knoten ausfiele:

Alert-Verwaltung

Mit dem Tool zur Alert-Verwaltung können Sie Alerts erstellen, auflisten, Informationen abrufen und Alerts löschen. Als Nächstes erstellen wir einen Alert. Verwenden Sie zuvor jedoch noch einmal Observe, um schnell eine Baseline zu ermitteln, damit wir wissen, dass der Alert Sinn machen wird:

Sagen Sie „Benachrichtige mich, wenn der Frontend-Speicher 75 MB überschreitet“ und der Agent erstellt eine persistente Kibana-Alerting-Regel – ein gespeichertes Objekt, das auch nach Beendigung der Unterhaltung weiter ausgeführt wird. Die Ansicht rendert eine Live-Regelkarte: Regelname, Bedingung, Zeitfenster, Prüfintervall, KQL-Filter und Tags. Schaltflächen für nächste Schritte bieten die Möglichkeit, die Regel zu überprüfen, die Stabilisierung der Metrik zu beobachten oder den aktuellen Cluster-Zustand zu prüfen. Der Agent bestätigt, was erstellt wurde und wo es in Kibana zu finden ist:

MCP-App-Architektur

Die App besteht aus einem Node.js-Server, sechs modellorientierten Tools, die mit sechs Einzeldatei-Ansichtsressourcen verbunden sind, reinen App-Tools für erneute Abfragen und vite-plugin-singlefile-Bundling. Die Tools sind nach Deployment-Backend gruppiert (Universal, APM-abhängig, K8s-abhängig, ML-abhängig), sodass sowohl der Agent als auch der Nutzer im Voraus wissen, welche Tools für ein bestimmtes Deployment relevant sind, anstatt beim Aufruf Fähigkeitslücken zu entdecken. Das Repo enthält sechs Skills als separate .zip- Artefakte, die dem Agenten beibringen, wann und wie jedes Tool aufgerufen werden soll.

Das folgende Diagramm zeigt die drei Komponenten, aus denen die App besteht: den MCP-Host (Claude Desktop, VS Code oder ähnlich), der das LLM und die Claude-Skills enthält, die ihm beibringen, wie die Tools verwendet werden; den MCP-App-Server, einen einzelnen Node.js-Prozess, der die Tool-Registry bereitstellt, die React-UI-Ansichten bündelt und die gesamte Kommunikation mit Elastic abwickelt; und den Elastic Stack selbst, in dem Elasticsearch und Kibana als Live-Daten- und Alerting-Backends dienen.

Das folgende Diagramm veranschaulicht den Ablauf einer Nutzeranfrage: Claude liest die entsprechende Skill-Datei, um zu verstehen, welches Tool aufgerufen werden soll und wie dessen Parameter auszufüllen sind, ruft das Tool auf, das serverseitige Abfragen an Elasticsearch und Kibana auslöst, und erhält eine kompakte Textzusammenfassung zusammen mit einer React-UI-Ressource zurück, die inline als interaktives Widget gerendert wird.

Vom Alert zur Ursache: Untersuchungs-Workflows

Alert-Regeln teilen Ihnen mit, dass etwas nicht stimmt. ML-Module zeigen Ihnen das Muster. Elastic Workflows führen die Diagnose aus – automatisch, sobald ein Alert ausgelöst wird.

Wir stellen einen Kubernetes-Untersuchungs-Workflow (technische Vorschau) bereit, der bei einem Kubernetes-Alert ausgelöst wird und eine strukturierte Ursachenzusammenfassung zurückgibt, bevor Sie ein einziges Dashboard geöffnet haben. Der SRE, der per Pager benachrichtigt wird, öffnet den Alert und stellt fest, dass die Untersuchung bereits abgeschlossen ist.

Der Workflow ist ein gerichteter Graph von Schritten, der mehrere Datenquellen abfragt – primär über die Elasticsearch Query Language (ES|QL), mit einer Elasticsearch-Suche für das Nachschlagen von ML-Anomalien. „if“-Schritte verzweigen sich anhand von Abfrageergebnissen und entscheiden, welcher Abgleich ausgeführt werden soll (ML-Speicheranomalie vs. Log-Klassifizierung) und ob der Upstream-Zustand überprüft werden soll (nur bei bestehenden APM-Abhängigkeiten). KI-Schritte kommen an drei Stellen vor: bei der Klassifizierung von Log-Mustern auf dem Nicht-OOM-Pfad, bei der Einstufung von Upstream-Komponenten als beeinträchtigt vs. fehlerfrei und bei einem abschließenden „ai.summarize“, das alle strukturierten Belege zu einer Ursachenanalyse zusammenfasst.

Wie der Untersuchungs-Workflow in der Praxis aussieht

Die folgende Beispielausführung basiert auf dem OpenTelemetry Astronomy Shop, der mit Elastic ausgeführt wird – 16 Dienste, Kafka, PostgreSQL, alle über OTLP vorinstrumentiert. Neben der echten Telemetrie des Shops haben wir eine synthetische OOMKill-Kaskade eingespeist, die über die EDOT-Datenströme synthetische K8s- und APM-Signale in denselben Namespace schreibt. Der Workflow kann unsere Signale nicht von echten unterscheiden – er untersucht lediglich den Alert.

Alert ausgelöst: CrashLoopBackOff – app-deployment in oteldemo-esyox-default. Anzahl der Neustarts: 6.

Workflow-Schritt 1 – Pod- und Container-Kontext charakterisieren

Der Workflow fragt K8s-Metriken für die Neustartanzahl, den letzten Beendigungsgrund und die Auslastung im Vergleich zu deklarierten Limits ab.

Ergebnis: Letzter Beendigungsgrund OOMKilled, Anzahl der Neustarts 6. (Hinweis: Die kubeletstats-Auslastung war für diesen Pod/dieses Zeitfenster nicht verfügbar – der Workflow wird ordnungsgemäß fortgesetzt.)

Workflow-Verzweigungen: Der Beendigungsgrund ist OOMKilled, daher nimmt der Workflow den Pfad zur Speicheruntersuchung, nicht den Pfad zur Log-Untersuchung.

Workflow-Schritt 2a – ML-Anomalieergebnisse einsehen

Anstatt Speichertrends neu zu berechnen, fragt der Workflow den ML-Anomalieindex nach einer aktiven „k8s_pod_memory_growth“-Anomalie ab.

Ergebnis: Keine Anomalie – die Spitze wird als lastbedingt gekennzeichnet, nicht als mutmaßliches Leck.

Workflow-Schritt 3 – Upstream-Service-Integrität prüfen

Der Workflow listet Upstream-Abhängigkeiten aus den APM-„service_destination.1m“-Aggregaten auf und vergleicht dann die aktuelle Fehlerrate und mittlere Latenz mit derselben Stunde vor 7 Tagen. Ein KI-Klassifizierungsschritt entscheidet, ob dem Alert eine Upstream-Verschlechterung vorausgegangen ist. Ergebnis: Ein Upstream – api-gateway. Aktuelle mittlere Latenz 15,13 ms, Fehlerrate 41,26 %. Baseline (vor 168 Std.): identisch. Klassifizierung: upstream_healthy – innerhalb der Schwellenwerte von 5 × Fehler / 3 × Latenz. Upstream ist ausgeschlossen.

Workflow-Schritt 4 — Mit kürzlichen K8s-Änderungen korrelieren

Das Event-Log für den Namespace zeigt einen engen Zyklus von Pulled → Created → Started → Killing → BackOff, der sich etwa alle 60–90 Sekunden wiederholt. Keine Deployments oder Skalierungsereignisse in den vergangenen zwei Stunden.

Workflow-Ausgabe:

URSACHENHYPOTHESE (Konfidenz: hoch)

app-deployment führt unter Speicherdruck OOMKilling durch. Der Pod hat
6 Neustarts mit dem Beendigungsgrund OOMKilled durchgeführt. ML hat die Speicherspitze als
lastbedingt markiert (kein Leck). Upstream-api-gateway ist fehlerfrei entsprechend der aktuellen 7-Tage-
Baseline. Dies ist ein Ressourcenzuweisungsproblem – das Speicherlimit des Containers
ist für seinen tatsächlichen Arbeitssatz zu niedrig.

Beweis:
- 6 Neustarts, letzter Beendigungsgrund OOMKilled
- Keine ML-memory-growth-Anomalie → leak_suspected=false (lastbedingt)
- Upstream-api-gateway unverändert im Vergleich zur 7-Tage-Baseline (15,13 ms, 41,26 %) → fehlerfrei
- K8s-Ereignisse zeigen enge Pulled/Created/Started/Killing/BackOff-Zyklen;
  keine Deployments in den letzten 2 Std.

Wahrscheinliche Ursache: Speicherlimit für den tatsächlichen Arbeitssatz unter Last unzureichend.

Empfohlene nächste Schritte:
1. Erhöhen Sie das Arbeitsspeicherlimit für app-deployment basierend auf der beobachteten Nutzung
2. Überprüfen Sie den Anwendungscode auf Speicheroptimierungsmöglichkeiten
3. Ziehen Sie eine Graceful degradation auf Pfaden mit hoher Last in Betracht

Nachgelagerte Auswirkungen: anhand von APM-Zielmetriken keine identifiziert.

Die obige Ausgabe zeigt, wie der Alert aussieht, wenn Sie ihn öffnen – kein Link zu einer Reihe von Logs oder einem Dashboard, sondern eine Antwort.

Derselbe Workflow ist als MCP-Tool über Claude Desktop, VS Code oder jeden MCP-kompatiblen Client zugänglich. Wenn ein Entwickler über seine IDE fragt: „Warum gibt Checkout einen Fehler aus?“, ruft der Agent den Workflow auf und gibt dieselbe strukturierte Ausgabe inline zurück – dieselben Belege, dieselbe Grundursache –, ohne den Editor zu verlassen.

Hier ist eine animierte Schritt-für-Schritt-Anleitung zur Workflow-Ausführung:

Beobachtbarkeit-Skill für Kubernetes-Untersuchungen

Wir stellen außerdem einen einzelnen, umfassenden Untersuchungs-Skill („observability-k8s-investigation“) bereit, der das vollständige Diagnoseprotokoll für Probleme mit Kubernetes-Workloads, -Knoten und der control-plane enthält. Es handelt sich um eine zielgerichtete Untersuchungsmethodik, die die Gedankengänge enthält, die ein erfahrener SRE instinktiv anwendet, aber selten aufschreibt. Sie erhalten dies, indem Sie Kibana auf dem neuesten Stand halten, da es in unsere KI-Agenten-Skills integriert ist. Es beginnt mit Leitprinzipien, die die häufigsten Fehldiagnosen verhindern:

• Das Fehlen von Beweisen ist kein Beweis. Wenn Log-Abfragen null Zeilen zurückgeben, melden Sie „no_logs_available“ – leiten Sie aus leeren Ergebnissen keinen Fehlermodus ab.
• OOMKilled deutet nicht standardmäßig auf ein Speicherleck hin. Vergleichen Sie die aktuelle Nutzung mit einer 7-Tage-Baseline, bevor Sie von einem Leck ausgehen. Das Limit ist möglicherweise einfach zu knapp bemessen.
• Durchschnittliche CPU-Metriken verbergen Drosselung. Ein Pod kann bei 40–60 % durchschnittlicher Auslastung unauffällig wirken, während er bei p99 stark gedrosselt wird. Betrachten Sie Max und p95, nicht nur den Durchschnitt.
• Begleitsymptome sind keine Ursachen. Zwei Dienste, die sich gleichzeitig verschlechtern, haben gewöhnlich eine gemeinsame vorgelagerte Ursache. Gehen Sie nur dann von einem Kausalzusammenhang aus, wenn die Beeinträchtigung eines Dienstes der des anderen eindeutig vorausgeht und das Delta groß ist.

Von dort aus bildet der Skill eine Fehlermodus-Taxonomie ab, die 16 verschiedene K8s-Fehlermuster über Workload-, Knoten-, control-plane-, Autoscaling- und Netzwerkebenen hinweg abdeckt – von OOMKilled und CFS-Drosselung über Admission-Webhook-Blockaden bis hin zu StatefulSet-Split-Brain. Jeder Modus verfügt über ein ausschlaggebendes Signal, das ihn identifiziert, und eine Prüfliste zur Bestätigung, die ihn verifiziert.

Der Untersuchungsablauf folgt einem strukturierten Bogen: Orientieren (Ziel-Pod, Namespace, Deployment ermitteln), Charakterisieren (Anzahl der Neustarts, Beendigungsgründe, Auslastung abrufen), Klassifizieren (mit der Taxonomie abgleichen), Untermauern (Ereignisse, Logs, APM, Baseline-Vergleiche heranziehen) und Synthetisieren (eine Hypothese zur Grundursache mit kalibriertem Konfidenzniveau – hoch, mittel oder niedrig – mit expliziten Belegen und empfohlenen nächsten Schritten erstellen).

Wenn zwei Fehlermodi zu den Belegen passen, nennt der Skill beide und gibt an, welcher seiner Ansicht nach ursächlich ist und warum. Wenn die Beweislage uneindeutig ist, wird dies angegeben. „Konkurrierende Hypothesen sind eine gültige Ausgabe“ ist ein ausdrückliches Designprinzip – das Erzeugen falscher Gewissheit wird als Fehlermodus der Untersuchung selbst behandelt.

Erste Schritte

Diese Funktionen bauen auf der in Teil 1 beschriebenen Kubernetes-Integration auf. Sobald Dashboards und die Datenerfassung laufen:

Schritt 1 – Untersuchungs-Workflows aktivieren (technische Vorschau). Importieren Sie den Kubernetes Crashloop Investigation Workflow von der Workflows-Seite in Kibana und konfigurieren Sie ihn optional so, dass er bei einer Alert-Regel ausgelöst wird.

Schritt 2 – Installieren Sie die MCP-App auf einem MCP-kompatiblen Client (technische Vorschau). Das Repository der MCP-App für Observability finden Sie auf GitHub. (Downloads finden Sie auf der Seite „Versionen“.) Vergessen Sie bei der Installation der App nicht, auch die enthaltenen Skills zu installieren und zu aktivieren. Greifen Sie über Ihren bevorzugten agentischen Client auf die Tools der Beispiel-MCP-App zu – Anweisungen finden Sie in der README unter dem obigen GitHub-Link.

Schritt 3 – Nutzen Sie den K8s-Investigation-Skill (technische Vorschau). Dieser ist praktisch inklusive, wenn Sie Agent Builder verwenden, da er bereits in KI-Agent-Skills integriert ist. Der Skill bringt dem Agenten bei, wann und wie die zugrunde liegenden Tools und Workflows aufgerufen werden sollen, und stellt so konsistente Diagnosen in Konversationskontexten sicher.

Was kommt als Nächstes?

Untersuchungs-Workflows diagnostizieren, was in den von Ihnen überwachten Diensten fehlerhaft ist. Die nächste Frage ist schwieriger: was ist mit den Diensten, die Sie nicht überwachen?

Wir denken über eine topologiebewusste Coverage Intelligence nach – das automatische Erkennen jedes in Ihrem Cluster bereitgestellten Workloads über die Kubernetes-API, der Abgleich mit in Elastic einfließenden Telemetriedaten und das Aufdecken von Lücken. „Sie haben 47 Services. 11 verfügen über keine verteilten Traces. Hier ist Ihr riskantester toter Winkel.“ Diese Funktion wird derzeit geprüft und wird voraussichtlich Gegenstand eines zukünftigen Blogbeitrags sein.

Parallel dazu erweitern wir Workflows in Richtung Problembehebung – nicht nur Diagnose, sondern Handeln: Erstellen eines Tickets mit angehängter Untersuchungszusammenfassung, Vorschlagen eines Rollbacks zur menschlichen Freigabe oder Skalieren eines Workloads, um Zeit zu gewinnen, während die Ursache behoben wird.

Wenn Sie Kubernetes aktuell auf Elastic ausführen, teilen Sie uns mit, welche Untersuchungsschritte Sie bei jedem Vorfall manuell wiederholen, bei welchen Behebungsmaßnahmen Sie einem Workflow zutrauen würden, dass er sie vorschlägt, und welche MCP-Tools wir als Nächstes entwickeln sollten. Sie können hier an der Elastic-Community-Diskussion teilnehmen.