HolmesGPT: ein SRE-Agent für die Ursachensuche in Produktionsvorfällen
SRE Agent - CNCF Sandbox Project
Auf einen Blick
- Was ist das?
- HolmesGPT verbindet ein LLM mit Observability-Datenquellen und durchsucht sie in einer agentischen Schleife nach der Ursache eines Vorfalls. Der Nutzen steht und fällt mit der Qualität dieser Anbindungen, nicht mit dem Modell.
- Für wen ist es gedacht?
- Sinnvoll ist HolmesGPT für Teams, die bereits Observability-Daten und Alerts in Prometheus, Datadog, Kubernetes oder Jira halten und die Ursachensuche beschleunigen wollen, ohne eine neue Plattform einzuführen. Wer keine dieser Quellen angebunden hat oder keinen LLM-Provider betreiben darf, gewinnt nichts.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem HolmesGPT adressiert
Ein Produktionsvorfall beginnt selten mit einer klaren Fehlermeldung. Meist liegt eine Alert-Lawine vor, und die eigentliche Arbeit besteht darin, aus Metriken, Logs, Kubernetes-Events und Ticketverläufen eine Hypothese zu bilden. Diese Arbeit ist manuell, wiederholt sich und bindet genau die Personen, die den Vorfall auch beheben könnten. HolmesGPT setzt hier an: Ein Agent soll die angeschlossenen Observability-Quellen selbst abfragen, statt dass ein Mensch sie nacheinander im Dashboard öffnet. Die Zielgruppe sind SRE- und Plattform-Teams, die bereits Daten sammeln, aber deren Auswertung im Vorfall noch von Hand machen. Das Projekt ist laut README ein CNCF-Sandbox-Projekt, ursprünglich von Robusta.Dev erstellt, mit Beiträgen von Microsoft. Der Lizenztyp Apache-2.0 erlaubt kommerzielle Nutzung und Änderungen, ohne dass der Quellcode offengelegt werden muss.
Die agentische Schleife und warum die Toolsets der eigentliche Kern sind
Nach der Beschreibung im README arbeitet HolmesGPT mit einer agentischen Schleife: Das Modell entscheidet, welche Datenquelle es als Nächstes abfragt, wertet das Ergebnis aus und entscheidet erneut. Die Datenquellen heißen im Projekt toolsets. Sie sind der Kern des Systems, weil das Modell ohne sie nur raten könnte. Das README listet eine breite Auswahl an integrierten Toolsets: Prometheus, Grafana, Datadog, Kubernetes, Coralogix, Elasticsearch und OpenSearch, ArgoCD, Crossplane, Docker, AWS, Azure, GCP, AKS, Atlassian Rovo, Confluence, GitHub und GitLab. Ein Teil davon läuft über MCP, also über von den Anbietern gehostete Server, was erklärt, warum dieselbe Quelle teils doppelt auftaucht, etwa Confluence und Confluence (MCP). Für alles, was nicht in der Liste steht, verweist das Projekt auf benutzerdefinierte Toolsets und auf generische REST-API-Toolsets. Wer eine interne Plattform anbinden will, baut also einen eigenen Toolset, statt auf eine fertige Integration zu warten. Zwei technische Details sind für den Betrieb relevant und werden im README explizit als Feature genannt: serverseitige Filterung mit JSON-Tree-Traversal und Tool-Output-Transformatoren sollen große Antworten aus dem Kontextfenster heraushalten, und pro Tool gesetzte Speichergrenzen mit Streaming großer Ergebnisse auf die Platte sollen OOM-Kills beim Abfragen großer Datenmengen verhindern. Das sind keine Kosmetikpunkte. Ein Agent, der eine Logabfrage über mehrere Gigabyte ungefiltert in ein Kontextfenster lädt, scheitert nicht an der Modellqualität, sondern an der Datenmenge.
Betriebsarten: manuell ausgelöst oder als Operator im Cluster
HolmesGPT lässt sich auf zwei Arten betreiben. Im manuellen Modus wird eine Untersuchung angestoßen, wenn ein Mensch ein Problem bemerkt. Der Operator-Modus dreht das um: Laut README läuft HolmesGPT dabei im Hintergrund und meldet gefundene Probleme über Slack. Der Operator selbst läuft in Kubernetes, die Health Checks können aber laut README jede angeschlossene Datenquelle abfragen, also auch VMs, Cloud-Dienste, Datenbanken und SaaS-Plattformen. Zwei Arten von Prüfungen nennt die Dokumentation: Deployment verification, bei der eine Prüfung neben der Anwendung läuft und verifiziert, ob eine neue Version gesund ist, und Scheduled health checks für wiederkehrende Prüfungen. Über die GitHub-Integration kann der Agent laut README sogar Pull Requests für gefundene Probleme öffnen. Genau hier liegt die Grenze des Projekts: Der Agent darf nach einer Analyse handeln. Wer ihm Schreibzugriff auf Repositories oder Alerts gibt, sollte vorher festlegen, was er ohne menschliche Freigabe tun darf. Das README beschreibt die Funktion, nicht die Absicherung.
Installation und Konfiguration: was das Material hergibt
Das README verlinkt einen Abschnitt Installation, ohne die Befehle im Auszug zu nennen. Konkrete Installationskommandos lassen sich aus dem vorliegenden Material also nicht belegen. Belegbar sind die Konfigurationsflächen: Datenquellen werden über benannte Toolsets konfiguriert, und für jede gibt es eine eigene Dokumentationsseite unter holmesgpt.dev/data-sources/builtin-toolsets/. Für nicht abgedeckte Systeme existiert der Pfad holmesgpt.dev/data-sources/custom-toolsets/ und der REST-API-Toolset. Die Modellseite ist austauschbar: Das README nennt OpenAI, Anthropic, Azure, Bedrock und Gemini sowie einen Sammelverweis auf holmesgpt.dev/ai-providers/. Zwei Dinge folgen daraus. Erstens ist die Modellwahl kein Lock-in, sondern eine Konfigurationsfrage. Zweitens verschiebt sich der Aufwand vollständig auf die Toolsets: Ein Team ohne fertige Integration investiert in Schema, Authentifizierung und Filterregeln für die eigene Datenquelle. Wer die Installation plant, sollte mit dem Installationsabschnitt der Dokumentation beginnen und parallel prüfen, ob die eigene Datenquelle bereits als Toolset existiert.
Grenzen und Fälle, in denen HolmesGPT das falsche Werkzeug ist
Der Agent ersetzt keine Observability-Plattform. Er liest aus dem, was bereits vorhanden ist. Ein Team, das keine Metriken, Logs oder Alert-Quellen zentralisiert hat, kann HolmesGPT nicht sinnvoll betreiben, weil die Schleife ohne abfragbare Datenquelle leer läuft. Das README nennt ausdrücklich, dass kein Kubernetes erforderlich ist, was den Einsatzbereich öffnet, aber auch bedeutet, dass die Qualität der Antwort direkt von der Qualität der angebundenen Quellen abhängt. Ein zweiter Punkt ist die Kosten- und Betriebsseite: Jede Iteration der Schleife ist ein Modellaufruf, und der Operator-Modus läuft dauerhaft im Hintergrund. Das Material nennt keine Zahlen zu Laufzeit oder Token-Verbrauch, und ohne eigene Messung lässt sich dazu nichts Belastbares sagen. Drittens die Sicherheitsfrage: Der Agent erhält Zugriff auf Produktionsdaten, im Operator-Modus zusätzlich auf Slack und optional auf Repositories. Wer diese Zugriffe nicht auf das Nötige begrenzen kann, sollte den manuellen Modus wählen. Und schließlich: Für einen einzelnen, klar abgegrenzten Fehler in einer Anwendung mit einer bekannten Fehlermeldung ist ein Agent Overhead. Ein Blick in das Log ist schneller.
Alternative: Robusta oder ein generischer MCP-Client
Die naheliegende Alternative ist Robusta, das Ursprungsprojekt hinter HolmesGPT. Der Unterschied liegt im Ansatz: Robusta ist als Kubernetes-Monitoring und Alerting gebaut, mit festen Regeln und Regressionserkennung. HolmesGPT setzt statt auf vordefinierte Regeln auf ein Modell, das während der Untersuchung selbst entscheidet, welche Quelle es abfragt. Das ist flexibler bei unerwarteten Fehlerbildern und weniger vorhersagbar im Verhalten. Eine zweite Alternative sind generische MCP-Clients oder ein selbstgebauter LLM-Agent, der dieselben Datenquellen anspricht. Der Unterschied ist der Aufwand für die Anbindung: HolmesGPT bringt fertige Toolsets für Prometheus, Datadog, Kubernetes und andere mit, während ein generischer Client jedes Schema selbst kennen muss. Wer bereits einen Agenten mit eigenen Tools betreibt, gewinnt durch HolmesGPT vor allem die mitgelieferten Integrationen. Wer nur ein einzelnes System abfragen will, ist mit einem direkten API-Aufruf besser bedient.
Wartung, Versionen und Lizenz
Das Projekt veröffentlicht häufig: Die Release-Liste zeigt 0.41.0 vom 8. September 2026, davor 0.41.0-alpha vom 6. September und 0.40.0 vom 26. August. Der letzte Push auf master liegt bei 2026-09-09. Diese Kadenz bedeutet, dass Teams mit einer festen Version arbeiten und Upgrades bewusst planen sollten, statt dem master zu folgen. Alpha-Releases sind vor einem Produktionseinsatz zu meiden. Ein Kostenfaktor, der leicht übersehen wird, sind die Modellaufrufe: Sie skalieren mit der Anzahl der Untersuchungen und der Anzahl der Iterationen pro Untersuchung, nicht mit der Zahl der installierten Instanzen. Wie stark das ins Gewicht fällt, hängt vom gewählten Provider und der Konfiguration ab und lässt sich nur mit eigenen Messungen bestimmen. Zur Lizenz: Apache-2.0 erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber die Beibehaltung von Copyright- und Lizenzhinweisen und enthält eine ausdrückliche Patentgewährung. Eine Rechtsberatung ersetzt das nicht, besonders wenn das Projekt in ein Produkt eingebettet wird.
Redaktionelles Fazit
Sinnvoll ist HolmesGPT für Teams, die bereits Observability-Daten und Alerts in Prometheus, Datadog, Kubernetes oder Jira halten und die Ursachensuche beschleunigen wollen, ohne eine neue Plattform einzuführen. Wer keine dieser Quellen angebunden hat oder keinen LLM-Provider betreiben darf, gewinnt nichts. Vor dem Rollout zu klären ist, ob die benötigte Datenquelle als Toolset existiert oder über einen API-Toolset selbst gebaut werden muss, welche Berechtigungen der Agent in Kubernetes erhält und ob der Betrieb den Operator-Modus in Kubernetes oder nur den manuellen Aufruf per CLI vorsieht.
Community-Notizen