Gateway
OpenTelemetry export
OpenClaw exports diagnostics through the official diagnostics-otel plugin
using OTLP/HTTP (protobuf). Logs can also be written as stdout JSONL for
container and sandbox log pipelines. Any collector or backend that accepts
OTLP/HTTP works without code changes. For local file logs, see
Logging.
- Diagnostics events are structured, in-process records emitted by the Gateway and bundled plugins for model runs, message flow, sessions, queues, and exec.
diagnostics-otelsubscribes to those events and exports them as OpenTelemetry metrics, traces, and logs over OTLP/HTTP, and can mirror log records to stdout JSONL.- Provider calls receive a W3C
traceparentheader from the actual current OpenTelemetry model-call span when the provider transport accepts custom headers. Diagnostic IDs remain local correlation keys, and plugin-emitted trace context is not propagated. - Exporters attach only when both the diagnostics surface and the plugin are enabled, so in-process cost stays near zero by default.
This page is an index. OpenTelemetry export is documented on five pages, one per reader job. Open the page that matches your task.
| Page | Read it when |
|---|---|
| Set up OpenTelemetry export | You want to install the plugin, turn export on, check exporter health, or turn it off. |
| OpenTelemetry configuration | You need the diagnostics.otel fields, the OTEL_* variables, or sampling and flush settings. |
| Privacy and trace context | You need to know what content leaves the process, or want to continue an upstream trace. |
| Model calls and exported metrics | You are building dashboards or alerts and need exact metric names and attributes. |
| Exported spans and diagnostic events | You are reading traces or subscribing a plugin to diagnostic events. |
Where each section moved
Every section heading from the previous single-page version keeps its anchor
here, so an existing link such as /gateway/opentelemetry#gateway-rpc still resolves. Each entry
points at the page that now holds the content.
- Quick start
- Signals exported
- Which processes export
- Exporter health
- Configuration reference
- Environment variables
- Continue an upstream WebSocket trace
- Privacy and content capture
- Sampling and flushing
- Model-call observation units
- Claude Code CLI model-call fidelity
- Exported metrics
- Gateway RPC
- Model usage
- Message flow
- Talk
- Queues and sessions
- Session liveness telemetry
- Gateway event-loop observation windows
- Harness lifecycle
- Tool execution and loop detection
- Exec
- Diagnostics internals (memory, payloads, exporter health)
- Exported spans
- Diagnostic event catalog
- Without an exporter
- Disable
Related
- Logging - file logs, console output, CLI tailing, and the Control UI Logs tab
- Gateway logging internals - WS log styles, subsystem prefixes, and console capture
- Diagnostics flags - targeted debug-log flags
- Diagnostics export - operator support-bundle tool (separate from OTEL export)
- Configuration reference - full
diagnostics.*field reference - Prometheus metrics - expose diagnostics as Prometheus text metrics through the diagnostics-prometheus plugin
- Audit history - the audit ledger alongside these traces
Was this useful?