OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

CLI commands

Auditprotokolle

openclaw audit

Fragen Sie das reine Metadaten-Audit-Ledger des Gateways nach Agent-Ausführungen, Tool-Aktionen und optional aktivierten Lebenszyklusdatensätzen für Nachrichten ab.

Das Ledger ist für Ausführungs- und Tool-Ereignisse standardmäßig aktiviert. Setzen Sie audit.enabled: false und starten Sie das Gateway neu, um die Erfassung aller neuen Ereignisse zu beenden. Nachrichtendatensätze sind separat standardmäßig deaktiviert; setzen Sie audit.messages auf direct oder all und starten Sie das Gateway neu, um sie aufzuzeichnen. Vorhandene Datensätze bleiben bis zu ihrem Ablauf (30 Tage) abfragbar.

Das Ledger ist von Unterhaltungstranskripten getrennt: Es erfasst Identität, Reihenfolge, Herkunft, Aktion, Status und normalisierte Ergebniscodes, speichert jedoch niemals Inhalte, und Nachrichtenkennungen erscheinen nur als installationslokale schlüsselbasierte Pseudonyme. Der Audit-Verlauf beschreibt das vollständige Datenmodell, die Datenschutzsemantik, Speicherungs- und Aufbewahrungsgrenzen sowie Abdeckungsbeschränkungen; diese Seite behandelt die Befehlsschnittstelle.

bash
openclaw auditopenclaw audit --agent main --status failedopenclaw audit --session "agent:main:main" --after 2026-07-01T00:00:00Zopenclaw audit --run 8c69f72e-8b11-4c54-98d5-1a3dd67450c3openclaw audit --kind tool_action --limit 50 --jsonopenclaw audit --kind message --direction outbound --channel telegram --json

Filter

  • --agent <id>: exakte Agent-ID
  • --session <key>: exakter Sitzungsschlüssel
  • --run <id>: exakte Ausführungs-ID
  • --kind <kind>: agent_run, tool_action oder message
  • --status <status>: started, succeeded, failed, cancelled, timed_out, blocked oder unknown
  • --direction <direction>: Nachrichtenrichtung, inbound oder outbound
  • --channel <channel>: exakter Nachrichtenkanal
  • --after <timestamp> / --before <timestamp>: inklusiver ISO-Zeitstempel oder Unix-Millisekunden
  • --limit <count>: Seitengröße von 1 bis 500; Standardwert 100
  • --cursor <sequence>: eine vorherige, nach neuesten Einträgen zuerst sortierte Abfrage fortsetzen
  • --json: die begrenzte Seite als JSON ausgeben

Die CLI fragt den versionierten Aktivitäts-RPC ab, sodass ein Befehl das vollständig konfigurierte Ledger anzeigt. Die Textausgabe zeigt Zeit, Art, Richtung, Kanal, Status, Agent, Ausführung und Aktion. Fehlende Nachrichtenherkunft wird als - dargestellt; OpenClaw erfindet keine Agent- oder Ausführungs-IDs. Tool-Aktionen zeigen außerdem den Tool-Namen. Die JSON-Ausgabe enthält nextCursor, wenn eine weitere Seite vorhanden ist. Übergeben Sie diesen Wert an --cursor, um fortzufahren, ohne Datensätze neu zu ordnen, die während der Seitennavigation eintreffen.

Diese Exporte bleiben sensible betriebliche Metadaten, obwohl Nachrichtentexte und unverarbeitete Nachrichtenidentitätsfelder fehlen. Agent-, Sitzungs- und Ausführungs-IDs, Zeitangaben, Kanäle, Ergebnisse und stabile HMAC-Referenzen können Aktivitäten miteinander verknüpfen. Schützen Sie sie mit denselben Zugriffskontrollen und Aufbewahrungsverfahren wie andere betriebliche Datensätze.

Aufgezeichnete Ereignisse

Das Gateway projiziert vertrauenswürdige Lebenszyklusströme auf sechs Aktionen:

  • agent.run.started
  • agent.run.finished
  • tool.action.started
  • tool.action.finished
  • message.inbound.processed
  • message.outbound.finished

