Diagnose-Flags

Diagnose-Flags ermöglichen gezielte Debug-Logs, ohne überall Verbose-Logging einzuschalten. Flags sind opt-in und haben keine Wirkung, wenn ein Subsystem sie nicht abfragt.

Wie es funktioniert

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

Per Konfiguration aktivieren

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

Mehrere Flags:

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

Starte das Gateway nach Änderung der 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-Diagnose-Logdatei. Standardmäßig:

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

Wenn du logging.file gesetzt hast, nutze stattdessen diesen Pfad. Logs sind JSONL (ein JSON-Objekt pro Zeile). Schwärzung gilt weiterhin basierend auf logging.redactSensitive.

Logs extrahieren

Die neueste Logdatei finden:

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

Nach Telegram-HTTP-Diagnosen filtern:

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

Oder beim Reproduzieren mitverfolgen:

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

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

Hinweise

Wenn logging.level höher als warn gesetzt ist, werden diese Logs möglicherweise unterdrückt. Standard info reicht aus.
Flags können bedenkenlos aktiviert bleiben; sie beeinflussen nur das Log-Volumen für das jeweilige Subsystem.
Nutze /logging, um Log-Ziele, -Levels und Schwärzung anzupassen.