Claude OTel traces: the Azure Monitor path and Foundry gap

On 14 October 2026 Anthropic moved OpenTelemetry trace export for the Claude Platform into public beta. Every agent turn, model call and tool use can now arrive in your observability tool as a standard OpenTelemetry trace, with latency, token counts and IDs attached. The announcement names twelve partner platforms, from Grafana Cloud and Datadog to Langfuse and Splunk. Azure Monitor is not on the list, and the server-side export does not cover Claude in Microsoft Foundry at all. Both gaps can be bridged. The bridge has a specific shape, a specific set of constraints, and a cost line in Application Insights that you should calculate before you flip the content mode to "Full content".

What shipped on 14 October

Anthropic's OpenTelemetry support now has two halves, and the distinction decides everything that follows for an Azure shop.

SDK tracing runs inside your application. The Claude SDK (Python, TypeScript, C#, Go, Java, PHP and Ruby) emits a client span for each request and each tool the tool runner executes, using the tracer provider your application already registers. Your own OTLP exporter ships the spans wherever you like. The docs list this half as beta on the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry.

API tracing runs on Anthropic's side. You add a destination in the Claude Console (an OTLP/HTTP endpoint plus request headers) and the API itself pushes spans for each model run inside a request, each server tool it executes, and each Managed Agents turn. The supported-platforms line for this half reads "Claude API: beta, Claude Platform on AWS: beta". Foundry is absent. So is Bedrock and Vertex AI.

Put together, the coverage matrix looks like this:

Both halves use attributes from the OpenTelemetry GenAI semantic conventions, and Microsoft's own Foundry tracing uses the same conventions, which is what makes a merged view in Application Insights realistic. One caveat: Microsoft's documentation states that the GenAI conventions have Development status and might change, and Anthropic's SDK note says span and attribute names can change during the beta. Pin SDK versions and treat dashboards as disposable for now.

The two constraints that shape the Azure design

Reading the two sets of docs side by side exposes a mismatch that no amount of portal clicking will resolve.

Constraint one: a Claude destination authenticates with static headers. You give the Console an HTTPS endpoint on port 443 and up to 20 request headers, typically an API key. The API disables the destination if the endpoint returns a 3xx redirect, if its hostname resolves to a non-public IP address, or if every delivery fails for 24 hours. Each delivery must complete the TLS handshake within 5 seconds, return response headers within 5 seconds, and finish within 10 seconds in total. Delivery is at-least-once and best-effort, so the same span can arrive twice and some spans can be lost. A Private Link-only collector is therefore out, and so is anything that sits behind an authentication redirect.

Constraint two: Azure Monitor's native OTLP endpoint wants a Microsoft Entra token. Azure Monitor added direct OTLP ingestion this year. Microsoft's message-centre post from 24 March 2026 announced it as public preview, and the options page updated on 9 October now lists the OpenTelemetry Collector path as generally available, with only the Azure Monitor Agent and AKS add-on paths still in preview. The collector doc is explicit: "The OpenTelemetry Collector requires Microsoft Entra authentication to send data to Azure Monitor." The endpoint is a data collection endpoint URL of the form https://<logs-dce-domain>/datacollectionRules/<dcr-immutable-id>/streams/Microsoft-OTLP-Traces/otlp/v1/traces, and the caller needs the Monitoring Metrics Publisher role on the data collection rule. There is no API-key mode.

Static bearer on one side, rotating Entra token on the other. The conclusion is unavoidable: for API tracing you run a small OpenTelemetry Collector on Azure as a translator. For SDK tracing you do not need one, because the exporter lives in your own process where a managed identity is available. That split gives you three concrete paths.

Path A: Claude Platform with API tracing, Collector on Azure

This is the path for teams calling api.anthropic.com directly, and the only path that captures Managed Agents turns and server-side tool spans. The Collector takes OTLP/HTTP from Anthropic on a public hostname, checks a static bearer token, batches, and forwards to Azure Monitor with an Entra identity.

1. Create an Application Insights resource with OTLP support set to On. The Overview page then shows the data collection rule ID and the traces, logs and metrics endpoint URLs. Pick Sweden Central or another EU region; traces and logs land in the linked Log Analytics workspace.
2. Deploy the OpenTelemetry Collector Contrib image (0.148.0 or later for the current azure_auth syntax) on Azure Container Apps with external ingress and a custom domain. Give the app a managed identity and assign it Monitoring Metrics Publisher on the data collection rule.
3. Protect the receiver with the Collector's bearer-token authentication extension and generate a long random token. That token is the only credential Anthropic will hold.
4. Add the destination in the Claude Console: Provider "Custom", OTLP endpoint URL set to your collector's base URL without /v1/traces, an authorization: Bearer ... header, and content mode Metadata only to start. Scope it to the workspaces you intend to trace.
5. Click Test, look for the anthropic.test span, then filter Application Insights on service.name = claude-platform.

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: bearertokenauth

processors:
  batch:
    timeout: 2s

extensions:
  bearertokenauth:
    token: "${env:CLAUDE_DESTINATION_TOKEN}"
  azure_auth:
    managed_identity: {}
    scopes:
      - https://monitor.azure.com/.default

exporters:
  otlphttp/azuremonitor:
    traces_endpoint: "https://<logs-dce-domain>/datacollectionRules/<dcr-immutable-id>/streams/Microsoft-OTLP-Traces/otlp/v1/traces"
    auth:
      authenticator: azure_auth

service:
  extensions: [bearertokenauth, azure_auth]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/azuremonitor]

