Monitoring

Ongrid liefert ab Werk eine funktionierende Monitoring-Pipeline und ist darauf ausgelegt, sich an Ihre bestehende Pipeline anzupassen, falls Sie bereits eine haben.

Die Datenebene

edge:
  hostmetrics, procmetrics, node-exporter  ─┐
                                            │  remote_write (HTTPS direct)
                                            ▼
                                       ┌─────────┐
                                       │  Prom   │  (default: bundled)
                                       └────┬────┘
                                            │ query_range / instant
                                            ▼
                                  ┌──────────────────────┐
                                  │  manager:            │
                                  │   - alert evaluator  │
                                  │   - query_promql     │
                                  │   - /api/grafana     │
                                  └──────────────────────┘

Die Voreinstellung ist ein im docker-compose mitgeliefertes Prometheus unter prometheus:9090. Edges pushen direkt über HTTPS — kein Scrape, keine Node Discovery. Das ist die Daten-/Steuerungsebenen-Trennung aus ADR-014: Der geminio-Tunnel trägt die Steuerung, die Telemetrie geht direkt.

Warum direkt und nicht über den Tunnel

Bei einer Kardinalität von ≥ 5 k Serien/Sekunde auf einer 50-Host-Installation verschluckt sich das Multiplexen von remote_write durch den geminio-Steuertunnel. Direktes remote_write nimmt den Manager aus dem heißen Pfad und überlässt es Proms eigenem Write-Ahead-Log, die Ingest-Pufferung zu übernehmen. Der Trade-off ist ein zusätzlicher HTTPS-Endpunkt zum Öffnen; siehe Server-Installation für das nginx-Reverse-Proxy-Snippet.

Eingebautes vs. externes Prom

Beide Modi sind erstklassig.

Eingebaut (Standard)

docker compose up startet prometheus:v2.55 mit --web.enable-remote-write-receiver. Der Speicher ist ein benanntes Volume ongrid_prom_data. Die Retention beträgt standardmäßig 15 d — anpassbar über PROMETHEUS_RETENTION in .env.

Der Manager spricht es unter http://prometheus:9090 via der ONGRID_PROM_QUERY_URL-Env-Variable an. Keine weitere Konfiguration nötig.

Extern

Richten Sie ONGRID_PROM_QUERY_URL auf Ihren eigenen Prom- / VictoriaMetrics- / Thanos-Query-Endpunkt aus. Edges verwenden weiterhin remote_write — richten Sie sie auf Ihre Ingest-URL aus, indem Sie das pro-Edge remote_write_url in der Edge-Plugin-Konfiguration setzen (internal/manager/biz/edge/plugin_config.go).

Das von der Cloud mitgelieferte Prom kann als „Selbstbeobachtungs"-Prom weiterlaufen, das nur den Manager selbst scrapt (die ADR-026-Self-Obs-Metriken liegen dort). Alarme, die beide Hälften brauchen, können zweimal mit unterschiedlichen match_scope_types definiert werden.

Der Abfragepfad

Zwei Konsumenten, ein Client.

Alarm-Evaluator

PipelineEvaluator.evaluatePromQuery führt bei jedem Tick die Expr jeder aktivierten metric_raw-Regel aus. Die Vergleichsoperatoren von PromQL selbst (up == 0, cpu_pct > 90) SIND das Prädikat — Prom verwirft nicht passende Serien aus der Antwort, sodass der Evaluator pro zurückgegebenem Vektoreintrag einfach einen Incident auslöst und den Rest beim nächsten Recovery-Sweep aufräumt.

// pipeline.go:269
res, err := e.prom.Query(ctx, rule.Expr, now)
// ...
for _, ent := range entries {
    dedupeKey := fmt.Sprintf("pipeline:%s:%s", rule.RuleKey, labelSetKey(ent.Metric))
    // ... RecordFiring + notify
}

Das query_promql-Werkzeug

Das LLM erhält ein BaseTool namens query_promql, das eine Instant- oder Range-Abfrage entgegennimmt und den JSON-Vektor / die Matrix zurückgibt. Die Investigator-Persona nutzt es als ihre primäre Metrik-Sonde; der Coordinator-Chat nutzt es, wann immer Sie fragen „Wie hoch ist die CPU auf edge-prod-04 gerade?"

Das Schema liegt in query_promql_basetool.go; die zugrundeliegende Engine ist internal/pkg/promquery.

Eingebettetes Grafana

Das Compose liefert Grafana unter grafana:3000 aus. Der Manager proxyt es unter /api/grafana/* (Auth am Proxy geprüft), sodass MonitorPanel.tsx der SPA mit einem Klick iframes einbetten kann — kein separates Grafana-Login.

Ab Werk spiegelt der Manager interne Monitor-Panel-Definitionen über biz/grafana/Service bei einem Sync-Tick nach Grafana. Operatoren bearbeiten Panels in Grafana (im reichhaltigen Editor), der Manager nimmt sie auf. Die Seite MonitorEditor in der SPA ist ein schlanker Read-then-Redirect, der den Grafana-Panel-Editor mit den relevanten Serien vorausgefüllt öffnet.

Grafana-Zugangsdaten

Das mitgelieferte Grafana startet mit admin / admin. Ändern Sie das vor dem Freischalten. Siehe Erstinbetriebnahme-Checkliste.

Selbstbeobachtung

ADR-026 hat /metrics am Manager + 6 Basis-Alarme verdrahtet (LLM-Token-Spike, Alarm-Evaluator-Stall, Tunnel-Disconnect-Storm, Audit-Log-Lag, Investigator-Backlog, RCA-Latenz p99). Diese werden beim ersten Boot in die Regel- + Dashboard-Tabellen geseedet und bei jedem Upgrade erneut bestätigt.

Das mitgelieferte Prom scrapt das /metrics des Managers. Im Modus mit externem Prom müssen Sie ein Scrape-Target unter manager:9100 hinzufügen (Standard ONGRID_METRICS_ADDR).

Siehe auch

• Alarme — die Regel-Arten, die Prom abfragen.
• Traces — der Spanmetrics-Generator, der traces_spanmetrics_*-Serien zurück in dasselbe Prom füttert.
• Logs — die parallele Pipeline für Loki.
• Umgebungsvariablen — jeder ONGRID_PROM_*- und PROMETHEUS_*-Stellknopf.