OpenSRE: KI-Agenten für Incident Response — wenn Alerts automatisch untersucht werden

OpenSRE von Tracer Cloud untersucht Produktionsalerts automatisch — Logs, Metriken, Runbooks — und liefert einen strukturierten Root-Cause-Report, bevor jemand das PagerDuty-Alert öffnet.

Teil 5 dieser Serie beschrieb, warum KI-Agenten eine Observability-Schicht brauchen — und warum Telegraf als klassischer Daten-Agent diese Schicht bereitstellt. Jetzt geht es um die nächste Frage: Was passiert, wenn ein KI-Agent tatsächlich auf diese Daten schaut — nicht nur Metriken schreibt, sondern selbst ermittelt, warum etwas kaputt ist?

GitHub: Tracer-Cloud/opensre — ~5.4k ⭐, 688 Forks (Mai 2026, Public Alpha)

Das Problem, das OpenSRE löst

Wenn etwas in Produktion bricht, sind die Beweise verstreut: Logs in Grafana, Metriken in Datadog, Runbooks in Confluence, vergangene Incidents in Jira, aktuelle Slack-Threads im Engineering-Kanal. Ein erfahrener SRE verbringt bei einem Incident die ersten zwanzig Minuten damit, dieses Bild zusammenzusetzen — bevor die eigentliche Diagnose beginnt.

Das ist teuer, fehleranfällig und skaliert nicht. Wer mehr Services betreibt, hat mehr Incidents, braucht mehr SREs. Das Verhältnis ist ungefähr linear — bis KI dazwischentritt.

OpenSRE stellt die These auf: Wenn SWE-bench Coding-Agenten geholfen hat, weil es skalierbare Trainingsdaten und klares Feedback lieferte, dann fehlt der SRE-Welt genau dieses Äquivalent. Produktionsvorfälle sind langsamer, verrauschter und schwerer zu simulieren als lokale Code-Aufgaben. Genau deshalb sind KI-Agenten für Infrastruktur-Debugging noch ungelöst — nicht weil die Modelle schlecht sind, sondern weil die Trainings- und Evaluationsinfrastruktur fehlt.

OpenSRE baut beides gleichzeitig: einsatzfähige SRE-Agenten und den Benchmark-Unterbau, der sie verbessert.

Wie ein Investigation-Agent vorgeht

Wenn ein Alert auslöst, arbeitet OpenSRE einen definierten Ablauf ab.

Beispiel: Ein Alert meldet steigende Latenz in einem API-Service. Der Agent korreliert erhöhte 5xx-Raten in Grafana mit einem Spike im Kafka-Consumer-Lag, findet im Runbook einen bekannten Zusammenhang und identifiziert eine blockierende Downstream-Datenbankverbindung als wahrscheinlichste Ursache.

Der Ablauf dahinter:

1. Fetch: Alert-Kontext holen, korrelierte Logs, Metriken und Traces abrufen
2. Reason: Anomalien korrelieren — zeitliche Übereinstimmungen, Kausalpfade, bekannte Runbook-Muster
3. Report: Strukturierten Investigation-Report mit wahrscheinlichem Root Cause generieren
4. Act: Nächste Schritte vorschlagen — und optional Remediation-Aktionen ausführen (z. B. Restart, Rollback, Scaling)
5. Communicate: Summary direkt in Slack oder PagerDuty posten

Der Agent liest dabei keine rohen Prometheus-Metriken und versucht zu raten. Er liest Runbooks — die strukturierten Wissensdokumente des SRE-Teams — und wendet sie an. Das ist Context Engineering in der Praxis — nicht das Modell entscheidet, sondern der bereitgestellte Kontext: Ein Runbook, das beschreibt, wie ein Datenbankverbindungspool überläuft und wie man das eingrenzt, macht den Agenten zuverlässiger als ein besseres Modell ohne dieses Wissen.

# Installation
curl -fsSL https://install.opensre.com | bash

# Onboarding (Integrationen konfigurieren)
opensre onboard

# Einmalige Investigation gegen ein Alert-File
opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json

# Interaktive Shell
opensre

Im interaktiven Modus beschreibt man den Incident auf Deutsch oder Englisch — der Agent stellt Rückfragen, streamet die Investigation live und liefert einen strukturierten Bericht.

60+ Integrationen — und warum das zählt

Ein SRE-Agent, der nur eine Datenquelle sieht, ist begrenzt. OpenSRE verbindet sich mit dem Stack, der in der Praxis läuft:

Observability: Grafana (Loki, Mimir, Tempo), Datadog, CloudWatch, Honeycomb, Sentry, Elasticsearch, Better Stack

Infrastruktur: Kubernetes, AWS (EKS, EC2, Lambda, S3, ECS Fargate), GCP, Azure

Datenbanken: PostgreSQL, MySQL, MongoDB, ClickHouse, Snowflake, MariaDB

Datenplattformen: Apache Kafka, Apache Airflow, Spark, Prefect, RabbitMQ

Incident Management: PagerDuty, Opsgenie, Jira, Alertmanager

Kommunikation: Slack, Discord, Telegram, Google Docs

Protokolle: MCP, ACP, OpenClaw (ein weiteres Tool-Aufruf-Protokoll) — der Agent kann also selbst wieder Tools aufrufen

