Gateway

Gateway-Protokollierung

Protokollierung

Eine benutzerorientierte Übersicht (CLI + Control UI + Konfiguration) finden Sie unter /logging.

OpenClaw verfügt über zwei Protokollierungsoberflächen:

Konsolenausgabe – was im Terminal bzw. in der Debug-UI angezeigt wird.
Dateiprotokolle – vom Gateway-Logger geschriebene JSON-Zeilen.

Beim Start protokolliert das Gateway das aufgelöste Standard-Agentenmodell sowie die Modusvorgaben, die sich auf neue Sitzungen auswirken:

text

Agentenmodell: openai/gpt-5.6-sol (thinking=medium, fast=on)

thinking stammt vom Standard-Agenten, aus den Modellparametern oder aus der globalen Agentenvorgabe; wenn es nicht festgelegt ist, wird medium angezeigt. fast stammt vom Standard-Agenten oder aus den fastMode-Parametern des Modells.

Dateibasierter Logger

Die standardmäßigen rollierenden Protokolldateien befinden sich unter /tmp/openclaw/ (eine Datei pro Tag) und werden gemäß der lokalen Zeitzone des Gateway-Hosts datiert. Das Standardprofil verwendet openclaw-YYYY-MM-DD.log; benannte Profile verwenden openclaw-<profile>-YYYY-MM-DD.log (zum Beispiel openclaw-dev-YYYY-MM-DD.log). Wenn dieses Verzeichnis unsicher oder nicht beschreibbar ist (falscher Eigentümer, für alle beschreibbar oder ein symbolischer Link), weicht OpenClaw stattdessen auf einen benutzerbezogenen os.tmpdir()/openclaw-<uid>-Pfad aus; unter Windows wird stets dieser Rückfallpfad im temporären Betriebssystemverzeichnis verwendet.
Aktive Protokolldateien werden bei logging.maxFileBytes rotiert (Standard: 100 MB). Dabei werden bis zu fünf nummerierte Archive (.1 bis .5) aufbewahrt und die Ausgabe in einer neuen aktiven Datei fortgesetzt.
Konfigurieren Sie Pfad und Stufe der Protokolldatei über ~/.openclaw/openclaw.json: logging.file, logging.level.
Das Dateiformat besteht aus einem JSON-Objekt pro Zeile.

Die Codepfade für Talk, Echtzeitsprachübertragung und verwaltete Räume verwenden den gemeinsamen Datei-Logger für begrenzte Lebenszyklusdatensätze, die zur betrieblichen Fehlersuche und zum OTLP-Protokollexport vorgesehen sind. Transkripttext, Audiodaten, Turn-IDs, Anruf-IDs und Provider-Element-IDs werden niemals in den Protokolldatensatz kopiert.

Der Tab „Logs“ der Control UI verfolgt diese Datei über das Gateway (logs.tail). Die CLI verfährt ebenso:

bash

openclaw logs --follow

Ausführlichkeit und Protokollstufen

Dateiprotokolle werden ausschließlich durch logging.level gesteuert.
--verbose wirkt sich nur auf die Ausführlichkeit der Konsole (und den WS-Protokollstil) aus – die Stufe der Dateiprotokollierung wird dadurch nicht erhöht.
Um ausschließlich bei ausführlicher Ausgabe verfügbare Details in Dateiprotokollen zu erfassen, setzen Sie logging.level auf debug oder trace.
Die Trace-Protokollierung enthält außerdem diagnostische Zeitübersichten für ausgewählte häufig durchlaufene Codepfade, beispielsweise die Vorbereitung der Plugin-Tool-Factory. Siehe /tools/plugin#slow-plugin-tool-setup.

Konsolenerfassung

Die CLI erfasst console.log/info/warn/error/debug/trace, schreibt sie in Dateiprotokolle und gibt sie weiterhin auf stdout/stderr aus.

Passen Sie die Ausführlichkeit der Konsole unabhängig davon an:

logging.consoleLevel (Standard: info)
logging.consoleStyle (pretty | compact | json; standardmäßig pretty auf einem TTY, andernfalls compact)

Schwärzung

OpenClaw maskiert sensible Tokens, bevor Protokoll- oder Transkriptausgaben den Prozess verlassen. Diese Schwärzungsrichtlinie gilt für Konsolen-, Dateiprotokoll-, OTLP-Protokolldatensatz- und Sitzungstranskript-Textausgaben, sodass übereinstimmende geheime Werte maskiert werden, bevor JSONL-Zeilen oder Nachrichten auf den Datenträger geschrieben werden.

