Als mein erster Agent plötzlich und lautlos aufhörte zu funktionieren, bemerkte ich es drei Tage lang nicht. Drei Tage lang versäumte ich geplante Berichte. Drei Tage lang gab es automatisierte Nachrichten ohne Antwort. Drei Tage lang gab es Überwachungsarbeit, die nichts überwachte.
Mein Kunde bemerkte es früher als ich. Es war peinlich.
Also richtete ich Grafana ein, um meine Agenten so zu überwachen, wie meine Agenten alles andere überwachen. Jetzt weiß ich in den Minuten, die folgen, wenn etwas nicht stimmt, und ich weiß in der Regel warum, bevor ich überhaupt ein Terminal öffne.
Worauf man achten sollte (und worauf nicht)
Als ich die Überwachung zum ersten Mal einrichtete, überwachte ich alles. Die Antwortzeiten pro Anfrage, die Anzahl der Tokens pro Nachricht, die Vertrauenswerte der Modelle, den Speicherverbrauch pro Sitzung, die Fehlerquoten pro Typ, die Latenzhistogramme… 47 Metriken auf 12 Panels.
Ich betrachtete dieses Dashboard eine Woche lang. Dann stellte ich fest, dass ich nur vier Dinge wirklich beobachtete:
Funktioniert es? Einfache Überprüfung ein/aus. Grüner Punkt = der Prozess lebt und antwortet. Das hilft, Abstürze, Hänger und Ausfälle der Infrastruktur zu erkennen.
Ist es langsam? Durchschnittliche Antwortzeit der letzten 5 Minuten. Normalerweise 2-3 Sekunden. Wenn es 8 Sekunden überschreitet, stimmt etwas nicht – normalerweise eine Kontextüberlastung oder Probleme mit dem API-Anbieter.
Fehlt es? Fehlerquote in Prozent der Gesamtanfragen. Unter 2 % ist normal (gelegentliche API-Zeitüberschreitungen). Über 5 % deutet auf systematische Probleme hin.
Ist es teuer? Betriebskosten für den aktuellen Tag im Vergleich zum Tagesdurchschnitt. Ein Anstieg auf 2x bedeutet, dass etwas abnormale lange oder häufige Anfragen generiert.
Ich habe mein Dashboard auf diese vier Metriken reduziert. Eine Zeile, vier große Zahlen mit Farbcode. Das ist es, was ich 10 Mal am Tag anschaue. Alles andere befindet sich auf einer „Details“-Seite, die ich nur beim Debuggen einsehe.
Die Konfiguration
Daten sammeln: Ich habe ein kleines Skript geschrieben, das die OpenClaw-Logs analysiert und die Metriken im Prometheus-Format bereitstellt. Es läuft als Hintergrundprozess und extrahiert die Logdatei alle 30 Sekunden. Etwa 50 Zeilen Code. Nichts Aufwendiges.
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 gekennzeichnet: Eingabe/Ausgabe)
– openclaw_process_up (Gauge, 1 oder 0)
Prometheus extrahiert diese Metriken alle 15 Sekunden. Die Standardaufbewahrungsfrist 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 benutze die kostenlose Stufe von Grafana Cloud (10.000 Metriken, was mehr als ausreichend ist). Sie können Grafana auch selbst auf demselben Server hosten – es ist leichtgewichtig.
Gesamtzeit für die Einrichtung: etwa 2 Stunden beim ersten Mal. Der Großteil der Zeit wurde mit dem Schreiben des Log-Parsers verbracht.
Die Alarme, die funktionieren
Ich habe vier Alarme. Ich habe ihre Schwellenwerte drei Monate lang angepasst, um falsche positive Meldungen zu minimieren:
Prozess > 2 Minuten im Leerlauf. Aktiviert, wenn die ein/aus-Überprüfung zwei aufeinanderfolgende Minuten lang fehlschlägt. Zwei Minuten bieten genügend Spielraum für Neustarts und kleine Netzwerkunterbrechungen. Dies sendet eine Push-Benachrichtigung an mein Telefon.
Antwortzeit p95 > 15 Sekunden über 5 Minuten. Eine langsame Antwort hat keine Bedeutung. Fünf Minuten mit konstant langsamen Antworten bedeuten, dass systematisch etwas nicht stimmt. Dies wird auf meinem Slack-Alarmkanal veröffentlicht.
Fehlerquote > 10 % über 3 Minuten. Ich habe dies höher eingestellt als erwartet (10 % anstelle von 5 %), da kurze Ausbrüche von API-Zeitüberschreitungen während der Wartung des Anbieters normal sind. Drei Minuten mit hohen, andauernden Fehlern bedeuten, dass es kein einfaches Ereignis ist. Benachrichtigung auf dem Telefon.
Tägliche Kosten > 3x des gleitenden Durchschnitts. Stündlich überprüft. Fängt unerwünschte Schlaufen und unerwartete Nutzungsmuster ab, bevor sie kostspielig werden. Slack-Alarm nur – dies ist informativ, nicht dringend.
Ich habe zwei Alarme entfernt, die zu laut waren: „Einsamer Anfrage > 30 Sekunden“ (das passierte zu oft bei komplexen Agentenaufgaben) und „Speicherverbrauch > 80 %“ (nicht relevant – Node.js kümmert sich um seine eigene Müllabfuhr, und kurze Spitzen sind normal).
Das Dashboard, das echte Probleme erkannt hat
Februar: Allmähliches Aufblähen des Kontexts. Die Antwortzeiten stiegen in zwei Wochen von 2,5 s auf 7 s. Der Trend war auf dem Dashboard offensichtlich – die einzelnen Anfragen schienen korrekt, aber der tägliche Durchschnitt stieg. Grundursache: Die Gesprächskontexte wuchsen, weil die Verdichtung nicht korrekt ausgelöst wurde. Ein Konfigurationsfix brachte die Antwortzeiten innerhalb einer Stunde wieder auf Normalniveau.
März: Kostenanstieg durch eine Schleife. Ein Cron-Job hatte einen Retry-Mechanismus, der aufgrund eines Bugs unendlich oft weiter versuchte, wenn die API einen bestimmten Fehlercode zurückgab. Der tägliche Kostenalarm wurde bei 2x des Durchschnitts ausgelöst. Ich habe ihn in weniger als 2 Stunden bemerkt. Ohne den Alarm hätte es weitergemacht, bis das API-Kontingent erreicht war.
März: Lautloser Cron-Ausfall. Mein täglicher Bericht-Jobb hörte auf, ausgeführt zu werden. Keine Fehlermeldung – er wurde einfach nicht ausgeführt. Das Dashboard zeigte, dass der erwartete Aktivitätshöhepunkt um 8 Uhr fehlte. Der Cron-Planer war nach einem Update abgestürzt. Ein Neustart löste das Problem, und ich habe den Alarm für dengestoppten Prozess speziell für den Planer hinzugefügt.
Was ich meinem früheren Ich sagen würde
Beginnen Sie mit den vier Grundmetriken. Fügen Sie Komplexität nur hinzu, wenn Sie einen spezifischen Debugging-Bedarf haben. Die meisten Überwachungsdashboards scheitern, weil sie zu komplex sind – Sie erstellen 20 Panels, werden von den Daten überwältigt und hören komplett auf, das Dashboard zu betrachten.
Das Dashboard, das Sie tatsächlich verwenden, ist besser als das Dashboard, das alles verfolgt. Machen Sie es schnell lesbar, sorgen Sie dafür, dass die Alarme umsetzbar sind, und überprüfen Sie die Schwellenwerte jeden Monat. Das ist die gesamte Strategie.
🕒 Published: