Wer Kubernetes betreibt, kennt die Situation: Ein Alert meldet CrashLoopBackOff, Pods starten ständig neu, und die Fehlerrate steigt. Die nötigen Informationen sind meist längst vorhanden – verteilt über Kubernetes-Events, Container-Logs, Metriken, Traces und die Historie der letzten Deployments. Am Mangel an Daten scheitert es selten. Aufwendig ist es, diese Daten zusammenzuführen, zeitlich einzuordnen und gegen mögliche Ursachen zu prüfen.

Gerade bei komplexeren Plattformen springen Administratoren dabei zwischen mehreren Werkzeugen hin und her. Sie prüfen den Pod-Status, lesen Logs, vergleichen Konfigurationen, suchen nach Änderungen im Git-Repository und gleichen Metriken mit dem Zeitpunkt eines Rollouts ab. Jeder einzelne Schritt ist für sich genommen bekannt, Zeit kostet vor allem die Verknüpfung der einzelnen Hinweise. Unter Druck steigt zudem das Risiko, sich zu früh auf eine plausible Ursache festzulegen und andere Spuren zu übersehen. HolmesGPT [1] setzt genau an dieser Stelle an. Der Open-Source-SRE-Agent greift auf Kubernetes-, Monitoring-, Logging- und weitere Betriebsdaten zu, führt selbstständig Abfragen aus und verdichtet die Ergebnisse schrittweise zu einer technischen Diagnose. Dafür erhält das zugrunde liegende Sprachmodell Werkzeuge, mit denen es die Umgebung aktiv untersucht: Es ruft Events und Logs ab, prüft auffällige Metriken oder sucht nach Änderungen, die kurz vor dem Incident ausgerollt wurden.

Damit verschiebt sich der Einsatz von KI im Betrieb weg von einfachen Chatoberflächen hin zu einer konkreten Untersuchungslogik. Interessant ist dabei weniger, ob HolmesGPT eine überzeugend klingende Antwort formuliert – entscheidend ist, ob die Analyse nachvollziehbar bleibt, die richtigen Datenquellen einbezieht und belastbare Belege für die vermutete Ursache liefert. Unser Workshop zeigt anhand eines konkreten Fehlerszenarios, wie HolmesGPT aufgebaut ist, welche Datenquellen und Berechtigungen der Agent benötigt und wo die Grenzen im produktiven Einsatz liegen.

HolmesGPT ist ein quelloffener Agent für die Untersuchung technischer Störungen. Das Projekt entstand im Umfeld der Observability-Plattform Robusta; die Cloud Native Computing Foundation nahm es im Oktober 2025 als Sandbox-Projekt auf. Der Status zeigt, dass HolmesGPT im Cloud-Native-Umfeld angekommen ist, markiert aber weiterhin eine frühe Entwicklungsstufe. Im Kern verbindet HolmesGPT ein Sprachmodell mit Werkzeugen für den Zugriff auf Betriebsdaten: Der Agent ruft während einer Analyse weitere Informationen aus der Umgebung ab, liest etwa einen Alert, prüft betroffene Kubernetes-Ressourcen und wertet anschließend Logs oder Metriken aus. Die gefundenen Hinweise bestimmen jeweils den nächsten Schritt.

Den Zugriff auf externe Systeme regeln sogenannte Toolsets. Sie binden unter anderem Kubernetes, Prometheus, Loki, Tempo, Grafana, Argo CD, GitHub, Cloud-Plattformen und Datenbanken an. Auch interne Dokumentationen lassen sich einbeziehen.

HolmesGPT ersetzt dabei keine Observability-Plattform. Prometheus sammelt weiterhin Metriken, Loki speichert Logs, und Kubernetes liefert den Zustand der Workloads. Der Agent greift auf diese Quellen zu, verbindet die Informationen und erstellt daraus eine begründete Diagnose. Der Agent lässt sich über die Kommandozeile, als Dienst im Kubernetes-Cluster oder über das Python-Paket in eigene Anwendungen einbinden. Die Qualität der Ergebnisse hängt dabei stark von den verfügbaren Daten und vom eingesetzten Sprachmodell ab.

Eine Untersuchung beginnt mit einer Frage, einem Alert oder einem Aufruf über das HTTP-API. HolmesGPT übergibt den verfügbaren Kontext zusammen mit den freigeschalteten Werkzeugen an das Sprachmodell. Dazu gehören beispielsweise der betroffene Namespace, die Alert-Beschreibung und Hinweise auf auffällige Ressourcen. Das Modell entscheidet anschließend, welche Informationen für die Analyse noch fehlen.

Benötigt HolmesGPT weitere Daten, wählt der Agent ein passendes Werkzeug aus. Steigt etwa nach einem Rollout die Fehlerrate eines Dienstes, ruft er zunächst die betroffenen Pods und deren Zustand ab. Zeigen die Logs keine eindeutige Ursache, prüft er im nächsten Schritt möglicherweise die Latenz- und Fehlermetriken im zeitlichen Umfeld des Deployments. Fällt der Anstieg mit einem neuen Rollout zusammen, folgt als weiterer Schritt der Vergleich mit der Vorversion. Jeder Fund verändert damit den weiteren Untersuchungsweg.

Technisch entsteht eine Schleife aus Modell- und Werkzeugaufrufen: Das Sprachmodell formuliert eine Abfrage, HolmesGPT führt sie über das entsprechende Toolset aus und liefert das Ergebnis zurück. Dieser Vorgang wiederholt sich, bis der Agent genügend Hinweise für eine Diagnose gesammelt hat oder keine weitere sinnvolle Abfrage mehr findet. Die integrierte OpenTelemetry-Unterstützung bildet diesen Ablauf ebenfalls ab: In einem Trace wechseln sich LLM-Iterationen und Tool-Aufrufe bis zur abschließenden Antwort ab.

Die Toolsets stellen dabei die Verbindung zu den tatsächlichen Systemen her. Für Kubernetes steht standardmäßig ein lesender Zugriff über kubectl bereit, weitere Integrationen binden zusätzliche Plattformen über eigene Toolsets an. Auch individuelle Umgebungen lassen sich über benutzerdefinierte Toolsets, HTTP-APIs oder MCP-Server ergänzen. Der Agent kann ausschließlich die Werkzeuge nutzen, die in seiner Konfiguration aktiviert sind – die Rechte richten sich dabei weiterhin nach den hinterlegten Zugangsdaten und Service-Accounts.

Am Ende fasst HolmesGPT die vermutete Ursache, die gefundenen Belege und mögliche Schritte zur Behebung zusammen. Eine überzeugend formulierte Antwort reicht dabei nicht aus: Für den praktischen Einsatz muss erkennbar bleiben, welche Logs, Events oder Metriken die Diagnose stützen. Gerade diese Beweiskette entscheidet später darüber, ob ein Administrator die Empfehlung übernehmen kann oder die Untersuchung manuell fortsetzen muss.

HolmesGPT lässt sich lokal über die Kommandozeile oder zentral als Dienst betreiben. Für einzelne Analysen reicht die CLI aus. Soll der Agent später über eine Oberfläche, einen Chatbot oder eine eigene Anwendung erreichbar sein, bietet sich die Installation per Helm an: Dabei läuft HolmesGPT im Kubernetes-Cluster und stellt ein HTTP-API bereit. Die Projektdokumentation [2] empfiehlt diesen Weg vor allem für eigene Integrationen.

Für die Installation sind ein Kubernetes-Cluster, Helm, ein konfigurierter kubectl-Zugriff und die Zugangsdaten zu einem unterstützten Modellanbieter erforderlich. Zuerst binden Administratoren das Helm-Repository ein:

Die Modellkonfiguration liegt in der Datei "values.yaml". API-Schlüssel gehören dabei in ein Kubernetes Secret und sollten nicht direkt in der Helm-Datei stehen; das Chart bindet die Schlüssel als Umgebungsvariablen in den HolmesGPT-Pod ein. Das folgende Beispiel nutzt ein OpenAI-Modell:

