2.6 KiB
2.6 KiB
| read_when | summary | title | x-i18n | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Flag di diagnostica per log di debug mirati | Flag di diagnostica |
|
I flag di diagnostica ti consentono di abilitare log di debug mirati senza attivare il logging verboso ovunque. I flag sono opt-in e non hanno alcun effetto a meno che un sottosistema non li controlli.
Come funziona
- I flag sono stringhe (case-insensitive).
- Puoi abilitare i flag nella configurazione o tramite un override env.
- I caratteri jolly sono supportati:
telegram.*corrisponde atelegram.http*abilita tutti i flag
Abilita tramite configurazione
{
"diagnostics": {
"flags": ["telegram.http"]
}
}
Più flag:
{
"diagnostics": {
"flags": ["telegram.http", "gateway.*"]
}
}
Riavvia il Gateway dopo aver modificato i flag.
Override env (una tantum)
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload
Disattiva tutti i flag:
OPENCLAW_DIAGNOSTICS=0
Dove finiscono i log
I flag emettono log nel file di log di diagnostica standard. Per impostazione predefinita:
/tmp/openclaw/openclaw-YYYY-MM-DD.log
Se imposti logging.file, usa invece quel percorso. I log sono in formato JSONL (un oggetto JSON per riga). La redazione continua ad applicarsi in base a logging.redactSensitive.
Estrai i log
Scegli il file di log più recente:
ls -t /tmp/openclaw/openclaw-*.log | head -n 1
Filtra per la diagnostica HTTP di Telegram:
rg "telegram http error" /tmp/openclaw/openclaw-*.log
Oppure usa tail mentre riproduci il problema:
tail -f /tmp/openclaw/openclaw-$(date +%F).log | rg "telegram http error"
Per i Gateway remoti, puoi anche usare openclaw logs --follow (vedi /cli/logs).
Note
- Se
logging.levelè impostato su un valore più alto diwarn, questi log possono essere soppressi. Il valore predefinitoinfova bene. - I flag sono sicuri da lasciare abilitati; influenzano solo il volume dei log per il sottosistema specifico.
- Usa /logging per cambiare destinazioni dei log, livelli e redazione.