Obseria Intelligence 3.0: Agentische Root-Cause-Analyse mit Evidenz

Als wir 2022 die erste Version von Obseria Intelligence veröffentlicht haben, war das Versprechen einfach: keine Alarmflut mehr, sondern eine Antwort auf die Frage, warum ein System sich gerade so verhält. Die kausale Analyse auf Basis der automatisch erkannten Topologie hat dieses Versprechen für tausende Teams eingelöst. Aber sie hatte eine Grenze: Sie lieferte einen Bericht, und die Untersuchung endete dort.

Mit Obseria Intelligence 3.0 ändern wir das. Die Root-Cause-Analyse wird zu einer Untersuchung, die ein Agent eigenständig führt, dokumentiert und mit einer Beweiskette abschließt. In diesem Beitrag zeigen wir, was dahintersteckt, wie das in der Praxis aussieht und warum wir Erklärbarkeit nicht verhandelbar gemacht haben.

Warum Korrelation nicht reicht

Die meisten „KI-gestützten“ Analysen in Observability-Tools sind Korrelationen: Metrik A steigt, Metrik B steigt, also hängen sie zusammen. In verteilten Systemen ist das selten die ganze Wahrheit. Wenn der Checkout-Service langsam wird, steigen gleichzeitig die Latenzen von zwölf Diensten, die ihn aufrufen, und die Fehlerraten von drei Diensten, die er selbst aufruft. Alle Kurven sehen gleich aus. Welche ist die Ursache?

Obseria Intelligence beantwortet das über Kausalität statt Statistik. Obseria TopoGraph kennt die Aufrufketten, Prozesse, Hosts und Cloud-Ressourcen. Entlang dieses Graphen lässt sich eine Hypothese prüfen: Kann eine Änderung an Knoten X die beobachteten Symptome an Knoten Y, Z erzeugen? Und gab es an X tatsächlich eine Änderung, etwa ein Deployment, eine Konfiguration, einen Ressourcenengpass?

Was „agentisch“ hier konkret bedeutet

In Version 3.0 übernimmt ein Untersuchungs-Agent den Ablauf, den ein erfahrener SRE bei einem Incident durchläuft, nur in Sekunden statt in Stunden:

1. Eingrenzen. Aus dem Problem-Kontext (betroffene Services, Zeitfenster, Symptome) bildet der Agent kausale Hypothesen entlang des Topologie-Graphen.
2. Prüfen. Für jede Hypothese fragt er gezielt Telemetrie ab: Deployment-Events, Ressourcen-Metriken, Fehler-Logs, Trace-Spans. Nicht alles, sondern genau das, was die Hypothese belegen oder widerlegen würde.
3. Verwerfen. Hypothesen ohne Beleg werden fallen gelassen und als geprüft dokumentiert, damit niemand sie im Incident-Call erneut untersucht.
4. Erklären. Die verbleibende Ursache wird mit einer Beweiskette beschrieben, die jeden Schritt mit einem Link auf die zugrunde liegenden Daten belegt.
5. Vorschlagen. Passt die Ursache zu einem bekannten Muster, schlägt der Agent einen Fix vor und simuliert ihn gegen die betroffenen SLOs.

Der entscheidende Unterschied zu einem Chatbot über Ihren Daten: Der Agent darf nichts behaupten, was er nicht mit einer Abfrage belegen kann. Jede Aussage im Bericht ist ein Link.

Eine Beweiskette aus der Praxis

So sieht ein Ergebnis aus, wie es ein Pilotkunde aus dem Einzelhandel in der vergangenen Woche erhalten hat. Die Zeiten sind echt, die Namen anonymisiert:

Was hier nicht steht, ist genauso wichtig: keine Wahrscheinlichkeitsangabe ohne Grundlage, keine Liste von zwanzig „möglicherweise verwandten“ Alarmen. Drei verworfene Hypothesen, eine belegte Ursache, ein simulierter Fix.

Fragen in natürlicher Sprache, Antworten mit Abfragen

Der Untersuchungs-Agent ist auch interaktiv. Sie können nachfragen, und die Antwort kommt mit der Abfrage, die sie erzeugt hat. Die Frage „Welche Kunden waren betroffen?“ erzeugt beispielsweise diese Obseria Query Language (OQL):

fetch spans
| filter service.name == "checkout-svc" and status == "ERROR"
| filter start_time >= "2026-10-05T14:32:00Z" and start_time < "2026-10-05T14:47:00Z"
| summarize orders = count_distinct(order.id), customers = count_distinct(customer.segment), by: {customer.segment}
| sort orders desc

Die Abfrage läuft unter den Rechten des fragenden Nutzers. Wer die Kundensegment-Spalte nicht sehen darf, bekommt sie auch vom Agenten nicht.

Guardrails und Governance

Agenten, die in Produktionssysteme eingreifen, brauchen klare Grenzen. Drei Prinzipien haben wir in 3.0 fest eingebaut:

• Lesen ja, handeln nur mit Policy. Untersuchen darf der Agent immer. Jede Aktion (Rollback, Skalierung, Ticket) läuft über Obseria Automation mit Freigabe-Regeln pro Umgebung, Service und Zeitfenster.
• Vollständiger Audit-Trail. Jede Abfrage, jede verworfene Hypothese und jede vorgeschlagene Aktion wird protokolliert und ist Teil des Incident-Berichts.
• Keine Daten für Modelltraining. Kundendaten verlassen die gewählte Region nicht und werden nicht zum Training verwendet, auch nicht anonymisiert.

Verfügbarkeit und nächste Schritte

Obseria Intelligence 3.0 ist ab heute für alle Pro- und Enterprise-Kunden in den Regionen EU und UK verfügbar und wird in den kommenden zwei Wochen für Testaccounts freigeschaltet. Bestehende Root-Cause-Berichte bleiben unverändert; die agentische Untersuchung erscheint als neuer Abschnitt in jedem Problem.

Wenn Sie den Untersuchungs-Agenten mit eigenen Agenten oder Assistenten kombinieren möchten: Der MCP-Server und die CLI stellen dieselben Untersuchungsfunktionen bereit. Die Dokumentation beschreibt, wie Sie eigene Hypothesen-Quellen, etwa Change-Management-Systeme, als Evidenz anbinden.