Gateways orchestrieren Werkzeuge, Modelle und Richtlinien. Logs erzählen Geschichten nach Incidents, aber Prometheus-Metriken zeigen graduelle Latenz-Drift, Queue-Wachstum und Provider-spezifische Fehlerquoten, bevor Rechnungen explodieren. Für OpenClaw in 2026 bedeutet Reife: ein textuelles /metrics-Endpoint, sauber begrenzte Labels, Histogramme, die zu SLOs passen, und Betrieb, der Healthchecks, Logs und Traffic-Drains nicht gegeneinander ausspielt. Lesen Sie parallel Gateway-Health-Monitoring und Uptime, Logging-Redaktion mit logrotate, Upgrade- und Migrations-Checklisten sowie nginx-Rolling-Drains, damit Observability während Deployments konsistent bleibt.
Rehearsals auf dedizierter Apple-Hardware sind kostbar, aber MacHTML-Cloud-Mac-mini-Angebote um 16,9 USD pro Tag machen mehrtägige Soak-Tests machbar, ohne Laptops zu blockieren.
Warum Gateways Prometheus brauchen
Im Gegensatz zu klassischen Webdiensten multiplexen Agenten-Gateways viele parallele Streams: WebSockets, HTTP-Batches, Dateisystem-Nebenwirkungen und externe APIs. CPU-Diagramme allein täuschen, weil Arbeit zwischen Worker verschoben werden kann. Zähler für Anfragen, Histogramme für Latenzen und Gauges für Queue-Tiefe machen Engpässe sichtbar, bevor Nutzerinnen sie spüren. Ohne diese Signale bleiben Teams auf Tail-Sampling angewiesen, das seltene, teure Tool-Aufrufe übersieht.
OpenClaw betont partielle Ausfälle: ein Provider kann gedrosselt sein, während andere gesund wirken. Metriken müssen daher segmentiert, aber nicht übersegmentiert sein—ein Spannungsfeld, das die folgenden Abschnitte adressieren.
Operativ bedeutet das: Incident-Commander brauchen Kurven, die sich mit Runbook-Schritten decken. Wenn ein Dashboard nur „CPU hoch“ zeigt, verlieren Teams kostbare Minuten mit Profilern, während Warteschlangen weiter wachsen. Prometheus liefert zudem eine gemeinsame Abfragesprache für On-Call-Rotationen, die nicht jedes interne Gateway-Dashboard neu lernen müssen.
Finanzielle Kontrollen profitieren ebenfalls: plötzlich steigende Token-Nutzung korreliert mit Histogramm-Schieflagen auf bestimmten Routen. Ohne Metriken entdecken Finanzteams die Abweichung erst in monatlichen Abrechnungen, wenn Korrekturen teuer sind und Kundenerwartungen bereits gebrochen wurden.
Schließlich erleichtern Metriken Postmortems: reproduzierbare PromQL-Snippets zeigen exakt, wann ein Canary begann, sich von der Baseline zu entfernen, während Logs kontextuelle Spuren liefern. Die Kombination verkürzt MTTR messbar, sofern Dashboards im Vorfeld kuratiert wurden.
Scrape-Design für /metrics
Trennen Sie Kunden-Traffic von Admin-Endpunkten. Binden Sie Metriken an Loopback oder interne Schnittstellen, tunneln Sie via SSH oder schützen Sie mit mTLS. Prometheus benötigt stabile Ziele und konsistente metrics_path-Werte. Planen Sie Scrape-Intervalle so, dass sie nicht mit Cold-Start-Spitzen kollidieren, die direkt nach Rollouts auftreten.
Service Discovery muss konsistent mit Ihrem Orchestrierer sein: wenn Kubernetes Endpoints liefert, stellen Sie sicher, dass Readiness-Probes den Pod aus der Liste entfernen, bevor der Prozess SIGTERM erhält. Für Bare-Metal- oder VM-Deployments dokumentieren Sie Ports pro Rolle und vermeiden Sie dynamische Portzuweisungen, die Prometheus-Ziele bei jedem Neustart invalidieren.
Global limits: setzen Sie scrape_timeout knapper als das Intervall, damit hängende TLS-Handshakes nicht unbegrenzt Threads blockieren. Kombinieren Sie das mit circuit breakern auf Seiten des Agents, damit ein langsames Gateway nicht alle Pull-Worker einfriert.
scrape_configs:
- job_name: openclaw-gateway
scrape_interval: 15s
metrics_path: /metrics
static_configs:
- targets: ['gateway-prod.internal:9108']Dokumentieren Sie TLS-Zertifikatsrotation getrennt von App-Releases, damit Scrape-Failures nicht fälschlich als Code-Regressionen interpretiert werden.
Histogramme vs. Summaries
Histogramme erlauben serverseitig gewählte Buckets und konsistente Quantil-Schätzungen über Replikas. Summaries berechnen Quantile clientseitig und lassen sich nicht zuverlässig aggregieren. Wählen Sie Bucket-Grenzen entlang definierter SLO-Schwellen, etwa 250ms oder 1s, statt willkürlicher Zehnerpotenzen. Exemplare verbinden Traces—nur aktivieren, wenn Sampling und Datenschutzprozesse stehen.
Praktisch sollten Sie Histogramme für serverseitig gemessene Roundtrips verwenden und Summaries nur dort, wo Bibliotheken keine alternative Instrumentierung erlauben. Achten Sie darauf, dass Bucket-Überläufe dokumentiert sind: wenn alles im „+Inf“-Bucket landet, sind SLOs blind. Reviewen Sie Dashboards wöchentlich auf leere Buckets und verschobene Schwerpunkte nach Releases.
Native Histogramme reduzieren Label-Druck in neueren Prometheus-Versionen; migrieren Sie frühzeitig, wenn Ihre Plattform sie unterstützt, und planen Sie Speicher-Budgets neu, da die TSDB anders komprimiert.
Kardinalität und Label-Budgets
Jede Labelkombination erzeugt eine neue Zeitreihe. Gateways verführen dazu, Modellnamen, Dateipfade oder API-Schlüssel als Labels zu exportieren—unterlassen Sie das. Begrenzen Sie die Serie pro Prozess hart und verschieben Sie hochkardinale Dimensionen in strukturierte Logs, die bereits nach den Redaktionsregeln im Logging-Artikel aus dem Einleitungsblock behandelt werden.
Recording Rules können Routen aggregieren, ohne sensible IDs preiszugeben. Reviewen Sie neue Labels im CI, indem Sie Serienzahlen nach Integrationsläufen vergleichen.
Alarmieren Sie auf sprunghafte Serienzahlen: ein fehlerhaftes Deployment, das UUIDs als Label exportiert, verdoppelt schnell die TSDB-Größe. Setzen Sie harte Obergrenzen in der Instrumentierungsbibliothek und verwenden Sie const-Enums für erlaubte Werte. Wenn dynamische Werte nötig sind, hashen Sie sie serverseitig in wenige Buckets.
Denken Sie an Federation und downsampling: edge-nahe Prometheus-Instanzen können grobkörnig aggregieren, bevor zentrale Systeme langfristig speichern. Dokumentieren Sie, welche Labels bei Federation fallengelassen werden, damit keine Compliance-relevanten Dimensionen verloren gehen.
Metriken mit Health und Logs koppeln
Synthetische Probes sagen „Port offen“, Metriken sagen „Warteschlange leert“. Kombinieren Sie Dashboards so, dass Farbwechsel auf Probes mit steigenden Fehlerzählern korrelieren. Während größerer Upgrades—siehe Migrations-Checkliste im Einleitungsabsatz—pausieren Sie Autoscaling, wenn Scrape-Erfolg über zwei Intervalle unter definierte Schwellen fällt.
Logs liefern Kontext zu Spans und Request-IDs; Metriken liefern den zeitlichen Rahmen. Verknüpfen Sie Grafana-Links mit vorgefertigten Log-Queries, damit On-Call nicht neu bastelt. Trainieren Sie Support so, dass sie zuerst Metriken öffnen, um Incident-Scope einzugrenzen, bevor sie tief in Logs graben.
Alert-Routing sollte unterschiedliche Schweregrade unterscheiden: ein fehlgeschlagener Scrape kann transient sein, während steigende 5xx-Raten kritisch sind. Vermischen Sie nicht beide Signale in einer Sirene, sonst gewöhnen Teams sich an False Positives.
Scrapes während nginx-Drains
Bei Rolling-Deployments verschieben sich Upstreams frühzeitig. Service Discovery muss beendete Pods entfernen, bevor Prometheus erneut scraped; andernfalls entstehen Lücken oder falsche „down“-Signale. Folgen Sie dem Drain-Artikel aus der Einleitung, um Readiness-Gates konsistent zu halten.
Wenn Prometheus durch einen zentralen nginx scrapt, definieren Sie eigene location-Blöcke mit IP-Allowlists und getrennten Zertifikaten. So rotieren Sie TLS unabhängig von öffentlichen Hostnamen und vermeiden, dass Marketing-DNS-Zerschneidungen Admin-Pfade offenlegt.
Beobachten Sie zudem HTTP/2-Verbindungsmultiplexing: lange Streams können Scrapes verzögern, wenn Worker ausgelastet sind. Begrenzen Sie parallele Scrape-Jobs pro Host, um Head-of-Line-Blocking zu vermeiden.
LaunchAgent für lokale Agenten
Auf macOS sind LaunchAgents präziser als cron. Lassen Sie minütlich einen kleinen Check laufen, der /metrics lokal curl’t und Textformat validiert. Speichern Sie Geheimnisse nicht in Plists—Keychain-Helfer verwenden.
Protokollieren Sie stdout/stderr in die Unified Logging-Schicht, damit MDM-Tools Fehler sammeln können. Für mehrere Umgebungen nutzen Sie getrennte Label in der lokalen Prometheus-Config, damit Rehearsal-Daten nie Produktions-Dashboards vergiften.
Denken Sie an Energiesparmodi: Laptops im Deckelmodus verzögern Timer. Für CI-Mac-Minis im Rechenzentrum ist das weniger relevant, aber für verteilte Entwicklerlaptops sollten Scrape-Tests im CI die Quelle der Wahrheit bleiben.
<key>StartInterval</key>
<integer>60</integer>Cloud-Mac-Rehearsal
Ein gemieteter Mac mini spiegelt Scheduler, Dateisystem-Groß-/Kleinschreibung und TLS-Stacks. Richten Sie eine Mini-Prometheus-Instanz mit kurzer Retention ein und simulieren Sie Lastgenerator-Szenarien. Mit etwa 16,9 USD pro Tag amortisieren sich Mehrtages-Tests gegenüber Produktionsausfällen schnell.
Automatisieren Sie Screenshots von Grafana-Kiosks via SSH, um visuelle Regressionen in Dashboards zu erkennen, wenn sich PromQL-Dateien ändern. Speichern Sie Artefakte versioniert neben dem Gateway-Build, damit Support nachvollziehen kann, welche Metrikdefinition aktiv war.
Testen Sie auch Uhrzeitsprünge: Springende Uhren auf VMs können Scrape-Intervalle verschieben. Stellen Sie NTP-Disziplin sicher, damit Alert-Evaluator keine falschen Fenster berechnen.
Sicherheit und Admin-Trennung
Metriken verraten interne Queue-Namen, Versionen und Circuit-Breaker-Zustände. Schützen Sie Endpunkte mit Netzwerkrichtlinien und getrennten TLS-Profilen. Vermeiden Sie, dass öffentliche Reverse-Proxies Admin-Pfade aus Versehen exponieren, wenn DNS-Einträge zwischen Umgebungen kopiert werden.
RBAC für Prometheus selbst ist ebenso wichtig: nicht jeder Engineer braucht Rohzugriff auf potenziell sensible Label, die aus Versehen doch exportiert wurden. Kombinieren Sie Datenmaskierung downstream mit strengen Review-Prozessen upstream.
Wenn Sie mTLS verwenden, rotieren Sie Client-Zertifikate häufiger als öffentliche Zertifikate und überwachen Sie Ablaufalarme separat, damit Metriken nicht stillschweigend verschwinden.
SLOs, Recording Rules, Burn-Alerts
Definieren Sie SLIs aus Latenz und Fehleranteil, materialisieren Sie mehrfenstrige Burn-Alerts und halten Sie Runbooks bereit, die PromQL-Abfragen mit Logfiltern verknüpfen. Recording Rules halten Dashboards flüssig, sollten aber dokumentiert sein, damit neue Engineerinnen wissen, welche Metriken abgeleitet sind.
Kalibrieren Sie Fensterlängen mit historischen Daten: zu kurze Fenster flackern, zu lange verzögern die Reaktion. Nutzen Sie separate Alerts für Budgetverbrennung und absolute SLO-Verletzungen, damit Teams priorisieren können.
Integrieren Sie Statusseiten: wenn Burn-Alerts feuern, sollten automatische Updates nur dann öffentlich gehen, wenn Kommunikationsrichtlinien das erlauben—verkoppeln Sie das explizit, um Panik zu vermeiden.
Matrix: exportieren oder streichen
| Signal | Export? | Hinweis |
|---|---|---|
| Request-UUID | Nein | In Logs mit Redaktion. |
| Queue-Tiefe | Ja | Kritisch für Backpressure. |
| 429-Zähler je Provider | Ja | Bounded Labels. |
| Heap-Samples | Nein | Eigenes pprof mit Auth. |
Rollout-Checkliste
- Serien inventarisieren und Budget einhalten.
- Histogramm-Buckets mit SLOs abstimmen.
- TLS, ACLs und Relabel finalisieren.
- Readiness so konfigurieren, dass Drains sauber sind.
- Loadtests auf Cloud-Mac mit Produktionsintervallen.
- Grafana-Annotationen für Deployments aktivieren.
- LaunchAgent-Canary auf macOS-Hosts.
- Retention und Downsampling für Rehearsal-Prometheus setzen.
FAQ
Prometheus direkt auf dem Gateway-Host?
Meist nein—zentrale TSDB reduziert Blast-Radius.
OpenTelemetry?
Ergänzend; übersetzen Sie in Prometheus, wenn PromQL Standard ist.
Kardinalität in CI testen?
Ja, Serienzählen nach Tests snapshotten und bei Regressionen failen.
Zuverlässige Metriken sind Teil derselben Zuverlässigkeitskultur wie Healthchecks und Logs. Ein Mac mini von MacHTML für rund 16,9 USD pro Tag hilft, Scrape-Pfade und TLS vor Produktions-Prometheus zu validieren.
Gateway-Metriken auf Cloud-Mac-mini proben
Spiegeln Sie Produktions-Scrapes, messen Sie Kardinalität und testen Sie LaunchAgent-Zyklen auf echter macOS-Hardware.