Diagnosedatenexport

OpenClaw kann für Fehlerberichte eine lokale Diagnose-.zip erstellen: bereinigter Gateway- Status, Zustandsprüfung, Protokolle, Konfigurationsstruktur und aktuelle, nutzlastfreie Stabilitätsereignisse.

Behandeln Sie Diagnosepakete bis zur Überprüfung wie Geheimnisse. Nutzlasten und Zugangsdaten werden standardmäßig geschwärzt, das Paket fasst jedoch weiterhin lokale Gateway-Protokolle und den Laufzeitstatus auf Hostebene zusammen.

Schnellstart

openclaw gateway diagnostics export

Gibt den Pfad der erstellten ZIP-Datei aus. So wählen Sie einen Ausgabepfad:

openclaw gateway diagnostics export --output openclaw-diagnostics.zip

Für die Automatisierung:

openclaw gateway diagnostics export --json

Chat-Befehl

Besitzer können in jeder Unterhaltung /diagnostics [note] ausführen, um einen lokalen Gateway-Export als einzelnen, kopierbaren Supportbericht anzufordern:

1. Senden Sie /diagnostics, optional mit einem kurzen Hinweis (/diagnostics bad tool choice).
2. OpenClaw sendet eine Vorbemerkung und fordert eine einmalige ausdrückliche Ausführungsgenehmigung an, durch die openclaw gateway diagnostics export --json ausgeführt wird. Genehmigen Sie Diagnosen nicht über eine Regel, die alles erlaubt.
3. Nach der Genehmigung antwortet OpenClaw mit dem lokalen Paketpfad, einer Zusammenfassung des Manifests, Datenschutzhinweisen und relevanten Sitzungs-IDs.

In Gruppenchats kann ein Besitzer weiterhin /diagnostics ausführen, OpenClaw sendet das Exportergebnis, Genehmigungsaufforderungen und die Aufschlüsselung der Codex-Sitzungen/-Threads jedoch privat an den Besitzer. Die Gruppe sieht nur einen kurzen Hinweis, dass die Diagnosen privat gesendet wurden. Wenn kein privater Kommunikationsweg zum Besitzer vorhanden ist, schlägt der Befehl sicher fehl und fordert den Besitzer auf, ihn in einer Direktnachricht auszuführen.

Wenn die aktive Sitzung das native OpenAI-Codex-System verwendet, deckt dieselbe Ausführungsgenehmigung auch das Hochladen von OpenAI-Feedback für die OpenClaw bekannten Codex-Threads ab. Dieser Upload erfolgt getrennt von der lokalen Gateway-ZIP-Datei und nur bei Sitzungen mit dem Codex-System. Die Genehmigungsaufforderung weist darauf hin, dass eine Genehmigung auch Codex-Feedback sendet, ohne Codex-Sitzungs- oder Thread-IDs aufzuführen. Nach der Genehmigung listet die Antwort Kanäle, OpenClaw-Sitzungs-IDs, Codex-Thread-IDs und lokale Fortsetzungsbefehle für die an OpenAI gesendeten Threads auf. Wird die Genehmigung abgelehnt oder ignoriert, werden der Export, das Hochladen des Codex-Feedbacks und die Liste der Codex-IDs übersprungen.

Dadurch bleibt die Codex-Fehlersuchschleife kurz: Stellen Sie fehlerhaftes Verhalten in einem Kanal fest, führen Sie /diagnostics aus, genehmigen Sie einmalig, teilen Sie den Bericht und führen Sie anschließend den ausgegebenen Befehl codex resume <thread-id> lokal aus, wenn Sie den Thread selbst untersuchen möchten. Siehe Codex-System.

Inhalt des Exports

• summary.md: menschenlesbare Übersicht für den Support.
• diagnostics.json: maschinenlesbare Zusammenfassung von Konfiguration, Protokollen, Status, Zustandsprüfung und Stabilitätsdaten.
• manifest.json: Exportmetadaten und Dateiliste.
• Bereinigte Konfigurationsstruktur und nicht geheime Konfigurationsdetails.
• Bereinigte Protokollzusammenfassungen und aktuelle geschwärzte Protokollzeilen.
• Nach bestem Bemühen erstellte Momentaufnahmen von Gateway-Status und -Zustand.
• stability/latest.json: neuestes gespeichertes Stabilitätspaket, sofern verfügbar.

Der Export ist auch dann nützlich, wenn der Gateway fehlerhaft ist: Wenn Status-/Zustandsabfragen fehlschlagen, werden lokale Protokolle, die Konfigurationsstruktur und das neueste Stabilitätspaket weiterhin erfasst, sofern verfügbar.

Datenschutzmodell

Beibehalten werden: Subsystemnamen, Plugin-IDs, Provider-IDs, Kanal-IDs, konfigurierte Modi, Statuscodes, Zeitspannen, Byte-Anzahlen, Warteschlangenstatus, Speicherwerte, bereinigte Protokollmetadaten, geschwärzte Betriebsmeldungen, Konfigurationsstruktur und nicht geheime Funktionseinstellungen.

