openclaw logs

Gateway-Dateiprotokolle über RPC fortlaufend ausgeben. Funktioniert im Remote-Modus.

Optionen

• --limit <n>: maximale Anzahl zurückzugebender Protokollzeilen (Standard: 200)
• --max-bytes <n>: maximale Anzahl aus der Protokolldatei zu lesender Bytes (Standard: 250000)
• --follow: dem Protokollstream folgen
• --interval <ms>: Abfrageintervall beim Folgen (Standard: 1000)
• --json: zeilengetrennte JSON-Ereignisse ausgeben
• --plain: reine Textausgabe ohne formatierte Darstellung
• --no-color: ANSI-Farben deaktivieren
• --local-time: Zeitstempel in Ihrer lokalen Zeitzone darstellen (Standard)
• --utc: Zeitstempel in UTC darstellen

Gemeinsame Gateway-RPC-Optionen

• --url <url>: Gateway-WebSocket-URL
• --token <token>: Gateway-Token
• --timeout <ms>: Zeitüberschreitung in ms (Standard: 30000)
• --expect-final: auf eine abschließende Antwort warten, wenn der Gateway-Aufruf von einem Agenten ausgeführt wird

Die Übergabe von --url überspringt automatisch angewendete Anmeldedaten aus der Konfiguration; geben Sie --token ausdrücklich an, wenn das Ziel-Gateway eine Authentifizierung erfordert.

Beispiele

openclaw logsopenclaw logs --followopenclaw --dev logs --followopenclaw --profile work logs --followopenclaw logs --follow --interval 2000openclaw logs --limit 500 --max-bytes 500000openclaw logs --jsonopenclaw logs --plainopenclaw logs --no-coloropenclaw logs --utcopenclaw logs --follow --local-timeopenclaw logs --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

Das ausgewählte Stammprofil entspricht der rotierenden Datei des Gateways: Das Standardprofil verwendet openclaw-YYYY-MM-DD.log, während benannte Profile openclaw-<profile>-YYYY-MM-DD.log verwenden (zum Beispiel openclaw-dev-YYYY-MM-DD.log).

Fallback- und Wiederherstellungsverhalten

• Wenn das implizite lokale Loopback-Gateway eine Kopplung anfordert, die Verbindung während des Aufbaus schließt oder eine Zeitüberschreitung eintritt, bevor logs.tail antwortet, greift openclaw logs automatisch auf die konfigurierte Gateway-Protokolldatei zurück. Explizite --url-Ziele verwenden diesen Fallback niemals.
• --follow greift nach einem RPC-Fehler des impliziten lokalen Gateways nicht auf diese konfigurierte Datei zurück – eine veraltete, parallel vorhandene Datei könnte eine aktive fortlaufende Ausgabe verfälschen. Unter Linux wird stattdessen, sofern verfügbar, anhand der PID das aktive Gateway-Journal des Benutzer-systemd verwendet (die ausgewählte Quelle wird ausgegeben); andernfalls wird die Verbindung zum aktiven Gateway weiterhin erneut versucht.
• Während --follow lösen vorübergehende Verbindungsabbrüche (Schließen des WebSockets, Zeitüberschreitung, Verbindungsabbruch) eine automatische Wiederverbindung mit exponentiellem Backoff aus: bis zu 8 Wiederholungsversuche, mit höchstens 30s zwischen den Versuchen. Bei jedem Wiederholungsversuch wird eine Warnung an stderr ausgegeben, und sobald eine Abfrage erfolgreich ist, wird einmalig ein [logs] gateway reconnected-Hinweis ausgegeben. Im --json-Modus werden beide als {"type":"notice"}-Datensätze an stderr ausgegeben. Nicht behebbare Fehler (Authentifizierungsfehler, fehlerhafte Konfiguration) führen weiterhin zum sofortigen Beenden.
• Im --follow --json-Modus werden Wechsel der Protokollquelle als {"type":"meta"}-Datensätze ausgegeben. Verfolgen Sie Cursor für jede sourceKind separat: Ein Stream kann von der Ausgabe der Gateway-Datei (sourceKind: "file") zum Fallback auf das lokale Journal (sourceKind: "journal", localFallback: true, mit service.pid/service.unit) und nach der Wiederherstellung zurück zur Ausgabe der Gateway-Datei wechseln. Gehen Sie nicht davon aus, dass während der gesamten Sitzung eine stabile Quelle oder ein stabiler Cursor verwendet wird, und tolerieren Sie überlappende Zeilen, wenn bei der Wiederherstellung der Cursor der Gateway-Datei erneut abgespielt wird.

Verwandte Themen

• Protokollierungsübersicht
• Gateway-CLI
• CLI-Referenz
• Gateway-Protokollierung