Jeder zurückgegebene Datensatz besitzt eine stabile Ereignis-ID, eine monoton ansteigende Ledger- Sequenz, einen Lebenszykluszeitstempel, Akteur, Aktion, Status, eine schemaVersion: 1-Markierung, Quellsequenz und redaction: "metadata_only". Agent-/Sitzungs-/Ausführungsherkunft und ereignisspezifische Felder sind nur vorhanden, wenn die vertrauenswürdige Quelle sie bereitstellt. Nachrichtendatensätze lassen sessionKey und sessionId absichtlich weg, sodass --session nur Ausführungs- und Tool-Datensätze filtert.

Abgeschlossene Ausführungs- und Tool-Datensätze unterscheiden Erfolg, Fehlschlag, Abbruch, Zeitüberschreitung und Richtlinienblockierungen anhand abgeschlossener Status- und Fehlercodes. unknown ist ein explizites nicht erfolgreiches Ergebnis, wenn eine vorgelagerte Laufzeitumgebung kein maßgebliches Endergebnis bereitstellt. Tool-Aufruf-IDs werden nur als stabile Fingerabdrücke exportiert. Tool-Namen müssen dem kompakten, modellseitig sichtbaren Namensvertrag entsprechen; andere Werte werden zu unknown.

Nachrichtendatensätze ergänzen Richtung, Kanal, Unterhaltungsart, Ergebnis und optional Zustellungsart, Fehlerphase, Dauer, Ergebnisanzahl, normalisierten Ursachencode sowie schlüsselbasierte Konto-/Unterhaltungs-/Nachrichten-/Zielpseudonyme. Die aktuelle Eingangsgrenze umfasst akzeptierte Nachrichten, die die zentrale Weiterleitung erreichen, einschließlich zentraler Duplikat- und endgültiger Verarbeitungsergebnisse. Die Ausgangsgrenze schreibt eine abschließende Zeile pro ursprünglicher logischer Antwortnutzlast, die die gemeinsame dauerhafte Zustellung erreicht; Aufteilung und Adapter-Auffächerung werden in resultCount aggregiert. In die Warteschlange eingereihte wiederholbare oder mehrdeutige Sendungen werden erst aufgezeichnet, nachdem eine Bestätigung, eine Dead-Letter-Einstufung oder ein Abgleich das Ergebnis endgültig gemacht hat. Plugin-lokale und direkte Sendepfade, die diese gemeinsamen Grenzen umgehen, werden noch nicht abgedeckt; das Fehlen einer Zeile beweist nicht, dass keine Nachricht existierte.

Das Audit-Ledger ersetzt keine Transkripte, keinen Aufgabenverlauf, keinen Cron-Ausführungsverlauf und keine Protokolle. Es stellt einen kleinen, ausführungsübergreifenden Index für betriebliche Abfragen bereit, ohne Unterhaltungsinhalte in einen weiteren Speicher zu kopieren.

Bei Eingangszeilen misst durationMs die zentrale Weiterleitung, und resultCount zählt finalisierte Tool-, Blockierungs- und Antwortnutzlasten in der Warteschlange. Bei Ausgangszeilen umfasst durationMs die Zustellungsverantwortung bis zu ihrem Abschluss (und damit die Wartezeit in der Warteschlange), während resultCount identifizierte physische Sendungen an die Plattform zählt. deliveryKind beschreibt, sofern vorhanden, die effektive Nutzlast nach Hook- und Rendering-Verarbeitung; unterdrückte und durch Abstürze mehrdeutige Zeilen lassen dieses Feld weg.

Gateway-RPC

audit.activity.list erfordert operator.read und akzeptiert dieselben Filter. Es gibt die benannte V1-Union von Aktivitätsereignissen zurück, einschließlich Datensätzen zu Ausführungen, Tools, eingehenden Nachrichten und ausgehenden Nachrichten.

bash
openclaw gateway call audit.activity.list --params '{"channel":"telegram","limit":50}'

Das Ergebnis ist { "events": AuditActivityEventV1[], "nextCursor"?: string }. Die Ergebnisse werden mit dem neuesten zuerst zurückgegeben und sind auf 500 Datensätze pro Anfrage begrenzt.

Der ausgelieferte RPC audit.list bleibt für ältere Ausführungs-/Tool-Clients unverändert. Wenn audit.activity.list auf einem älteren Gateway nicht verfügbar ist, versucht die CLI audit.list nur dann erneut, wenn jeder angeforderte Filter von dieser älteren Methode unterstützt wird. --kind message, --direction und --channel schlagen auf einem älteren Gateway mit einer Upgrade-Meldung fehl, anstatt stillschweigend verworfen zu werden.

Verwandte Themen

Was this useful?
On this page

On this page