Die zugehörige Datei "values.yaml" fällt für den ersten Test überschaubar aus:

Mit "reasoning_effort" lässt sich steuern, wie viel Rechenaufwand das Modell in die Analyse investiert. Für den Einstieg ist "medium" ein brauchbarer Ausgangspunkt, bei schwierigen Incidents kann der Wert später auf "high" steigen. HolmesGPT verwaltet Modelle über modelList und nutzt den dort vergebenen Namen auch bei Aufrufen der HTTP-API.

Für den Praxistest kommt ein absichtlich fehlerhaftes Deployment zum Einsatz. Der Checkout-Service erwartet die Umgebungsvariable DB_HOST, die zugehörige ConfigMap stellt den Wert jedoch unter dem Namen "DATABASE_HOST" bereit. Der Container startet, erkennt die fehlende Variable und beendet sich mit Exit-Code "1". Kubernetes versucht daraufhin, den Pod immer wieder neu zu starten. Das Manifest im Listing-Kasten legt einen eigenen Namespace, die ConfigMap und das fehlerhafte Deployment an.

Nach dem Einspielen des Manifests erscheint der Pod nach kurzer Zeit im Status "CrashLoopBackOff". Anschließend erhält HolmesGPT nur den Namen des Workloads und den betroffenen Namespace:

Der genaue Untersuchungsweg hängt vom eingesetzten Modell ab. Im ersten Schritt ermittelt HolmesGPT üblicherweise den Pod und das zugehörige Deployment. Der Pod-Status zeigt die wiederholten Neustarts und den fehlgeschlagenen Container-Start, danach führen die vorherigen Container-Logs zu einem ersten konkreten Hinweis: "DB_HOST is not set". Diese Meldung erklärt den Absturz, reicht für eine vollständige Ursachenanalyse aber noch nicht aus. HolmesGPT muss zusätzlich prüfen, wie das Deployment seine Umgebungsvariablen bezieht, und findet dabei die über envFrom eingebundene ConfigMap "checkout-config". Darin ist ausschließlich "DATABASE_HOST" hinterlegt – der erwartete Schlüssel "DB_HOST" fehlt.

Eine brauchbare Diagnose nennt daher den Konfigurationsfehler und führt die zugehörigen Belege auf: den Status "CrashLoopBackOff", den Exit-Code des Containers, die Meldung aus den vorherigen Logs sowie den abweichenden Schlüssel in der ConfigMap. Gibt HolmesGPT lediglich die Logmeldung wieder, bleibt die Analyse zu oberflächlich. Die eigentliche Ursache ergibt sich erst aus der Abweichung zwischen Anwendungserwartung und bereitgestellter Konfiguration:

Der Test ist bewusst überschaubar gehalten, zeigt aber dennoch den zentralen Ablauf einer HolmesGPT-Untersuchung: Der Agent beginnt mit einem sichtbaren Symptom, ruft weitere Daten ab und folgt den Hinweisen bis zur fehlerhaften Konfiguration. Damit lässt sich gut prüfen, ob das eingesetzte Modell Werkzeuge sinnvoll auswählt und seine Diagnose mit konkreten Fundstellen belegt.

Die bisherige Analyse stützt sich auf allgemeines Kubernetes-Wissen des Modells und die Daten im Cluster. In realen Umgebungen kommen eigene Namenskonventionen, Abhängigkeiten und Zuständigkeiten hinzu. HolmesGPT kann dieses Wissen über Skills einbeziehen.

Skills bündeln wiederverwendbares Wissen und feste Arbeitsabläufe für KI-Agenten. Grundlage ist eine Datei namens "SKILL.md" (im Singular): Sie enthält YAML-Metadaten wie "name" und "description" sowie die eigentlichen Anweisungen in Markdown. Optional können Skripte, Vorlagen und Referenzdateien im selben Verzeichnis liegen. Dieses offene Agent-Skills-Format erleichtert die Versionierung und Wiederverwendung über verschiedene kompatible Systeme hinweg. Skills laden erst dann in den Kontext, wenn eine Anwendung sie tatsächlich benötigt – so bleibt der Kontext schlank und spart Token sowie damit einhergehend Kosten.