Die Schwärzung sensibler Werte ist immer aktiviert.
logging.redactPatterns: Array aus Regex-Zeichenfolgen (überschreibt die Vorgaben)
- Verwenden Sie reine Regex-Zeichenfolgen (automatisch gi) oder /pattern/flags für benutzerdefinierte Flags.
- Übereinstimmungen werden maskiert, wobei die ersten 6 und letzten 4 Zeichen erhalten bleiben (bei Werten mit mindestens 18 Zeichen); kürzere Werte werden zu ***.
- Die Vorgaben decken gängige Schlüsselzuweisungen, CLI-Flags, JSON-Felder, Bearer-Header, PEM-Blöcke, verbreitete Token-Präfixe von Anbietern sowie Feldnamen für Zahlungszugangsdaten ab (Kartennummer, CVC/CVV, gemeinsam verwendetes Zahlungstoken, Zahlungszugangsdaten).

Sicherheitsgrenzen wie Tool-Aufrufereignisse der Control UI, die Ausgabe von sessions_history, Diagnoseexporte, Provider-Fehler, die Anzeige von Ausführungsgenehmigungen und Gateway-WebSocket-Protokolle werden immer geschwärzt. logging.redactPatterns fügt bereitstellungsspezifische Muster hinzu.

Gateway-WebSocket-Protokolle

Das Gateway gibt WebSocket-Protokollmeldungen in zwei Modi aus:

Normalmodus (ohne --verbose): Nur „interessante“ RPC-Ergebnisse werden ausgegeben – Fehler (ok=false), langsame Aufrufe (Standardschwellenwert: >= 50ms) und Parsing-Fehler.
Ausführlicher Modus (--verbose): Gibt den gesamten WS-Anfrage-/Antwortverkehr aus.

WS-Protokollstil

openclaw gateway unterstützt eine Stilumschaltung pro Gateway:

--ws-log auto (Standard): Der Normalmodus ist optimiert; der ausführliche Modus verwendet eine kompakte Ausgabe.
--ws-log compact: kompakte Ausgabe (gepaarte Anfrage/Antwort) im ausführlichen Modus.
--ws-log full: vollständige Ausgabe pro Frame im ausführlichen Modus.
--compact: Alias für --ws-log compact.

bash

# optimiert (nur Fehler/langsame Aufrufe)openclaw gateway # gesamten WS-Verkehr anzeigen (gepaart)openclaw gateway --verbose --ws-log compact # gesamten WS-Verkehr anzeigen (vollständige Metadaten)openclaw gateway --verbose --ws-log full

Konsolenformatierung (Subsystem-Protokollierung)

Der Konsolenformatierer ist TTY-bewusst und gibt konsistente Zeilen mit Präfixen aus. Subsystem-Logger halten die Ausgabe gruppiert und übersichtlich:

Subsystem-Präfixe in jeder Zeile (z. B. [gateway], [canvas], [tailscale]).
Subsystem-Farben (stabil pro Subsystem, aus dem Namen gehasht) sowie Stufenfarben.
Farben, wenn die Ausgabe ein TTY ist oder die Umgebung wie ein leistungsfähiges Terminal aussieht (TERM/COLORTERM/TERM_PROGRAM); berücksichtigt NO_COLOR und FORCE_COLOR.
Verkürzte Subsystem-Präfixe: Ein führendes Segment gateway/, channels/ oder providers/ wird entfernt; anschließend werden höchstens die letzten 2 verbleibenden Segmente beibehalten (z. B. wird channels/turn/kernel als turn/kernel angezeigt). Bekannte Kanal-Subsysteme (telegram, whatsapp, slack usw.) werden immer auf den reinen Kanalnamen reduziert.
Untergeordnete Logger nach Subsystem (automatisches Präfix + strukturiertes Feld { subsystem }).
logRaw() für QR-/UX-Ausgaben (kein Präfix, keine Formatierung).
Konsolenstile: pretty | compact | json.
Die Konsolenprotokollstufe ist von der Dateiprotokollstufe getrennt (die Datei behält sämtliche Details bei, wenn logging.level auf debug/trace gesetzt ist).
WhatsApp-Nachrichtentexte werden auf Stufe debug protokolliert (verwenden Sie --verbose, um sie anzuzeigen).

Dadurch bleiben Dateiprotokolle stabil, während die interaktive Ausgabe übersichtlich ist.