OpenClaw

About the OpenClaw integration

OpenClaw ships an official diagnostics-otel plugin that exports traces, metrics, and logs over OTLP/HTTP protobuf — exactly what https://ingest.telemetry.dev accepts. Point it at our endpoint with a bearer project API key and every agent run arrives as a trace: harness and run spans wrapping model calls (chat, invoke_agent) and tool executions (execute_tool), all using OpenTelemetry GenAI semantic conventions that telemetry.dev normalizes into model, token, and cost fields automatically. No SDK, no collector, no code changes.

Key features

• Config-only setup: Install one plugin and add a diagnostics.otel block to your OpenClaw config; nothing to wrap or instrument.
• Full agent traces: Model calls, tool executions, and harness lifecycle land as one span hierarchy per run — including turns delegated to Claude Code or Codex CLIs.
• Cache-aware token accounting: gen_ai.usage.* attributes, including cache read and cache creation tokens, drive server-side cost from current model pricing.
• Privacy by default: OpenClaw exports no prompt, response, or tool content unless you opt in with captureContent: true — and telemetry.dev discards content server-side before storage when your project's capture setting is off.
• Metrics and logs too: Token usage, operation duration, queue, and session metrics arrive as time series; structured Gateway logs are one flag away.

Get started

1. Create a telemetry.dev project API key.

2. Install and enable the exporter plugin:

   openclaw plugins install clawhub:@openclaw/diagnostics-otel

3. Point it at telemetry.dev in your OpenClaw config:

   {
     plugins: {
       allow: ["diagnostics-otel"],
       entries: { "diagnostics-otel": { enabled: true } },
     },
     diagnostics: {
       enabled: true,
       otel: {
         enabled: true,
         endpoint: "https://ingest.telemetry.dev",
         protocol: "http/protobuf",
         serviceName: "openclaw-gateway",
         headers: { Authorization: "Bearer <your-api-key>" },
       },
     },
   }

4. Restart the Gateway. Traces and metrics appear in telemetry.dev grouped by provider and model; set diagnostics.otel.logs: true to export logs as well.

Good to know

• Environments: OpenClaw does not set deployment.environment.name, so data lands in your project's default environment. To use an environment-scoped API key, set OTEL_RESOURCE_ATTRIBUTES="deployment.environment.name=production" on the Gateway process.
• Usage counting: OpenClaw reports token usage twice per run — on each openclaw.model.call span and again on a run-level openclaw.model.usage accounting span. telemetry.dev deduplicates per run when computing a trace's totals: each usage field counts a run's per-call spans when they fully report it, and falls back to that run's accounting span otherwise (cost falls back whenever the calls don't report every token kind it prices) — so trace tokens and cost are counted once, even with several runs in one trace or spans arriving in separate export batches.
• Content capture: diagnostics.otel.captureContent: true is what puts prompts and tool arguments on the wire — once set, OpenClaw includes that content in outbound OTLP. telemetry.dev's per-environment capture setting (on by default) controls whether received content is stored, not whether it is transmitted; turning it off discards content at ingest before it is written. System prompts and thinking blocks stay excluded by OpenClaw regardless.
• Sessions: A run is usually its own trace, but not always — Gateway requests carrying a W3C traceparent continue that upstream trace, and nested or delegated runs share their parent's trace. The durable limitation is that OpenClaw exports no session key, session ID, or gen_ai.conversation.id, so separate traces cannot be joined into conversations.