Claude API traces won’t reach a collector on 4318 or a private IP

So you've got an OpenTelemetry Collector humming on 4318 inside the VPC, and Anthropic just shipped trace export for the Claude API. It won't connect. Since 14 October the API can push spans for every Messages API request and Managed Agents session straight to your observability backend, but only to an OTLP/HTTP endpoint on HTTPS port 443, named by a public hostname. We read the setup docs line by line, because the rules that decide whether your traces land at all are buried in the delivery section.

The network rules that decide if anything arrives

Here's the part sysadmins will trip on first. A stock Collector's OTLP/HTTP receiver listens on localhost:4318, per the receiver's own README. Anthropic's page says it plainly: configure that receiver to accept HTTPS on 443, or put a load balancer or reverse proxy in front of it. The docs only describe OTLP/HTTP with protobuf, so a gRPC listener on 4317 is out too.

Then the hostname. The OTLP endpoint URL field wants a hostname, not an IP address, and the API checks what that name resolves to. If it points at an address that isn't public, the destination gets switched off. So a split-horizon DNS name that resolves to 10.x inside your network won't do; Anthropic's servers have to reach it from the internet. That's a real change for teams who keep collectors private and only let agents inside the network talk to them. You'll be opening one ingress path, so give it its own auth header and a rate limit.

Redirects are fatal rather than followed. A 3xx response disables the destination, which matters if your ingress bounces HTTP to HTTPS or adds a trailing slash. Timeouts are tight: the TLS handshake gets 5 seconds, the response headers another 5, and the whole delivery 10 seconds including a resend. The first request of every delivery is gzipped with Content-Encoding: gzip; if your endpoint answers 400 or 415, the API resends uncompressed. Requests carry User-Agent: Claude-Platform, which is handy for a WAF allow rule. Before saving, it's worth pointing our SSL certificate checker at the hostname, since a TLS failure is one of the listed delivery errors.

What the spans contain, and what they don't

By default a destination runs in Metadata only: identifiers, timing, status and token counts, plus names you chose yourself, like agent, tool and MCP server names. Full content adds prompts and responses, in the GenAI semantic convention attributes gen_ai.system_instructions, gen_ai.input.messages and gen_ai.output.messages. Each span holds up to 0.75 MB of content by default. Past that, the API trims it and sets anthropic.content.truncated to true, dropping the system prompt and the earliest messages first. Anthropic says a full 1M-token context needs about 4 MB, so raise the limit only if your backend and every proxy in between accept bodies that big.

Two compliance details stood out. Organisations with a HIPAA, FERPA or K-12 data-handling restriction get metadata only from API destinations whatever mode is set (SDK spans aren't covered by that rule). And zero data retention doesn't block Full content for the Messages API: the API holds the content in memory until delivery. Once it's delivered, though, your backend's retention applies. Managed Agents isn't eligible for zero data retention at all.

We'd start every destination on Metadata only. Full content is great for debugging and for building evals from real traffic, but it copies every prompt into a second system with its own access list. That's a decision for whoever owns your data policy, not a checkbox during setup.

Don't bill from it, and watch the double count

The docs say outright that exported spans aren't a complete record of usage. Delivery is best effort, a lost span can't be resent, and any caller can suppress a request's spans by sending a W3C traceparent header with the sampled flag off. For per-key spend, or to spot a leaked key, Anthropic points you at the Usage API instead. Retries also mean the same span can arrive twice; dedupe on trace ID plus span ID if your backend doesn't.

Token totals have a trap of their own. If you also turn on SDK tracing, a request shows up as two spans named anthropic.messages.create, one of kind CLIENT from the SDK and one of kind SERVER from the API. Sum both and you've doubled your bill on the dashboard. Count the API spans, and don't add cache read or write attributes on top of gen_ai.usage.input_tokens, which already includes them.

One more limit for AWS shops: Claude Platform on AWS doesn't honour the traceparent header yet, so its API spans always start their own traces. I'm not sure how much the best-effort delivery will bite in practice. Anthropic doesn't publish a loss rate, and Grafana's own setup guide calls the integration a public preview where breaking changes may still land. For debugging slow agent runs it looks useful today. For anything an auditor reads, we'd keep the Usage API as the source of truth.

FAQ

Sources: Anthropic, Claude Platform release notes (14 October 2026), OpenTelemetry for the Claude API and Use OpenTelemetry with the Claude API; independent: OpenTelemetry Collector OTLP receiver README and Grafana Cloud setup guide. All read on 15 October 2026.