Three operational notes. Container Apps terminates TLS on port 443 for you, which satisfies the "HTTPS on port 443" requirement without a reverse proxy. The batch processor keeps you inside Anthropic's 10-second delivery budget: the receiver acknowledges as soon as the span is queued, and the Azure export happens asynchronously. And Anthropic retries on 408, 429 and 5xx responses but not on 401 or 404, so a rotated bearer token silently drops spans until you notice the Delivery column reading Failing. Alert on it, or on a zero-span condition in Log Analytics.

To link the API spans with your own application's traces, call the SDK from inside one of your own spans; the SDK writes the W3C traceparent header and the API nests its spans beneath it. Send both halves to the same Application Insights resource or the join never happens.

Path B: Claude in Foundry with SDK tracing only

If you deploy Claude through Microsoft Foundry, as most of our Swedish clients now do for billing and Entra reasons, the API half is simply unavailable. The Foundry endpoint at {resource}.services.ai.azure.com/anthropic/v1/messages is not a Claude Console organisation, there is no destinations page to configure, and Managed Agents is on the list of Claude features not supported on Foundry anyway. What you can get is the SDK half, which the docs mark as beta on Microsoft Foundry.

The compensation is that you do not need a collector. Your application already has a managed identity, so the Microsoft OpenTelemetry Distro can export straight to Application Insights with Entra authentication. In Python that is the AnthropicFoundry client plus configure_azure_monitor:

from anthropic import AnthropicFoundry
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from azure.monitor.opentelemetry import configure_azure_monitor

credential = DefaultAzureCredential()

# One identity for both ingestion and inference. No keys anywhere.
configure_azure_monitor(
    connection_string="InstrumentationKey=...;IngestionEndpoint=https://swedencentral-0.in.applicationinsights.azure.com/",
    credential=credential,
)

client = AnthropicFoundry(
    resource="example-resource",
    azure_ad_token_provider=get_bearer_token_provider(
        credential, "https://ai.azure.com/.default"
    ),
)

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarise the open incidents"}],
)

Register the tracer provider before the first call, and the SDK's anthropic.messages.create client span appears in the dependencies table with gen_ai.usage.input_tokens and gen_ai.usage.output_tokens as attributes. What you lose versus Path A is the inside view: one span per request rather than one per model run, and no server tool spans. For single-request chat or extraction calls that is an acceptable trade. For deep agent loops it is not, and the fix is to own the loop in code (the tool runner emits a span per client tool) or to run the agent on the Claude Platform with Path A.

One more Foundry-specific detail: the response carries both a request-id and an apim-request-id header. Copy both onto the SDK span as custom attributes. When something goes wrong, Anthropic support wants the first and Microsoft support wants the second.

Path C: the Agent SDK and Claude Code on Azure compute

The Claude Agent SDK is a different animal because it runs the Claude Code CLI as a child process, and the CLI carries its own OpenTelemetry instrumentation. It exports three independent signals, each with its own switch: metrics for tokens, cost and tool decisions, log events for each prompt and tool result, and traces for the agent loop. Traces are beta and need CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 on top of CLAUDE_CODE_ENABLE_TELEMETRY=1.

CLAUDE_CODE_ENABLE_TELEMETRY=1
CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1
OTEL_TRACES_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.internal:4318
OTEL_SERVICE_NAME=invoice-triage-agent
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production
# Short-lived Container Apps jobs: flush faster than the 60 s metrics default
OTEL_METRIC_EXPORT_INTERVAL=1000
OTEL_TRACES_EXPORT_INTERVAL=1000
OTEL_LOGS_EXPORT_INTERVAL=1000

Two Azure-specific traps. The CLI batches and exports on an interval (60 seconds for metrics, 5 seconds for traces and logs), and if a Container Apps job is killed before the flush you lose the tail of the run; lower the intervals as above. And Application Insights "expect and require OTLP metrics with delta temporality and exponential histogram aggregation", so add the cumulativetodelta processor to the collector's metrics pipeline or the token counters will look wrong in the prebuilt dashboards. Here the collector can sit on an internal address, because the CLI is calling out from inside your VNet rather than Anthropic calling in.

Content modes: the GDPR decision hiding in a dropdown