Ausgelassen oder geschwärzt werden: Chattext, Prompts, Anweisungen, Webhook-Inhalte, Werkzeugausgaben, Zugangsdaten, API-Schlüssel, Token, Cookies, geheime Werte, unverarbeitete Anfrage-/Antwortinhalte, Konto-IDs, Nachrichten-IDs, unverarbeitete Sitzungs-IDs, Hostnamen und lokale Benutzernamen.

Wenn eine Protokollmeldung wie Text aus Benutzer-, Chat-, Prompt- oder Werkzeugnutzlasten aussieht, hält der Export lediglich fest, dass eine Meldung ausgelassen wurde, sowie deren Byte-Anzahl.

Stabilitätsaufzeichnung

Der Gateway zeichnet standardmäßig einen begrenzten, nutzlastfreien Stabilitätsdatenstrom auf, wenn Diagnosen aktiviert sind. Er erfasst betriebliche Fakten, keine Inhalte.

Derselbe Heartbeat prüft außerdem die Aktivität, wenn die Ereignisschleife oder CPU ausgelastet zu sein scheint, und gibt diagnostic.liveness.warning-Ereignisse mit der Verzögerung der Ereignisschleife, der Auslastung der Ereignisschleife, dem CPU-Kern-Verhältnis, der Anzahl aktiver/wartender/in der Warteschlange befindlicher Sitzungen, der aktuellen Start-/Laufzeitphase (sofern bekannt), aktuellen Phasenzeitspannen und begrenzten Arbeitsbezeichnungen aus. Diese werden nur dann zu Gateway-Protokollzeilen der Stufe warn, wenn Arbeit wartet oder sich in der Warteschlange befindet oder wenn aktive Arbeit mit einer anhaltenden Verzögerung der Ereignisschleife zusammenfällt; andernfalls werden sie mit debug protokolliert. Aktivitätsmessungen im Leerlauf werden weiterhin als Diagnoseereignisse aufgezeichnet, führen für sich allein jedoch niemals zu einer Warnung.

Startphasen geben diagnostic.phase.completed-Ereignisse mit Echtzeit- und CPU-Zeitmessungen aus. Diagnosen blockierter eingebetteter Läufe setzen terminalProgressStale=true, wenn der letzte Fortschritt der Schnittstelle einen Abschluss erkennen ließ (beispielsweise ein unverarbeitetes Antwortelement oder ein Antwortabschlussereignis), der Gateway den eingebetteten Lauf jedoch weiterhin als aktiv betrachtet.

So prüfen Sie die aktive Aufzeichnung:

openclaw gateway stabilityopenclaw gateway stability --type payload.largeopenclaw gateway stability --json

So prüfen Sie das neueste gespeicherte Paket nach einem schwerwiegenden Abbruch, einer Zeitüberschreitung beim Herunterfahren oder einem Startfehler beim Neustart:

openclaw gateway stability --bundle latest

So erstellen Sie aus dem neuesten gespeicherten Paket eine Diagnose-ZIP-Datei:

openclaw gateway stability --bundle latest --export

Gespeicherte Pakete befinden sich unter ~/.openclaw/logs/stability/, sofern Ereignisse vorhanden sind.

Nützliche Optionen

openclaw gateway diagnostics export \  --output openclaw-diagnostics.zip \  --log-lines 5000 \  --log-bytes 1000000

Diagnosen deaktivieren

Diagnosen sind standardmäßig aktiviert. So deaktivieren Sie die Stabilitätsaufzeichnung und die Erfassung von Diagnoseereignissen:

{  diagnostics: {    enabled: false,  },}

Das Deaktivieren der Diagnosen verringert den Detailgrad von Fehlerberichten; die normale Gateway-Protokollierung wird dadurch nicht beeinträchtigt.

Momentaufnahmen bei kritischem Speicherdruck sind standardmäßig deaktiviert. So erfassen Sie zusätzlich zu normalen Diagnoseereignissen die Stabilitätsmomentaufnahme vor einem Speichermangel:

{  diagnostics: {    memoryPressureSnapshot: true,  },}

Verwenden Sie dies nur auf Hosts, die den zusätzlichen Dateisystemscan und das Schreiben der Momentaufnahme bei kritischem Speicherdruck verkraften können. Normale Speicherdruckereignisse zeichnen weiterhin RSS-, Heap-, Schwellenwert- und Wachstumsdaten (rss_threshold, heap_threshold, rss_growth) auf, wenn die Momentaufnahme deaktiviert ist.

Verwandte Themen

• Zustandsprüfungen
• Gateway-CLI
• Gateway-Protokoll
• Protokollierung
• OpenTelemetry-Export – separater Ablauf zum Streamen von Diagnosen an einen Collector