Die Breite ist kein Selbstzweck. Ein echter Produktionsvorfall betrifft selten nur eine Schicht: Ein Kubernetes-Pod crasht, weil eine Datenbankverbindung fehlschlägt, weil ein Kafka-Consumer-Lag explodiert, weil ein Upstream-Service hängt. Wer nur Kubernetes sieht, findet den Pod. Wer alle Schichten sieht, findet den Root Cause.

Modell-Flexibilität: Anthropic, OpenAI, Ollama (lokal), Google Gemini, OpenRouter, NVIDIA NIM, Bedrock. Wer keine Cloud-APIs nutzen will oder Datenschutzanforderungen hat, kann Ollama mit einem lokalen Modell betreiben.

Der Benchmark-Ansatz: synthetische Incidents als Trainingsgrundlage

Das methodisch interessanteste an OpenSRE ist nicht die Agent-Architektur selbst, sondern der Benchmark-Unterbau.

Das Projekt führt zwei Testebenen parallel:

Synthetische RCA-Suites — kontrollierte Szenarien mit bekanntem Root Cause, Red Herrings (ablenkenden Falschwegen) und definierten Beweispfaden. Das Ziel ist nicht, ob der Agent das Problem löst, sondern ob er die richtigen Beweise gefunden und die richtigen Schlüsse gezogen hat — bewertbar, reproduzierbar, automatisiert.

End-to-End-Tests — reale Cloud-Szenarien: Kubernetes, EC2, CloudWatch, Lambda, ECS Fargate, Apache Flink. Kein Mock, kein Simulator — echter Infrastruktur-Stack, echter Agent-Lauf, gemessene Outcomes.

Ohne solche Benchmarks bleiben SRE-Agenten schwer vergleichbar — jede Demo funktioniert, aber niemand weiß, ob sie im echten Incident robust ist. Die Analogie zu SWE-bench ist präzise: SWE-bench lieferte Coding-Agenten eine Sammlung realer GitHub-Issues mit messbarem Erfolg (PR gemergt oder nicht). OpenSRE versucht dasselbe für Infrastruktur-Incidents: Wie viele Root Causes findet der Agent korrekt? Wie viele erforderliche Beweise sammelt er? Wie resistent ist er gegen Red Herrings?

Wer die Benchmark-Zahlen generieren will:

make benchmark
make benchmark-update-readme

Aktuell stehen dort noch keine Zahlen — der Benchmark-Unterbau ist implementiert, die Datenmenge noch im Aufbau. Das ist ehrlich kommuniziert.

Was das für SRE-Teams bedeutet

OpenSRE verändert nicht, was SREs tun — es verändert, womit sie anfangen. Statt das erste Viertel eines Incidents mit Datenzusammentragen zu verbringen, bekommt ein SRE einen bereits strukturierten Report: wahrscheinlicher Root Cause, Beweiskette, offene Fragen, vorgeschlagene nächste Schritte.

Das schiebt die menschliche Entscheidung dorthin, wo sie hingehört: zur Bewertung. Ist der Root Cause plausibel? Stimmt die Beweislage? Was ist der Kontext, den der Agent nicht kennt — vergangene Deployments, geplante Wartungsfenster, bekannte Sonderverhalten des Systems? Diese Fragen kann nur der SRE beantworten. Die Datenaggregation nicht.

Der Umkehrschluss gilt ebenfalls: Je besser Runbooks und Kontextdokumente gepflegt sind, desto besser ist der Agent. OpenSRE ist ein Argument, in strukturiertes Wissen zu investieren — nicht als Bürokratie, sondern weil es den Agenten direkt besser macht.

Sicherheit und Telemetrie

OpenSRE ist für Produktionsumgebungen konzipiert: strukturierte und auditierbare LLM-Prompts, lokale Transcript-Verarbeitung als Standard, kein stiller Bulk-Export von Rohlogs. Der Agent operiert innerhalb klar definierter Trust Boundaries — etwa read-only Observability-Zugriff getrennt von write-fähigen Actions. Das ist relevant, weil ein SRE-Agent Zugriff auf sensible Infrastrukturdaten bekommt — Datenbankverbindungsstrings, API-Keys in Log-Ausgaben, interne Service-Architekturen.

Telemetrie (PostHog für Produktanalytics, Sentry für Errors) ist standardmäßig aktiv, aber opt-out:

export OPENSRE_NO_TELEMETRY=1

Einordnung

OpenSRE ist Public Alpha — v0.1, seit Januar 2026 in Entwicklung, explizit als früher Zustand gekennzeichnet. APIs und Integrationen können sich ändern. Die Benchmark-Zahlen fehlen noch. Das ist der ehrliche Stand.

Was das Projekt trotzdem interessant macht: Es adressiert ein echtes Problem an der richtigen Stelle. Nicht „KI schreibt Runbooks” oder „KI erstellt Dashboards” — sondern: KI liest Runbooks, liest Dashboards und zieht Schlüsse, wenn es darauf ankommt. Die 60+ Integrationen sind kein Feature-Padding, sie sind die Voraussetzung dafür, dass die Diagnose stimmt.

Für Teams, die Telegraf oder ähnliche Monitoring-Stacks betreiben, ist OpenSRE das logische nächste Experiment: Was leistet ein Agent, der auf dieselben Daten schaut, die bisher nur Menschen ausgewertet haben? Die spannende Frage ist nicht mehr, ob Agenten Incidents analysieren können — sondern wie zuverlässig und unter welchen Bedingungen. Der Rahmen, das zu messen, ist mit OpenSRE bereits da.