Fähigkeiten-Übersicht
Ongrid ist als 4-Schichten-Stack organisiert. Die Aufteilung existiert, weil jede Schicht eine andere Update-Kadenz, einen anderen Wirkungsradius und eine andere Audit-Haltung hat — sie zusammenzulegen produzierte das „KI-Agent, der herum-ssh-t"-Antimuster, an dem die frühen Prototypen scheiterten.
Warum das für Betreiber zählt
Die meisten der quervernetzten Funktionen unten (Audit, Rollen-Gating, Hot-Provider-Swap, Wirkungsradius-Walk) leben in einer bestimmten Schicht. Bei einer „X funktioniert nicht"-Frage ist die Schicht, der diese Seite sie zuordnet, dort, wo die Konfiguration liegt.
Die vier Schichten
L1 — Cluster
Die physische oder virtuelle Infrastruktur: Hosts, der Manager-Prozess, der eingebettete MySQL- / Prometheus- / Loki- / Tempo- / Grafana- / Qdrant-Stack und der bidirektionale geminio-Tunnel-Broker.
Ongrid abstrahiert diese Schicht NICHT — es gibt kein Inventarschema, keine CMDB. Hosts werden entdeckt, wenn ein Edge-Agent nach Hause wählt. Die Cluster-Schicht ist „alles, was das Manager-Binary zur Laufzeit berührt."
L2 — Edge-Tunnel + Device-Direkt
Jeder Host führt ein ongrid-edge-Binary aus, das eine einzelne ausgehende geminio-Verbindung zum Manager etabliert. Der Tunnel multiplext:
- Reverse-RPCs — Manager → Edge-Aufrufe, die ein Skill auf dem Host aufrufen (
Caller.Call(ctx, edgeID, method, body),internal/manager/biz/aiops/tools/registry.go:34). - WebSSH-Streams — interaktiver Terminal-Verkehr über eine dedizierte Stream-Klasse, siehe WebShell.
- Plugin-Signaling — ein Kontrollkanal, der der Edge mitteilt, welche Sub-Plugins (
promtail,otelcol,node-exporter) zu spawnen sind.
Die „Device-Direkt"-Idee ist L2s definierende Wette: der Manager adressiert echte Hosts, keine Dienst-Abstraktionen. Wenn der Agent sagt „restart nginx on edge-prod-04", führt genau ein Host den Befehl aus.
L3 — Intelligenz
Der Graph-Kernel-ReAct-Agent, die Tool-Registry, die Persona-Registry, die Wissensbasis und der LLM-Provider-Router. Lebt vollständig managerseitig, spricht mit L2 nur über die Tool-Tasche.
Schlüssel-Dateien:
internal/manager/biz/aiops/tools/— 30+ BaseTools, die Hände des LLM.internal/pkg/llm/—MultiClient,RoutingChatModel,BudgetChecker.internal/manager/biz/knowledge/— Qdrant + Vault + Upload.
L4 — Alarmierung
Regelauswertung, Incident-Lebenszyklus, Auto-RCA-Fan-out, Kanal-Routing, Inhibition. Angetrieben von den Prometheus- + Loki- + Tempo-Signalen, die L1 sammelt, und schreibt durch L3 (die Investigator-Persona) zurück, wenn ein Incident feuert.
Schlüssel-Dateien:
internal/manager/biz/alert/pipeline.go— der Evaluator-Tick.internal/manager/biz/alert/investigator/usecase.go— Auto-RCA.
Fähigkeiten-Matrix
| Fähigkeit | Schicht | Seite |
|---|---|---|
| Alarmregeln (8 Metrik + 6 Log/Trace-Arten) | L4 | Alarme |
| Automatische Grundursachenanalyse beim Incident-Feuern | L3 + L4 | RCA |
| Prometheus + Grafana-Embed | L1 | Monitoring |
| Loki-Log-Suche + Log-Alarme | L1 + L4 | Logs |
| Tempo-Trace-Suche + Trace-Alarme | L1 + L4 | Traces |
| Dienst- / Device-Graph mit Wirkungsradius-Walk | L3 | Topologie |
| RAG gegen Vault + eigene Repos | L3 | Wissensbasis |
| 30+ Host- / Observability- / Wissens-Tools | L2 + L3 | Skills |
| WebSSH mit vollständiger Session-Aufzeichnung | L2 | WebShell |
Was diese Seite nicht ist
Dies ist die operatororientierte Übersicht. Für die Designbegründung (warum PromQL als kanonisches Prädikat behalten wurde, warum die Edge nach außen wählt, warum remote_write gegenüber scrape bevorzugt wird) siehe den ADR/HLD-Index im docs/-Baum des GitHub-Repos.
Siehe auch
- Architektur — die gleiche 4-Schichten-Aufteilung als Bereitstellungsdiagramm ausgedrückt.
- Konzepte — Vokabular (Edge, Device, Incident, Persona, Scope).
- Alarmregel-Schema — das Wireformat der Regel-Zeilen, die die Alarme-Seite zusammenfasst.