CLI commands
Protokolle
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 Protokolldatenstrom 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 durch einen Agenten gestützt wird
Durch die Angabe von --url werden automatisch angewendete Anmeldedaten aus der Konfiguration übersprungen. Geben Sie --token ausdrücklich an, wenn das Ziel-Gateway eine 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 --utcopenclaw logs --follow --local-timeopenclaw logs --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"Fallback- und Wiederherstellungsverhalten
- Wenn das implizite local loopback Gateway eine Kopplung anfordert, während des Verbindungsaufbaus geschlossen wird oder eine Zeitüberschreitung auftritt, bevor
logs.tailantwortet, greiftopenclaw logsautomatisch auf das konfigurierte Gateway-Dateiprotokoll zurück. Explizite--url-Ziele verwenden diesen Fallback niemals. --followgreift nach einem impliziten lokalen Gateway-RPC-Fehler nicht auf diese konfigurierte Datei zurück – eine veraltete parallel vorhandene Datei könnte bei der fortlaufenden Live-Ausgabe irreführend sein. Unter Linux verwendet es stattdessen, sofern verfügbar, anhand der PID das aktive Benutzer-systemd-Journal des Gateways (die ausgewählte Quelle wird ausgegeben); andernfalls versucht es weiterhin, die Verbindung zum aktiven Gateway herzustellen.- Während
--followlösen vorübergehende Verbindungsabbrüche (Schließen des WebSockets, Zeitüberschreitung, Verbindungsverlust) eine automatische Wiederverbindung mit exponentiellem Backoff aus: bis zu 8 Wiederholungsversuche, mit maximal 30 Sekunden zwischen den Versuchen. Bei jedem Wiederholungsversuch wird eine Warnung auf stderr ausgegeben, und sobald eine Abfrage erfolgreich ist, wird einmal der Hinweis[logs] gateway reconnectedausgegeben. Im Modus--jsonwerden beide als Datensätze vom Typ{"type":"notice"}auf stderr ausgegeben. Nicht behebbare Fehler (Authentifizierungsfehler, fehlerhafte Konfiguration) führen weiterhin zum sofortigen Beenden. - Im Modus
--follow --jsonwerden Wechsel der Protokollquelle als Datensätze vom Typ{"type":"meta"}ausgegeben. Verfolgen Sie Cursor getrennt nachsourceKind: Ein Datenstrom kann von der Gateway-Dateiausgabe (sourceKind: "file") zum lokalen Journal-Fallback (sourceKind: "journal",localFallback: true, mitservice.pid/service.unit) und nach der Wiederherstellung zurück zur Gateway-Dateiausgabe wechseln. Gehen Sie nicht von einer einzigen stabilen Quelle oder einem einzigen Cursor für die gesamte Sitzung aus, und tolerieren Sie sich überschneidende Zeilen, wenn bei der Wiederherstellung der Cursor der Gateway-Datei erneut wiedergegeben wird.
Verwandte Themen
Was this useful?