Monitoring Strategy for Claude Agents: Privacy, Collectors and Reporting APIs

1.Redacted by default: choosing which content to collect

Out of the box, Claude telemetry records the shape of activity, not its content. For prompts and assistant responses, only lengths are recorded. Raw file contents and code snippets are not included in metrics or events. MCP tool names are redacted to the literal "mcp_tool" for user-configured servers. Each extra kind of content is behind its own opt-in variable, so the strategic question is which gates your diagnosis actually needs.

Three details catch people out. First, OTEL_LOG_ASSISTANT_RESPONSES falls back to OTEL_LOG_USER_PROMPTS when unset, so turning on prompts quietly turns on responses as well unless you set the response gate to 0. Second, OTEL_LOG_TOOL_CONTENT writes a span event, so without tracing it collects nothing. Third, raw API bodies imply consent to everything the other gates would reveal. Volume matters too: content attributes are truncated at 60 KB by default, and CLAUDE_CODE_OTEL_CONTENT_MAX_LENGTH can be lowered to cut telemetry volume. Under OAuth, user.email is included in attributes. It goes only to your configured endpoint, never to Anthropic.

Sources12

2.Centralizing collection with managed settings

Across an organization, telemetry is only useful if every machine sends it to the same place. The variables can live in a settings file's env block, and when an administrator sets them in managed settings, Claude Code actively strips conflicting developer settings. Setting OTEL_EXPORTER_OTLP_ENDPOINT removes every developer-set per-signal endpoint. Setting OTEL_EXPORTER_OTLP_PROTOCOL removes developer per-signal protocols. Setting headers or client certificates removes developer endpoint variables too, so those credentials can't be sent to a collector that the administrator didn't choose.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer example-token"
  }
}

There is one gap. Exporter selectors (OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER and the beta OTEL_TRACES_EXPORTER) follow normal per-key precedence. A developer can still switch a signal off or send it to the console exporter, so if coverage has to be guaranteed, pin the selectors in managed settings as well. Also note that Claude Code has no default OTLP protocol. Every otlp exporter you enable needs a protocol set.

Sources12

3.Matching each signal to a backend

Because each signal can have its own endpoint, you don't have to send everything to one tool. The monitoring docs suggest backend types by signal. A full-featured observability platform works for all three, and its advantage is that it can correlate them.

Security auditing is one case for splitting signals. Events such as tool_decision (allowed or denied, and by what), permission_mode_changed, mcp_server_connection and auth can go to a SIEM over the logs endpoint alone. OTEL_LOG_TOOL_DETAILS then records which commands ran and which files were touched.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem.example.com:4318/v1/logs",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-siem-token"
  }
}

Sources1

4.When OpenTelemetry is more than you need

OpenTelemetry gives you per-run detail, but you have to run a collector and a backend. If the question is aggregate (who is using Claude Code, what it costs, whether spend matches the bill), Anthropic's reporting surfaces may be enough. The Claude Code Analytics Admin API sits in between: it offers more detail than the dashboard "without the complexity of the OpenTelemetry integration."

Both Admin APIs authenticate with an Admin API key. Claude Enterprise organizations are the exception: they use an Analytics API key against a different API. Usage-report numbers come from Anthropic's own accounting, which gives precise token counts instead of relying only on counting tokens in responses. That makes them the right source for cost reconciliation, even when OpenTelemetry is already running.

Sources345

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.OTEL_LOG_TOOL_CONTENT=1 puts tool output into log events.Why is that wrong?

   It adds a tool.output span event and requires tracing to be enabled. With metrics and logs alone, it collects nothing.

   Covered in Redacted by default: choosing which content to collect

2. 2.Pinning the OTLP endpoint in managed settings guarantees every machine exports every signal.Why is that wrong?

   The endpoint pin removes developer endpoint overrides, but exporter selectors follow per-key precedence. A developer can still disable a signal unless the selectors are pinned too.

   Covered in Centralizing collection with managed settings

3. 3.The OTLP exporter defaults to grpc if no protocol is set.Why is that wrong?

   Claude Code has no default protocol. You must set OTEL_EXPORTER_OTLP_PROTOCOL or a per-signal protocol for each otlp exporter.

   Covered in Centralizing collection with managed settings

Practise it for real

Turn on Claude Code telemetry locally, including beta traces, and confirm signals reach an OTLP collector

1. 1.export CLAUDE_CODE_ENABLE_TELEMETRY=1

   Why: Telemetry collection is off until this is set.

   You should see: No output yet; nothing exports without an exporter.

2. 2.export OTEL_METRICS_EXPORTER=otlp and OTEL_LOGS_EXPORTER=otlp

   Why: Each signal has its own selector, and you enable only what you need.

   You should see: Metrics and log events are selected for OTLP export.

3. 3.export CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 and OTEL_TRACES_EXPORTER=otlp

   Why: Traces are in beta and need both the beta flag and their own exporter selector. Metrics and logs do not need the flag.

   You should see: Traces are selected for OTLP export alongside metrics and logs.

4. 4.export OTEL_EXPORTER_OTLP_PROTOCOL=grpc and OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

   Why: There is no default protocol, and the endpoint tells the exporter where your collector is. The generic protocol and endpoint apply to all signals.

   You should see: The exporter has a complete destination.

5. 5.export OTEL_METRIC_EXPORT_INTERVAL=10000, then run claude and send a short prompt

   Why: The default metrics interval is 60000 ms. Shortening it for debugging shows data sooner, but reset it for production.

   You should see: Metrics reach the collector roughly every 10 seconds, log events every 5 seconds by default, and trace spans every 5 seconds by default.

6. 6.Look in your collector or backend for data from service.name claude-code, including claude_code.interaction, claude_code.llm_request and claude_code.tool spans

   Why: This confirms each of the three signals arrived, not just that the process started.

   You should see: Metrics, log events and a claude_code.interaction span tree with child llm_request and tool spans are visible.