Observability
Configure DefenseClaw v8 logs, traces, metrics, redaction, local history, and independent export destinations from one observability graph.
DefenseClaw v8 uses one pipeline for audit evidence, security findings, guardrail decisions, agent lifecycle, model/tool activity, platform health, and diagnostics:
agent · guardrail · scan · policy · platform
|
v
bucket collection (logs/traces/metrics)
|
v
canonical record
|
+-------------+--------------+----------------+
| | | |
v v v v
local SQLite select/redact select/redact select/redact
all logs OTLP Splunk HEC Galileo
L/T/M logs tracesCollection happens once; every destination independently selects, redacts, and delivers its own projection.
The source of truth is observability: under config_version: 8. It owns
collection, local retention, resource attributes, sampling, metric policy,
redaction profiles, destination routing, and transport settings. Notification
webhooks remain a separate product surface.
Connector-native OTLP ingress is separate from outbound destination routing.
For Codex, setup writes a connector-scoped bearer and
X-DefenseClaw-Source: codex header for the loopback
/v1/{logs,metrics,traces} endpoints; see the
Codex connector guide for credential, permission, and
teardown behavior.
Full-fidelity defaults
The minimal configuration is:
config_version: 8
observability: {}It resolves to four important defaults:
- all registered logs, traces, and metrics are collected;
- mandatory local SQLite stores every collected log unredacted;
- there is no remote export until a destination is configured;
- an enabled destination with no
sendorroutesexports every bucket and every signal its kind supports, unredacted.
Enabled destinations export full content by default
Full fidelity can include prompts, responses, tool arguments/results, evidence, paths, and identifiers. Apply a redaction profile before sending to a trust boundary that must not receive that content.
Use generated views instead of expanding every default into YAML:
defenseclaw config validate
defenseclaw config show --effective --section observability
defenseclaw config reference observability
defenseclaw observability planBuckets
Every canonical record belongs to one bucket:
| Bucket | What it answers |
|---|---|
compliance.activity | Who or what attempted, applied, rejected, or failed a control-plane change? |
security.finding | What durable risk was found, with status, evidence, and remediation? |
guardrail.evaluation | What runtime inspection ran and what decision did it reach, including clean evaluations? |
enforcement.action | What block, quarantine, disable, approval, or other policy action was attempted/applied? |
model.io | What model operation ran, with permitted content, usage, latency, and outcome? |
tool.activity | What tool ran, with permitted arguments/results, status, and latency? |
asset.scan | What skill/MCP/plugin/source scan ran and how did the scan stage behave? |
asset.lifecycle | How did an asset move through discovery, install, enable, quarantine, restore, or removal? |
network.egress | What outbound operation or egress policy decision occurred? |
agent.lifecycle | How did root agents, subagents, turns, workflows, phases, and executions progress? |
ai.discovery | What AI components and runtimes were discovered? |
telemetry.ingest | What inbound OTLP leaf was accepted, normalized, rejected, or re-exported? |
platform.health | Are gateway, storage, exporters, queues, guardrail, and sidecar healthy? |
diagnostic | What explicit debug/diagnostic fact does not belong to another product bucket? |
Evaluations and findings are not process/summary copies of the same object. A
guardrail evaluation records an inspection and its decision; zero or more durable
security findings may result. An asset scan records the scan operation; findings
remain in security.finding. An asset lifecycle transition also produces an
enforcement.action only when a policy action is attempted.
Destination capabilities and fan-out
| Destination kind | Signals it can receive |
|---|---|
jsonl, console, splunk_hec, http_jsonl | logs |
prometheus | metrics |
otlp | logs, traces, metrics |
| Galileo preset | traces |
This configuration sends everything supported to both destinations:
config_version: 8
observability:
destinations:
- name: engineering
kind: otlp
protocol: grpc
endpoint: otel.example.com:4317
headers:
Authorization: {env: OTEL_AUTHORIZATION}
- name: soc
kind: splunk_hec
endpoint: https://splunk.example.com:8088/services/collector/event
token_env: SPLUNK_HEC_TOKENengineering receives all logs, traces, and metrics. soc receives all logs
because Splunk HEC is logs-only. Both receive unredacted projections because no
policy overrides the default. Local SQLite also receives every collected log.
Adding destinations is fan-out, not failover or a selection of one backend. Each leg has independent filtering, redaction, queueing, delivery, and health.
Narrow a destination
Use concise send for the normal case:
observability:
destinations:
- name: soc
kind: splunk_hec
endpoint: https://splunk.example.com:8088/services/collector/event
token_env: SPLUNK_HEC_TOKEN
send:
signals: [logs]
buckets: [compliance.activity, security.finding, enforcement.action]
redaction_profile: strictUse ordered routes for source/action/severity filters or exclusions:
observability:
destinations:
- name: archive
kind: otlp
protocol: http/protobuf
endpoint: https://otel.example.com
routes:
- name: drop-diagnostics
signals: [logs, traces, metrics]
selector: {buckets: [diagnostic]}
action: drop
- name: high-security
signals: [logs, traces]
selector:
buckets: [security.finding, enforcement.action]
min_severity: HIGH
action: send
redaction_profile: sensitiveRoutes are first-match-wins per destination and signal. Different selector
fields are ANDed; values in one field are ORed. An unmatched record is not sent
to that destination. Supported selectors are buckets, sources, connectors,
actions, event_names, and min_severity.
Collection is earlier and controls runtime cost. If a bucket has
collect.traces: false, no destination route can recreate those traces. A small
SQLite-only mandatory compliance floor survives normal log collection disablement.
Tune bounded delivery
Every optional destination has independent routing, projection, queueing, retry,
and health. JSONL and console accept queue count/byte controls. Splunk HEC, HTTP
JSONL, and OTLP also accept push-batch count/byte/delay controls. Prometheus is
pull-based and rejects batch.
| Field | Default | Bounds |
|---|---|---|
batch.max_queue_size | 2048 | 1..65536 records |
batch.max_queue_bytes | 67108864 | 4198400..268435456 bytes |
batch.max_export_batch_size | 512 | 1..8192, no greater than queue count |
batch.max_export_batch_bytes | 8388608 | 4263936..67108864 encoded bytes |
batch.scheduled_delay_ms | 5000 | 1..600000; Galileo's omitted preset value is 1000 |
timeout_ms | 10000 | positive bounded milliseconds |
If a queue count or byte limit would be exceeded, DefenseClaw drops the newest attempted enqueue, preserves older FIFO work and mandatory SQLite history, and records bounded health telemetry. Sibling destinations continue independently. Transient or ambiguous acknowledgement failures retry the exact immutable projection; a lost acknowledgement can create a duplicate, so consumers use the record ID for deduplication. See the generated configuration reference for kind-specific fields.
Destination failure circuits
Each optional destination signal route (logs, traces, or metrics) has an independent in-memory delivery circuit. By default, three consecutive terminal transient or permanent-payload batches open that route for 30 seconds. A single payload rejection therefore does not suppress later valid telemetry. Authentication and unsafe-endpoint failures open the affected route immediately for 24 hours because retrying unchanged configuration would only repeat expensive or unsafe work.
While a circuit is open, new and already queued work for that route is rejected before adapter delivery and size-estimation work. Sibling signals, destinations, and mandatory local SQLite persistence continue. When cooldown expires, exactly one record is admitted as a half-open recovery probe. Success closes the circuit; another terminal failure reopens it.
Gateway health and defenseclaw doctor expose the circuit state, consecutive
failures, bounded failure class, and open deadline. Transient-open and
half-open states are warnings; an open authentication, permanent-payload, or
unsafe-endpoint circuit is a failed Doctor check.
The circuit is runtime suppression, not a silent policy edit. It does not
rewrite config.yaml or permanently disable a route. Repair the destination
credential or endpoint and reload the gateway. If export is no longer wanted,
disable that named optional route explicitly:
defenseclaw setup observability disable NAMEEdit bucket and redaction policy safely
Bucket names form a closed fourteen-name catalog; operators override collection
or delivery but cannot add names in config.yaml. Back up the source with private
permissions, edit only deliberate overrides, and validate before activation:
defenseclaw config validate
defenseclaw config show --effective --section observability
defenseclaw observability plan
defenseclaw-gateway restart
defenseclaw doctorStop if validation fails. A global or bucket redaction profile also changes local
SQLite. To preserve full-fidelity local history while redacting a remote trust
boundary, apply the profile only to that destination's send or matching route.
Centralized redaction
Use defenseclaw setup redaction for the guided policy editor. The first screen
covers broad policy choices; Show advanced settings? opens bucket collection,
custom profiles, destination policy, and ordered routes. For automation, start
with defenseclaw setup redaction status --json and preview changes with
--dry-run.
Profile none permits governed content without redaction
remove-all can send governed prompts, responses, tool data, evidence, paths,
and identifiers to configured destinations. Use it only when every affected
destination has an approved trust boundary.
defenseclaw setup redaction remove-all --yesThis selects none for every configurable log and trace projection while
leaving the managed enterprise destination locked.
Profile resolution is route, then bucket, then global default, then catalog:
observability:
defaults:
redaction_profile: sensitive
buckets:
model.io:
redaction_profile: content
redaction_profiles:
soc:
extends: sensitive
detectors: [pii, credentials, secrets]
field_classes:
content: detect
evidence: detect
path: hash
credential: removedetect replaces only sensitive substrings; whole redacts the full field;
hash creates a nonreversible same-install correlation token; remove omits;
and preserve retains. See Redaction for built-ins,
field classes, examples, and migration behavior.
A field-processing failure replaces the complete affected field with a safe
fail-closed token and never falls back to raw content. A classification,
projection-context, traversal, or complete-record serialization/size failure
rejects that destination's projection; independently successful destinations
continue. Profile none intentionally preserves content but still enforces
schema, type, size, and serialization limits.
Local history
Exactly one generated local-sqlite destination stores every collected log and
mandatory floor event. It cannot be disabled or filtered:
observability:
local:
path: ~/.defenseclaw/audit.db
judge_bodies_path: ~/.defenseclaw/judge_bodies.db
retention_days: 90retention_days: 0 means retain indefinitely and produces a capacity warning.
Raw judge-body capture is controlled separately by
guardrail.retain_judge_bodies.
Choose an operator view
Local OTel + Grafana
Collector, Loki, Tempo, Prometheus, and Grafana with the complete DefenseClaw dashboard bundle.
Agent360
Prompt-to-outcome lifecycle DAG with distinct session/prompt facts, recursive lineage provenance, per-agent grouped request work with raw terminal drill-down, real collaboration updates, approvals, outcomes, and Tempo traces.
Galileo
Generated rich trace projection for agent, workflow, model, tool, retrieval, and guardrail/judge operations.
Splunk
Logs through HEC plus Splunk Observability Cloud OTLP dashboards and detectors.
Grafana dashboard catalog
Dashboard ownership, data sources, drill-down paths, and empty-state semantics.
The defenseclaw-genai-rich-v1 trace profile preserves root agents, subagents,
turns, workflows, lifecycle/execution/phase IDs, model and tool operations,
retrieval, approvals, guardrail/judge spans, links, events, and stable correlation.
The local-observability-v1 consumer profile protects the Agent360 and bundled
dashboard query contract. If an operator narrows the local destination, plan and
setup output report partial dashboard coverage.
Local dashboards consume the canonical OTEL projection as delivered and do not redact, mask, or hide fields again. DefenseClaw centrally applies the selected profile before export; Grafana displays or links every field present after that projection, including content when the producer supplies it.
Upgrade from v7
Run the normal command:
defenseclaw upgrade --yesThe upgrader backs up the source, converts and validates the complete v8 candidate, preserves narrower v7 collection/routing/redaction behavior, refreshes owned local dashboard assets without resetting data volumes, restarts, and checks health. No separate migration approval or apply command is required. The v8 gateway does not rewrite v7 configuration at startup or run both formats in parallel.
Live v8 observability policy lives in YAML. Ambient DEFENSECLAW_OTEL_*, standard
OTEL_EXPORTER_OTLP_*, and DEFENSECLAW_DISABLE_REDACTION values are upgrade-only
inputs, not runtime routing/redaction controls. YAML names credential environment
references with token_env, bearer_env, or {env: NAME}; secret values stay out
of the source and rendered plan.
See Upgrade DefenseClaw for rollback and verification.
Alert runbooks
These procedures are the canonical targets used by the bundled alert rules. Keep connector IDs, trace IDs, and destination names in incident evidence, but do not paste prompt content, credentials, or raw audit databases into tickets.
Runbook: schema violations
- Open Runtime & Reliability → Schema violations by event type/code in the bundled Grafana dashboard and identify the producing event and violation code.
- Run
defenseclaw doctor,defenseclaw config validate, anddefenseclaw observability plan. Resolve configuration or registry errors before restarting anything. - Inspect correlated gateway or Collector logs without copying event content into the incident. A sustained nonzero count normally indicates that a producer and the generated telemetry registry disagree.
- For a source checkout, run
make telemetry-check,make check-schemas, and the owning producer tests. Roll back an incompatible producer or regenerate and validate its registry change before redeploying.
Runbook: block SLO
- Confirm that the alert window contains real guardrail traffic; an idle histogram is not a latency breach.
- Open Admission block SLO compliance, then pivot through Guardrail Evaluations and Connector Detail for the affected connector and policy.
- Compare regex, AI Defense, judge, policy, and finalization latency to isolate the slow stage or upstream dependency.
- Preserve the configured enforcement action during diagnosis. Change to a fail-open posture only under the incident commander's approved procedure, and retain the connector and trace IDs used to justify that decision.
Runbook: exporter stalled
- Run
defenseclaw observability planand confirm that the named destination is enabled and that its selectors include the expected signals and buckets. - Check
defenseclaw status, the gateway log, and local Collector logs. For a remote destination, also verify DNS, TLS, credentials, and network reachability. - Run
defenseclaw observability destination test <name>. Add--write-probeonly when a bounded delivery write is appropriate; the probe is isolated and does not create normal dashboard traffic. - Inspect that destination's queue, retry, drop, and circuit telemetry. An open
circuit suppresses only that route's adapter work while mandatory local
SQLite and sibling destinations continue. Repair and reload the destination,
or run
defenseclaw setup observability disable <name>when disabling it is the intended policy change.
Runbook: audit sink
For compatibility, this alert can still use the historical audit.sink
metric name. In live config v8 the affected target is a named
observability.destinations entry; there is no live audit_sinks section.
- Identify the
sink_kindand destination name, then inspect its delivered, dropped, retry, and circuit-state telemetry. - Verify its referenced credential, endpoint,
network_safety,send, androuteswithout revealing secret values. - Run
defenseclaw observability destination test <name>; use--write-probeonly for an approved isolated write. - Confirm mandatory local SQLite remains healthy. Repair or disable only the affected optional destination; do not remove local retention or broaden routing/redaction merely to clear the alert.
Common questions
OpenClaw integration
How DefenseClaw integrates with OpenClaw end-to-end — fetch interceptor, before_tool_call hook, correlation headers, plugin-mediated HITL approvals, and the audit loop.
Local observability stack
One-command OpenTelemetry + Loki + Tempo + Prometheus + Grafana stack, pre-wired to the DefenseClaw gateway. Grafana on :3000, dashboards seeded, no manual config.