Zum Hauptinhalt springen
OpenClaw kann ein lokales Diagnose-Zip für Fehlerberichte erstellen. Es kombiniert bereinigten Gateway-Status, Health-Daten, Logs, Konfigurationsform und aktuelle stabilitätsbezogene Ereignisse ohne Payloads. Behandeln Sie Diagnose-Bundles wie Geheimnisse, bis Sie sie geprüft haben. Sie sind darauf ausgelegt, Payloads und Zugangsdaten auszulassen oder zu schwärzen, fassen aber weiterhin lokale Gateway-Logs und hostbezogenen Laufzeitstatus zusammen.

​
Schnellstart

openclaw gateway diagnostics export
Der Befehl gibt den geschriebenen Zip-Pfad aus. Um einen Pfad auszuwählen: 
openclaw gateway diagnostics export --output openclaw-diagnostics.zip
Für Automatisierung: 
openclaw gateway diagnostics export --json

​
Chat-Befehl

Owner können /diagnostics [note] im Chat verwenden, um einen lokalen Gateway-Export anzufordern. Verwenden Sie dies, wenn der Fehler in einer echten Konversation aufgetreten ist und Sie einen kopierbaren Bericht für den Support möchten:
  1. Senden Sie /diagnostics in der Konversation, in der Sie das Problem bemerkt haben. Fügen Sie bei Bedarf eine kurze Notiz hinzu, zum Beispiel /diagnostics bad tool choice.
  2. OpenClaw sendet die Diagnose-Präambel und fordert eine explizite Exec-Genehmigung an. Die Genehmigung führt openclaw gateway diagnostics export --json aus. Genehmigen Sie Diagnosen nicht über eine Allow-All-Regel.
  3. Nach der Genehmigung antwortet OpenClaw mit einem einfügbaren Bericht, der den lokalen Bundle-Pfad, eine Manifest-Zusammenfassung, Datenschutzhinweise und relevante Sitzungs-IDs enthält.
In Gruppenchats kann ein Owner weiterhin /diagnostics ausführen, aber OpenClaw postet die Diagnosedetails nicht zurück in den gemeinsamen Chat. Es sendet die Präambel, Genehmigungsaufforderungen, das Gateway-Exportergebnis und die Aufschlüsselung der Codex-Sitzungen/-Threads über die private Genehmigungsroute an den Owner. Die Gruppe erhält nur einen kurzen Hinweis, dass der Diagnoseablauf privat gesendet wurde. Wenn OpenClaw keine private Owner-Route finden kann, bricht der Befehl sicher ab und fordert den Owner auf, ihn aus einer Direktnachricht auszuführen. Wenn die aktive OpenClaw-Sitzung den nativen OpenAI Codex-Harness verwendet, deckt dieselbe Exec-Genehmigung auch einen OpenAI-Feedback-Upload für die Codex- Laufzeit-Threads ab, die OpenClaw kennt. Dieser Upload ist vom lokalen Gateway-Zip getrennt und erscheint nur für Codex-Harness-Sitzungen. Vor der Genehmigung erklärt die Aufforderung, dass durch das Genehmigen der Diagnose auch Codex-Feedback gesendet wird, listet aber keine Codex-Sitzungs- oder Thread-IDs auf. Nach der Genehmigung listet die Chat-Antwort die Kanäle, OpenClaw-Sitzungs-IDs, Codex-Thread-IDs und lokalen Resume-Befehle für die Threads auf, die an OpenAI-Server gesendet wurden. Wenn Sie die Genehmigung ablehnen oder ignorieren, führt OpenClaw den Export nicht aus, sendet kein Codex-Feedback und gibt die Codex-IDs nicht aus. Dadurch wird der übliche Codex-Debugging-Ablauf kurz: bemerken Sie das Fehlverhalten in Telegram, Discord oder einem anderen Kanal, führen Sie /diagnostics aus, genehmigen Sie einmal, teilen Sie den Bericht mit dem Support und führen Sie dann lokal den ausgegebenen Befehl codex resume <thread-id> aus, wenn Sie den nativen Codex-Thread selbst prüfen möchten. Siehe Codex-Harness für diesen Prüfablauf.

​
Was der Export enthält

Das Zip enthält:
  • summary.md: menschenlesbare Übersicht für den Support.
  • diagnostics.json: maschinenlesbare Zusammenfassung von Konfiguration, Logs, Status, Health-Daten und Stabilitätsdaten.
  • manifest.json: Exportmetadaten und Dateiliste.
  • Bereinigte Konfigurationsform und nicht geheime Konfigurationsdetails.
  • Bereinigte Log-Zusammenfassungen und aktuelle geschwärzte Log-Zeilen.
  • Bestmögliche Gateway-Status- und Health-Snapshots.
  • stability/latest.json: neuestes persistiertes Stabilitäts-Bundle, sofern verfügbar.
Der Export ist auch nützlich, wenn der Gateway fehlerhaft ist. Wenn der Gateway Status- oder Health-Anfragen nicht beantworten kann, werden die lokalen Logs, die Konfigurationsform und das neueste Stabilitäts-Bundle trotzdem gesammelt, sofern sie verfügbar sind.

​
Datenschutzmodell

