Als einer meiner Agenten zum ersten Mal stillgelegt wurde, bemerkte ich es drei Tage lang nicht. Drei Tage ohne geplante Berichte. Drei Tage ohne beantwortete automatische Nachrichten. Drei Tage ohne eine Überwachungsaufgabe, die nichts überwachte.
Mein Kunde bemerkte es früher als ich. Das war peinlich.
Also richtete ich Grafana ein, um meine Agenten so zu beobachten, wie meine Agenten alles andere beobachten. Jetzt weiß ich innerhalb von Minuten, wenn etwas schiefgeht, und ich weiß normalerweise bevor ich ein Terminal öffne, warum.
Was man überwachen sollte (und was nicht)
Als ich zum ersten Mal die Überwachung einrichtete, verfolgte ich alles. Antwortzeiten pro Anfrage, Tokenanzahlen pro Nachricht, Modellzuversichtswerte, Speicherverbrauch pro Sitzung, Fehlerquoten nach Typ, Latenzhistogramme… 47 Metriken auf 12 Panels.
Ich sah mir dieses Dashboard eine Woche lang an. Dann wurde mir klar, dass ich nur vier Dinge beobachtete:
Läuft es? Einfache Überprüfung ob aktiv oder nicht. Grüner Punkt = Prozess ist aktiv und reagiert. Das erkennt Abstürze, Hänger und Infrastrukturfehler.
Ist es langsam? Durchschnittliche Antwortzeit der letzten 5 Minuten. Normalerweise 2-3 Sekunden. Wenn es über 8 Sekunden kriecht, stimmt etwas nicht – normalerweise Kontextschnellx oder API-Anbieterprobleme.
Schlägt es fehl? Fehlerquote als Prozentsatz der gesamten Anfragen. Unter 2 % ist normal (gelegentliche API-Timeouts). Über 5 % bedeutet systematische Probleme.
Ist es teuer? Betriebskosten für den aktuellen Tag im Vergleich zum Tagesdurchschnitt. Ein 2-facher Anstieg bedeutet, dass etwas unerwartet lange oder häufige Anfragen generiert.
Ich habe mein Dashboard auf diese vier Metriken reduziert. Eine Reihe, vier große Zahlen mit Farbcode. Damit sehe ich zehnmal am Tag nach. Alles andere befindet sich auf einer „Details“-Seite, die ich nur beim Debuggen besuche.
Die Einrichtung
Daten Sammlung: Ich schrieb ein kleines Skript, das OpenClaw-Protokolle analysiert und Metriken im Prometheus-Format bereitstellt. Es läuft als Sidecar-Prozess und liest die Protokolldatei alle 30 Sekunden aus. Etwa 50 Codezeilen. Nichts Aufwändiges.
Die Metriken, die es bereitstellt:
– openclaw_requests_total (Zähler, nach Typ gekennzeichnet)
– openclaw_response_seconds (Histogramm)
– openclaw_errors_total (Zähler, nach Fehlerart gekennzeichnet)
– openclaw_tokens_used (Zähler, nach Richtung: Eingabe/Ausgabe gekennzeichnet)
– openclaw_process_up (Gauge, 1 oder 0)
Prometheus liest diese Metriken alle 15 Sekunden aus. Die Standardaufbewahrung beträgt 15 Tage, was für meine Bedürfnisse ausreichend ist. Prometheus läuft auf demselben Server wie OpenClaw – es verwendet etwa 100 MB RAM für diese kleine Arbeitslast.
Grafana visualisiert die Metriken. Ich nutze die kostenlose Stufe von Grafana Cloud (10.000 Metriken, was reichlich ist). Sie können Grafana auch selbst auf dem selben Server hosten – es ist leichtgewichtig.
Gesamte Einrichtungszeit: etwa 2 Stunden beim ersten Mal. Der größte Teil davon war das Schreiben des Log-Parsers.
Die Alerts, die funktionieren
Ich habe vier Alarme. Ich habe deren Schwellenwerte über drei Monate hinweg angepasst, um Fehlalarme zu minimieren:
Prozess länger als 2 Minuten down. Wird ausgelöst, wenn die Überprüfung aktiv/inaktiv zwei aufeinanderfolgende Minuten lang fehlschlägt. Zwei Minuten geben genug Puffer für Neustarts und kurze Netzwerkprobleme. Dies sendet eine Push-Benachrichtigung an mein Telefon.
Antwortzeit p95 > 15 Sekunden für 5 Minuten. Eine einzelne langsame Antwort ist nicht entscheidend. Fünf Minuten mit konstant langsamen Antworten bedeuten, dass etwas systematisch nicht stimmt. Dies wird in meinem Slack-Alarmkanal gepostet.
Fehlerquote > 10 % für 3 Minuten. Ich habe diesen Wert höher gesetzt als man erwarten könnte (10 % statt 5 %), da kurzfristige API-Timeout-Spitzen während Wartungsarbeiten des Anbieters normal sind. Drei Minuten mit dauerhaft hohen Fehlern bedeutet, dass es sich nicht um einen kurzzeitigen Ausfall handelt. Telefonbenachrichtigung.
Tägliche Kosten > 3x gleitender Durchschnitt. Stündliche Überprüfung. Erfasst Schleifen und unerwartete Nutzungsmuster, bevor sie teuer werden. Nur Slack-Warnung – dies ist informativ, nicht dringend.
Ich habe zwei Warnungen entfernt, die zu laut waren: „jede einzelne Anfrage > 30 Sekunden“ (trat bei komplexen Agentenaufgaben zu häufig auf) und „Speicherverbrauch > 80 %“ (irrelevant – Node.js verwaltet seine eigene Speicherbereinigung und kurze Spitzen sind normal).
Das Dashboard, das echte Probleme entdeckte
Februar: Allmählicher Kontext-Überfluss. Die Antwortzeiten stiegen in zwei Wochen von 2,5 s auf 7 s. Die Trendlinie war auf dem Dashboard offensichtlich – einzelne Anfragen sahen gut aus, aber der tägliche Durchschnitt stieg. Grundursache: Gesprächskontexte wuchsen, weil die Verdichtung nicht korrekt ausgelöst wurde. Ein Konfigurationsfix brachte die Antwortzeiten innerhalb einer Stunde wieder auf normal zurück.
März: Kostenanstieg durch eine Schleife. Ein Cron-Job hatte einen Retry-Mechanismus, der aufgrund eines Fehlers unendlich oft versuchte, wenn die API einen bestimmten Fehlercode zurückgab. Die tägliche Kostenwarnung wurde bei 2x des Durchschnitts ausgelöst. Ich erkannte es innerhalb von 2 Stunden. Ohne die Warnung hätte es weitergearbeitet, bis der API-Schlüssel sein Ausgabenlimit erreicht hätte.
März: Stiller Cron-Fehler. Mein täglicher Berichtjob hörte auf zu laufen. Kein Fehler – es wurde einfach nicht ausgeführt. Das Dashboard zeigte, dass der erwartete tägliche Anstieg der Aktivität um 8 Uhr fehlte. Der Cron-Planer war nach einem Update abgestürzt. Ein Neustart behob das Problem, und ich fügte den Bemerkung „Prozess nicht aktiv” speziell für den Planer hinzu.
Was ich meinem früheren Ich sagen würde
Beginne mit den vier grundlegenden Metriken. Füge Komplexität nur hinzu, wenn du einen spezifischen Debugging-Bedarf hast. Die meisten Überwachungsdashboards scheitern, weil sie zu komplex sind – du baust 20 Panels, wirst von den Daten überwältigt und hörst auf, das Dashboard überhaupt zu betrachten.
Das Dashboard, das du tatsächlich verwendest, ist besser als das Dashboard, das alles verfolgt. Mach es übersichtlich, mach die Alarme umsetzbar und überprüfe die Schwellenwerte monatlich. Das ist die ganze Strategie.
🕒 Published: