Diagnostics Flags

Mit Diagnostics Flags kannst du gezielte Debug-Logs aktivieren, ohne überall verbose Logging einzuschalten. Flags sind opt-in und haben keine Auswirkung, solange kein Subsystem sie prüft.

So funktioniert’s

• Flags sind Strings (Groß-/Kleinschreibung egal).
• Du kannst Flags in der Config oder per Umgebungsvariable aktivieren.
• Wildcards werden unterstützt:
  • telegram.* matcht telegram.http
  • * aktiviert alle Flags

Aktivierung per Config

{
  "diagnostics": {
    "flags": ["telegram.http"]
  }
}

Mehrere Flags:

{
  "diagnostics": {
    "flags": ["telegram.http", "gateway.*"]
  }
}

Starte den Gateway nach Änderungen an den Flags neu.

Umgebungsvariable (einmalig)

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload

Alle Flags deaktivieren:

OPENCLAW_DIAGNOSTICS=0

Wo die Logs landen

Flags schreiben Logs in die Standard-Diagnostics-Logdatei. Standardmäßig:

/tmp/openclaw/openclaw-YYYY-MM-DD.log

Falls du logging.file gesetzt hast, nutze diesen Pfad. Logs sind im JSONL-Format (ein JSON-Objekt pro Zeile). Redaction greift weiterhin basierend auf logging.redactSensitive.

Logs extrahieren

Die neueste Logdatei finden:

ls -t /tmp/openclaw/openclaw-*.log | head -n 1

Nach Telegram-HTTP-Diagnostics filtern:

rg "telegram http error" /tmp/openclaw/openclaw-*.log

Oder live beim Reproduzieren mitverfolgen:

tail -f /tmp/openclaw/openclaw-$(date +%F).log | rg "telegram http error"

Bei Remote-Gateways kannst du auch openclaw logs --follow nutzen (siehe /cli/logs).

Hinweise

• Falls logging.level höher als warn gesetzt ist, werden diese Logs möglicherweise unterdrückt. Der Standard info ist in Ordnung.
• Flags kannst du bedenkenlos aktiviert lassen – sie beeinflussen nur das Log-Volumen des jeweiligen Subsystems.
• Mit /logging kannst du Log-Ziele, Level und Redaction ändern.