Anhand der Beschreibung im "SKILL.md"-Header entscheidet der Agent, welche Anleitung zu einer Anfrage passt. Anschließend lädt er den Skill und führt die hinterlegten Prüfschritte mit den freigeschalteten Toolsets aus. Für den Checkout-Service lässt sich der Ablauf direkt in der values.yaml–Datei hinterlegen:

Die Beschreibung sollte das Fehlerbild klar eingrenzen, da HolmesGPT darüber die Auswahl trifft. Die einzelnen Schritte dürfen konkrete Eigenheiten der Umgebung enthalten, etwa bekannte Abhängigkeiten, interne Dashboards oder das zuständige Team. Für erste Tests reicht die Ablage in der Helm-Konfiguration, bei mehreren Skills bietet sich hingegen ein Git-Repository an, damit Änderungen versioniert und geprüft werden können. HolmesGPT kann die Dateien auch aus ConfigMaps oder gemounteten Verzeichnissen laden. Der Zugriff auf die beschriebenen Systeme bleibt dabei über Toolsets, Service-Accounts und deren Berechtigungen geregelt.

Der bisherige Praxistest arbeitet mit Kubernetes-Ressourcen und den direkt am Pod verfügbaren Logs. Für viele Störungen reicht das nur bis zu einem gewissen Punkt. Nach dem Austausch eines Pods sind ältere Logs möglicherweise nicht mehr vorhanden, Lastspitzen, steigende Fehlerraten oder schleichender Ressourcenverbrauch werden erst über Metriken sichtbar. Liegt die Ursache außerhalb des Clusters, fehlen zudem Informationen zur zugrunde liegenden Cloudinfrastruktur.

HolmesGPT stellt für solche Systeme eigene Toolsets bereit. Prometheus liefert TimeSeries und Alert-Regeln, Loki macht historische Logs durchsuchbar. Weitere Integrationen decken unter anderem Tempo, Elasticsearch, Datadog und New Relic ab. Mehrere Logging-Quellen können parallel aktiv sein – HolmesGPT wählt während der Untersuchung die Quelle aus, die zum jeweiligen Problem passt.

Für Azure nutzt HolmesGPT einen eigenen MCP-Server. Dieser läuft bei einer Helm-Installation als zusätzlicher Pod und greift über die Azure-APIs auf freigegebene Ressourcen zu, darunter etwa virtuelle Maschinen, AKS, Azure SQL, Activity Logs, Azure Monitor, Netzwerke und Storage. So lässt sich jederzeit auch die zugrunde liegende Cluster-Technik oder -Konfiguration einsehen oder Umsysteme als Fehlerquelle identifizieren.

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen externe Systeme einheitlich anbinden – weshalb der Vergleich mit USB-C für KI-Systeme in der Praxis häufig fällt. Ein MCP-Server stellt dafür Werkzeuge, Datenquellen oder vorgefertigte Prompts bereit. HolmesGPT kann diese Funktionen während einer Untersuchung aufrufen, etwa um Azure-Ressourcen, Datenbanken oder interne APIs abzufragen. Das folgende Beispiel erweitert die bisherige "values.yaml" um Prometheus, eine direkte Loki-Verbindung und den Azure-MCP-Server. Für Azure geht es von einem AKS-Cluster mit aktivierter Workload Identity aus:

Prometheus und Loki werden unter "toolsets" konfiguriert, der Azure-Zugriff liegt getrennt unter "mcpAddons", da das Helm Chart dafür einen eigenen MCP-Server bereitstellt. Bei einem mandantenfähigen Loki kommt zusätzlich der Header "X-Scope-OrgID" hinzu. Alternativ kann HolmesGPT Loki über den Grafana-Datasource-Proxy ansprechen – dieser Weg erleichtert die Authentifizierung und ermöglicht direkte Verweise auf passende Ansichten in Grafana.

