CLI commands
Protokolle
openclaw logs
Gateway-Dateilogs per RPC verfolgen (funktioniert im Remote-Modus).
Verwandt:
Optionen
--limit <n>: maximale Anzahl der zurückzugebenden Logzeilen (Standard200)--max-bytes <n>: maximale Anzahl von Bytes, die aus der Logdatei gelesen werden (Standard250000)--follow: dem Logstream folgen--interval <ms>: Abfrageintervall während des Folgens (Standard1000)--json: zeilengetrennte JSON-Ereignisse ausgeben--plain: Klartextausgabe ohne gestaltete Formatierung--no-color: ANSI-Farben deaktivieren--local-time: Zeitstempel in Ihrer lokalen Zeitzone darstellen (Standard)--utc: Zeitstempel in UTC darstellen
Gemeinsame Gateway-RPC-Optionen
openclaw logs akzeptiert außerdem die standardmäßigen Gateway-Client-Flags:
--url <url>: Gateway-WebSocket-URL--token <token>: Gateway-Token--timeout <ms>: Timeout in ms (Standard30000)--expect-final: auf eine finale Antwort warten, wenn der Gateway-Aufruf agentengestützt ist
Wenn Sie --url übergeben, wendet die CLI Konfigurations- oder Umgebungs-Anmeldedaten nicht automatisch an. Geben Sie --token explizit an, wenn der Ziel-Gateway Authentifizierung erfordert.
Beispiele
openclaw logsopenclaw logs --followopenclaw logs --follow --interval 2000openclaw logs --limit 500 --max-bytes 500000openclaw logs --jsonopenclaw logs --plainopenclaw logs --no-coloropenclaw logs --limit 500openclaw logs --local-timeopenclaw logs --utcopenclaw logs --follow --local-timeopenclaw logs --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"Hinweise
- Zeitstempel werden standardmäßig in Ihrer lokalen Zeitzone dargestellt. Verwenden Sie
--utcfür UTC-Ausgabe. - Wenn der implizite local loopback Gateway eine Kopplung anfordert, während der Verbindung schließt oder ein Timeout auftritt, bevor
logs.tailantwortet, fälltopenclaw logsautomatisch auf das konfigurierte Gateway-Dateilog zurück. Explizite--url-Ziele verwenden diesen Fallback nicht. openclaw logs --followfolgt konfigurierten Dateifallbacks nach impliziten lokalen Gateway-RPC-Fehlern nicht weiter. Unter Linux verwendet es das aktive user-systemd-Gateway-Journal per PID, sofern verfügbar, und gibt die ausgewählte Logquelle aus; andernfalls versucht es weiter, den Live-Gateway erneut zu erreichen, statt eine potenziell veraltete nebeneinanderliegende Datei zu verfolgen.- Bei Verwendung von
--followlösen vorübergehende Gateway-Verbindungsabbrüche (WebSocket-Schließung, Timeout, Verbindungsabbruch) eine automatische Wiederverbindung mit exponentiellem Backoff aus (bis zu 8 Wiederholungen, begrenzt auf 30 s zwischen Versuchen). Bei jeder Wiederholung wird eine Warnung auf stderr ausgegeben, und ein Hinweis[logs] gateway reconnectedwird ausgegeben, sobald eine Abfrage erfolgreich ist. Im Modus--jsonwerden sowohl die Wiederholungswarnung als auch der Wiederverbindungsübergang als{"type":"notice"}-Datensätze auf stderr ausgegeben. Nicht behebbare Fehler (Authentifizierungsfehler, fehlerhafte Konfiguration) beenden den Prozess weiterhin sofort. - Im Modus
--follow --jsonwerden Logquellen-Übergänge als{"type":"meta"}-Datensätze ausgegeben. Consumer sollten Cursor prosourceKindverfolgen: Ein Stream kann von Gateway-Dateiausgabe (sourceKind: "file") zu lokalem Journal-Fallback (sourceKind: "journal",localFallback: true, mitservice.pid/service.unit) wechseln und nach der Wiederherstellung zurück zur Gateway-Dateiausgabe. Gehen Sie nicht von einer stabilen Quelle oder einem stabilen Cursor für die gesamte Follow-Sitzung aus, und tolerieren Sie überlappende Zeilen, wenn die Wiederherstellung den Gateway-Dateicursor erneut abspielt.
Verwandt
Was this useful?