CLI commands
Registri
openclaw logs
Segue in tempo reale i log su file del Gateway tramite RPC (funziona in modalità remota).
Correlati:
- Panoramica della registrazione: Registrazione
- CLI del Gateway: gateway
Opzioni
--limit <n>: numero massimo di righe di log da restituire (predefinito200)--max-bytes <n>: numero massimo di byte da leggere dal file di log (predefinito250000)--follow: segue il flusso dei log--interval <ms>: intervallo di polling durante il follow (predefinito1000)--json: emette eventi JSON delimitati da righe--plain: output in testo semplice senza formattazione stilizzata--no-color: disabilita i colori ANSI--local-time: mostra i timestamp nel tuo fuso orario locale (predefinito)--utc: mostra i timestamp in UTC
Opzioni RPC condivise del Gateway
openclaw logs accetta anche i flag standard del client Gateway:
--url <url>: URL WebSocket del Gateway--token <token>: token del Gateway--timeout <ms>: timeout in ms (predefinito30000)--expect-final: attende una risposta finale quando la chiamata al Gateway è supportata da un agent
Quando passi --url, la CLI non applica automaticamente la configurazione o le credenziali dell'ambiente. Includi --token esplicitamente se il Gateway di destinazione richiede autenticazione.
Esempi
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"Note
- I timestamp vengono mostrati nel tuo fuso orario locale per impostazione predefinita. Usa
--utcper l'output in UTC. - Se il Gateway local loopback implicito richiede l'abbinamento, si chiude durante la connessione o va in timeout prima che
logs.tailrisponda,openclaw logspassa automaticamente al log su file del Gateway configurato. Le destinazioni--urlesplicite non usano questo fallback. openclaw logs --follownon segue i fallback su file configurato dopo errori RPC impliciti del Gateway locale. Su Linux, usa il journal Gateway user-systemd attivo per PID quando disponibile e stampa l'origine del log selezionata; altrimenti continua a ritentare il Gateway live invece di seguire un file affiancato potenzialmente obsoleto.- Quando usi
--follow, le disconnessioni transitorie del gateway (chiusura WebSocket, timeout, caduta della connessione) attivano la riconnessione automatica con backoff esponenziale (fino a 8 tentativi, con limite di 30 s tra i tentativi). A ogni tentativo viene stampato un avviso su stderr e, quando un polling riesce, viene stampato un avviso[logs] gateway reconnected. In modalità--json, sia l'avviso di nuovo tentativo sia la transizione di riconnessione vengono emessi come record{"type":"notice"}su stderr. Gli errori non recuperabili (errore di autenticazione, configurazione errata) terminano comunque immediatamente. - In modalità
--follow --json, le transizioni dell'origine dei log vengono emesse come record{"type":"meta"}. I consumer dovrebbero tracciare i cursori per ognisourceKind: uno stream può passare dall'output su file del Gateway (sourceKind: "file") al fallback sul journal locale (sourceKind: "journal",localFallback: true, conservice.pid/service.unit) e tornare all'output su file del Gateway dopo il ripristino. Non presupporre una singola origine stabile o un singolo cursore per tutta la sessione follow, e tollera righe sovrapposte quando il ripristino riproduce il cursore del file del Gateway.
Correlati
Was this useful?