Diagnosen sind darauf ausgelegt, teilbar zu sein. Der Export behält Betriebsdaten, die beim Debugging helfen, zum Beispiel:
  • Subsystemnamen, Plugin-IDs, Provider-IDs, Kanal-IDs und konfigurierte Modi
  • Statuscodes, Dauern, Byte-Zähler, Queue-Zustand und Speichermesswerte
  • bereinigte Log-Metadaten und geschwärzte betriebliche Meldungen
  • Konfigurationsform und nicht geheime Feature-Einstellungen
Der Export lässt aus oder schwärzt:
  • Chat-Text, Prompts, Anweisungen, Webhook-Bodys und Tool-Ausgaben
  • Zugangsdaten, API-Schlüssel, Tokens, Cookies und geheime Werte
  • rohe Request- oder Response-Bodys
  • Konto-IDs, Nachrichten-IDs, rohe Sitzungs-IDs, Hostnamen und lokale Benutzernamen
Wenn eine Log-Meldung wie Benutzer-, Chat-, Prompt- oder Tool-Payload-Text aussieht, behält der Export nur bei, dass eine Nachricht ausgelassen wurde, sowie die Byte-Anzahl.

​
Stabilitätsrekorder

Der Gateway zeichnet standardmäßig einen begrenzten Stabilitätsstream ohne Payloads auf, wenn Diagnosen aktiviert sind. Er ist für betriebliche Fakten gedacht, nicht für Inhalte. Derselbe Diagnose-Heartbeat zeichnet Liveness-Samples auf, wenn der Gateway weiterläuft, aber die Node.js-Ereignisschleife oder CPU ausgelastet wirkt. Diese diagnostic.liveness.warning-Ereignisse enthalten Ereignisschleifenverzögerung, Ereignisschleifen- Auslastung, CPU-Kern-Verhältnis, Anzahl aktiver/wartender/eingereihter Sitzungen, die aktuelle Start-/Laufzeitphase, sofern bekannt, aktuelle Phasenabschnitte und begrenzte Labels für aktive/eingereihte Arbeit. Idle-Samples verbleiben in der Telemetrie auf info-Ebene. Liveness-Samples werden nur dann zu Gateway-Warnungen, wenn Arbeit wartet oder eingereiht ist, oder wenn aktive Arbeit mit anhaltender Ereignisschleifenverzögerung überlappt. Vorübergehende Max-Delay-Spitzen während ansonsten gesunder Hintergrundarbeit bleiben in Debug-Logs. Sie starten den Gateway nicht von selbst neu. Startphasen geben außerdem diagnostic.phase.completed-Ereignisse mit Wall-Clock- und CPU-Timing aus. Diagnoseereignisse für blockierte eingebettete Läufe setzen terminalProgressStale=true, wenn der letzte Bridge-Fortschritt terminal aussah, etwa ein rohes Response-Item oder Response-Completion-Ereignis, der Gateway den eingebetteten Lauf aber weiterhin als aktiv betrachtet. Den Live-Rekorder prüfen: 
openclaw gateway stability
openclaw gateway stability --type payload.large
openclaw gateway stability --json
Das neueste persistierte Stabilitäts-Bundle nach einem fatalen Exit, Shutdown- Timeout oder Neustartfehler prüfen: 
openclaw gateway stability --bundle latest
Ein Diagnose-Zip aus dem neuesten persistierten Bundle erstellen: 
openclaw gateway stability --bundle latest --export
Persistierte Bundles liegen unter ~/.openclaw/logs/stability/, wenn Ereignisse vorhanden sind.

​
Nützliche Optionen

openclaw gateway diagnostics export \
  --output openclaw-diagnostics.zip \
  --log-lines 5000 \
  --log-bytes 1000000
  • --output <path>: in einen bestimmten Zip-Pfad schreiben.
  • --log-lines <count>: maximale Anzahl bereinigter Log-Zeilen, die einbezogen werden.
  • --log-bytes <bytes>: maximale Log-Bytes, die geprüft werden.
  • --url <url>: Gateway-WebSocket-URL für Status- und Health-Snapshots.
  • --token <token>: Gateway-Token für Status- und Health-Snapshots.
  • --password <password>: Gateway-Passwort für Status- und Health-Snapshots.
  • --timeout <ms>: Timeout für Status- und Health-Snapshots.
  • --no-stability-bundle: Suche nach persistiertem Stabilitäts-Bundle überspringen.
  • --json: maschinenlesbare Exportmetadaten ausgeben.

​
Diagnosen deaktivieren

Diagnosen sind standardmäßig aktiviert. Um den Stabilitätsrekorder und die Sammlung von Diagnoseereignissen zu deaktivieren: 
{
  diagnostics: {
    enabled: false,
  },
}
Das Deaktivieren von Diagnosen reduziert die Detailtiefe von Fehlerberichten. Es wirkt sich nicht auf normales Gateway-Logging aus. Snapshots bei kritischem Speicherdruck sind standardmäßig deaktiviert. Um Diagnose- Ereignisse beizubehalten und zusätzlich den Stabilitäts-Snapshot vor dem OOM zu erfassen: 
{
  diagnostics: {
    memoryPressureSnapshot: true,
  },
}
Verwenden Sie dies nur auf Hosts, die den zusätzlichen Dateisystem-Scan und Snapshot- Schreibvorgang während kritischen Speicherdrucks tolerieren können. Normale Speicherdruckereignisse zeichnen weiterhin RSS, Heap, Schwellenwert und Wachstumsfakten auf, wenn der Snapshot deaktiviert ist.

​
Verwandt