Die Azure-Identität sollte mindestens die Rolle "Reader" auf dem benötigten Scope erhalten. Für Abfragen in Azure Monitor und Log Analytics sind je nach Einsatz zusätzlich Monitoring Reader und Log Analytics Reader erforderlich. Die Rollen müssen dabei nicht auf der gesamten Subskription liegen – eine Beschränkung auf eine Resource Group oder einzelne Ressourcen hält den Zugriff überschaubar.

Eigene Plattformen lassen sich über HTTP-Connectoren, benutzerdefinierte Toolsets und externe MCP-Server ergänzen. Bei neuen MCP-Anbindungen empfiehlt HolmesGPT den Transport streamable-http, der frühere SSE-Transport gilt inzwischen als veraltet. Jede weitere Datenquelle erhöht den verfügbaren Kontext, erweitert aber auch die Zahl möglicher Werkzeugaufrufe. Schlecht beschriebene Tools und sehr breite Zugriffsrechte können die Analyse unnötig verlängern. Für den Einstieg ist eine kleine Auswahl aus Kubernetes, Metriken, zentralen Logs und der tatsächlich verwendeten Cloudplattform meist ausreichend.

HolmesGPT zeigt, wie sich KI im Betrieb sinnvoll einsetzen lässt. Der Agent greift auf vorhandene Datenquellen zu, verfolgt Hinweise über mehrere Systeme hinweg und fasst die Ergebnisse zu einer technischen Diagnose zusammen. Im Praxistest reicht bereits der lesende Zugriff auf Kubernetes-Ressourcen und Container-Logs aus, um den fehlerhaften Checkout-Service bis zur falsch benannten Umgebungsvariable zurückzuverfolgen. Wie gut das in der Praxis funktioniert, hängt jedoch stark von der Umgebung ab: Fehlen historische Logs, Metriken oder Informationen zu Änderungen, bleibt auch die Analyse lückenhaft. Mit Prometheus, Loki und dem Azure-MCP-Server lässt sich der Kontext erweitern, Skills ergänzen dieses technische Bild um internes Betriebswissen, bekannte Fehlerbilder und feste Prüfabläufe – gerade diese Informationen entscheiden oft darüber, ob HolmesGPT nur eine plausible Vermutung liefert oder eine Ursache sauber belegt.

Auch KI-skeptische Teams können den Einstieg vergleichsweise nüchtern angehen. HolmesGPT lässt sich zwar so erweitern, dass es Änderungen ausführt oder Fehler selbst behebt, für den Anfang ist das jedoch nicht nötig: Mit rein lesenden Berechtigungen bleibt der Agent ein weiteres Werkzeug für Debugging und Ursachenanalyse, dessen Trefferquote und typische Schwächen sich über einen längeren Zeitraum im Abgleich mit den eigenen Untersuchungen realistisch einschätzen lassen. Im Blick behalten sollten Teams dabei die Kosten: Jede Untersuchung bedeutet Modellaufrufe, die sich je nach eingesetztem Modell summieren – besonders dann, wenn HolmesGPT nicht nur über Chat oder gezielte Nachfragen, sondern automatisiert durch Alerts ausgelöst wird. Bei einem echten Incident ist der Preis einer Analyse zweitrangig, unnötiges Grundrauschen durch häufig triggernde Automatismen lässt sich aber durch ein durchdachtes Trigger-Konzept, saubere Budgetkontrolle und ein zentrales Gateway wie LiteLLM vermeiden.

HolmesGPT ersetzt weder Monitoring noch Logging oder erfahrene Administratoren, kann die erste Analyse eines Incidents jedoch deutlich beschleunigen und die oft mühsame Suche über mehrere Systeme hinweg bündeln. Besonders sinnvoll ist der Einsatz dort, wo bereits gute Observability-Daten vorhanden sind und Teams ihr Betriebswissen strukturiert hinterlegen – dann wird der Agent zu einem brauchbaren zusätzlichen Werkzeug für die tägliche Fehlersuche.

(dr)