Wie Ongrids On-Call-Assistent Vorfälle direkt in Messengern untersucht

Stellen Sie sich ein typisches On-Call-Szenario vor. Um drei Uhr morgens schlägt ein Alarm an: Die API-Antwortzeiten sind um das Fünffache gestiegen. Müde öffnen Sie Ihren Laptop, squinten durch ein Dutzend Dashboards in Grafana, dann SSH in Nodes über einen Bastion-Host und greppen hektisch durch Logs. Die Suche nach der Grundursache dauert eine halbe Stunde, obwohl das Problem nur ein abgestürzter Pod oder eine feststeckende Transaktion war.

Die Autoren des Open-Source-Projekts Ongrid beschlossen, diese Routine an eine Kombination aus spezialisierten KI-Agenten und einem fertigen Observability-Stack auszulagern.

Was das System kann

Ongrid fungiert als autonomer On-Call-Ingenieur. Es verbindet sich mit Messengern wie Telegram oder Slack, lauscht auf eingehende Alarme und beginnt sofort mit der Untersuchung.

Das System basiert auf einer Coordinator- und Narrow-Specialist-Architektur. Wenn ein Alarm eingeht, erstellt der Haupt-Agent einen Worker für die Root-Cause-Analyse. Dieser Worker fragt Agenten für Datenbanken, Netzwerke oder SRE ab, sammelt Metriken, Logs und Traces, baut eine Abhängigkeitskarte auf und liefert einen fertigen Bericht im Chat, der auf die spezifische Codezeile oder den fehlgeschlagenen Service zeigt.

Sicherheit und Zugriffskontrolle

Der Albtraum jedes Sysadmins beim Hören von „einem Agenten in Produktion" ist eine Modellhalluzination, die einen gefährlichen Befehl ausführt und die Datenbank lahmlegt. Die Entwickler von Ongrid haben dies pragmatisch angegangen.

Erstens laufen Host-Utilities und die Bash-Sandbox standardmäßig im Read-Only-Modus. Der Agent kann diagnostische Befehle ausführen, den Prozessstatus prüfen oder Socket-Zustände inspizieren, wird aber nicht stillschweigend den Server neu starten.

Zweitens sind alle potenziell destruktiven Aktionen durch ein spezielles Genehmigungs-Gateway geschützt. Bevor ein Fix angewendet wird, fordert der Bot eine Genehmigung vom On-Call-Ingenieur im Chat oder in der Web-Oberfläche an.

Drittens müssen Hosts überhaupt keine offenen eingehenden Ports haben. Ein leichtgewichtiger Edge-Agent wird auf den Zielservern installiert, der eine ausgehende Verbindung zum Ongrid-Server selbst herstellt. SSH-Zugriff über Web-Terminal funktioniert über einen Reverse-Tunnel, ohne Port 22 nach außen weiterzuleiten und ohne mit Keys auf Bastion-Hosts zu hantieren. Jeder Aufruf wird zu Audit-Zwecken protokolliert.

Observability, Topologie und Kubernetes

Im Inneren ist bereits ein vorkonfigurierter Stack aus Prometheus, Loki, Tempo und Grafana eingerichtet. Der Unterschied ist, dass der Agent selbst Abfragen an sie schreibt und Ereignis-Zeitstempel mit OpenTelemetry-Traces korreliert.

Kubernetes-Cluster-Management wurde kürzlich zum Projekt hinzugefügt. Der Agent verbindet Cluster über Edge, verfolgt Workload-Events, hilft bei Upgrades und projiziert Pods auf eine gemeinsame Topologiekarte.

Die Topologiekarte hilft, die Blast-Radius eines Vorfalls einzuschätzen. Wenn ein Netzwerk-Switch oder eine Datenbank ausfällt, visualisiert das System alle abhängigen Services und filtert False Positives heraus.

Wissensdatenbank und Skill-Erweiterung

Jedes LLM ist ohne Kontext über Ihre Infrastruktur nutzlos. Ongrid enthält einen Knowledge Vault, in dem Sie Runbooks, vergangene Postmortems und Code-Repositories hochladen können. Die Qdrant-basierte Vektorsuche findet relevante Anweisungen und speist sie während der Vorfallanalyse in den Agenten ein.

Wenn Standard-Tools nicht ausreichen, können Sie weitere über MCP (Model Context Protocol) hinzufügen oder Ihr eigenes Szenario im visuellen Workflow-Editor erstellen.

Generierte Berichte und Dashboards werden im Artifacts Center gespeichert, wo sie leicht mit dem Team während Postmortems geteilt werden können.

Unter der Haube und Model-Stack

Das Backend der Plattform ist in Go geschrieben, und das Frontend ist mit React und TypeScript aufgebaut. Die Lösung kann vollständig auf Ihren eigenen Servern unter der AGPLv3-Lizenz bereitgestellt werden.

Was Sprachmodelle betrifft, ist das Projekt nicht an einen einzelnen Anbieter gebunden. Sie können Claude von Anthropic, OpenAI, DeepSeek, Gemini oder lokale Instanzen verwenden und den Model-Routing je nach Aufgabenkomplexität dynamisch umschalten.

So deployen Sie auf Ihrem eigenen Server

Die Installation auf Ubuntu, Debian oder Rocky Linux erfolgt mit einem fertigen Script:

# Для архитектуры AMD64
wget https://github.com/ongridio/ongrid/releases/download/v0.12.0/ongrid-v0.12.0-linux-amd64.tar.xz
tar -xf ongrid-v0.12.0-linux-amd64.tar.xz && cd ongrid-v0.12.0-linux-amd64
sudo ./install.sh

Für ARM64 ersetzen Sie einfach den Archivnamen durch das entsprechende Release. Das Script startet die Server-Komponente und die Web-Oberfläche, danach müssen Sie nur noch die Messenger-Verbindung konfigurieren und den Edge-Agent auf den Hosts installieren.

Für wen es sich lohnt

Ongrid ist nützlich für kleine und mittlere Operations-Teams, in denen es kein rund um die Uhr besetztes Network Operations Center (NOC) gibt und Entwickler sich beim On-Call abwechseln. Es nimmt die erste Welle der Panik während eines Vorfalls, indem es sofort Logs sammelt und das Problem auf eine klare Zusammenfassung eingrenzt.

Das Projekt ist noch jung (ca. 700 Stars auf GitHub), aber architektonisch wirkt es ausgereift dank des Fokus auf Sicherheit und der Verwendung offener Telemetrie-Standards.