Each destination and each SDK client has a content mode. Metadata only, the default, exports identifiers, timing, status, token counts and the names of your agents, tools and MCP servers. Full content adds the system prompt, every input message and every output message as span attributes: gen_ai.system_instructions, gen_ai.input.messages, gen_ai.output.messages, plus tool arguments and results. Anthropic's own note on the destinations page is the sentence to read out loud in the architecture review: "After delivery, the data is held by the service that you chose, outside Anthropic, under that service's retention and access controls."

Full content at a SaaS observability vendor means a complete copy of your users' conversations in a third-party store, with that vendor as a GDPR Article 28 processor whose data location, retention and sub-processors you must document. If you chose Foundry "Hosted on Azure" precisely because prompts and completions stay inside Azure, switching the SDK to content mode and pointing it at a non-EU endpoint quietly undoes that decision in one environment variable. Zero data retention on the Messages API still allows full-content export (the API holds the content only in memory until delivery), but Managed Agents is not ZDR-eligible, so an agent session traced in full content is retained on two sides.

Our recommendation for Swedish and EU organisations is a two-tier design. Metadata only to any destination, which is enough for cost, latency and failure triage. Full content only into an Application Insights resource in an EU region, with local authentication disabled so that only Entra-authenticated ingestion is accepted, and with the Foundry sensitive-content table restriction applied so that prompt text sits behind a tighter RBAC boundary than the rest of the telemetry. Application Insights keeps a built-in Azure Policy for this ("Application Insights components should block non-Azure Active Directory based ingestion"); assign it in deny mode and the second tier cannot be misconfigured.

The cost math for full content

Application Insights bills on gigabytes ingested into the Log Analytics workspace, and full content changes the span size by orders of magnitude. The default per-span content limit is 0.75 MB, which Anthropic sizes to hold a 200k-token English context; a 1M-token context needs about 4 MB and must be enabled explicitly. A metadata-only span is a few kilobytes at most. Run the arithmetic on your own request volume before you choose a mode:

Multiply the last column by your region's pay-as-you-go price per GB for Analytics Logs and by your retention window, and the RAG row lands in the thousands of kronor per month before anyone has looked at a single trace. A request traced by both the SDK and the API also produces two spans with the same name, so count tokens from one source only (the docs say sum the API's server spans) and budget ingestion for both. The 10-20 percent token savings that Anthropic's announcement attributes to early customers come from reading the metadata, not from storing every prompt.

Decision guide

The Swedish and EU angle

Observability data is personal data when it contains prompts. A support conversation, an HR query or a patient note pasted into a Claude prompt becomes a span attribute in full-content mode. For a Swedish controller that is a new processing activity with a new processor, and it belongs in the Article 30 record alongside the model provider itself. Metadata-only mode largely sidesteps this, which is the strongest argument for making it the organisation-wide default and granting full content per workspace on request.

Entra-only ingestion is an audit answer. NIS2-scope organisations are being asked how telemetry pipelines are authenticated. "Local authentication disabled on the Application Insights resource, Monitoring Metrics Publisher granted to two managed identities, policy assignment in deny mode" is a one-line answer an auditor can verify in the portal. A static API key copied into a SaaS console is not.

The Foundry gap is also a residency gap. Claude in Foundry offers Global Standard and US Data Zone deployments; there is no EU data zone for Claude today, and the server-side trace export does not exist there at all. Teams that want both Azure billing and full server-side traces have to choose, and the choice should be written down as an architecture decision rather than discovered during an incident. Our earlier post on Opus 5.5 in Foundry covers the billing side of that trade; this one covers the observability side.

MCP servers get a free ride. The Messages API now forwards a W3C traceparent in params._meta to MCP servers connected through the MCP connector, and the Python and C# MCP SDKs already read it. With the 2026-07-28 MCP spec deprecating protocol-level logging in favour of OpenTelemetry, an MCP server on Azure Container Apps can now emit its own spans under the API's tool span and land them in the same Application Insights resource. If you build MCP servers for Swedish customers, that is the integration to ship next.

Checklist

• 1. Decide per workload whether you are on the Claude Platform (Path A) or Foundry (Path B). Write the trace coverage you lose on Foundry into the decision record.
• 2. Create an Application Insights resource with OTLP support on, in an EU region, with local authentication disabled and the deny policy assigned.
• 3. For Path A, deploy the Collector on Container Apps with external ingress, bearer-token auth on the receiver and azure_auth on the exporter. Confirm the hostname resolves to a public IP and never redirects.
• 4. Add the destination as metadata-only, scoped to selected workspaces, and alert on the Delivery column or on zero spans per hour.
• 5. For Path B, register the Microsoft OpenTelemetry Distro with a managed identity before the first SDK call and copy request-id and apim-request-id onto the span.
• 6. Run the ingestion arithmetic for full content against your real request volume and context sizes before enabling it anywhere.
• 7. Pin the Claude SDK version and date-stamp your Kusto queries; both the beta and the GenAI conventions can rename attributes.
• 8. Revisit the earlier guides on LLM observability with OpenTelemetry and App Insights and tracing agent decisions and tool calls for the query patterns; the span names changed, the questions did not.