OpenTelemetry (OTel) is the vendor-neutral standard for distributed tracing — the "one request, many hops, one timeline" view that microservice teams already rely on. For AI systems, the OTel community defines GenAI semantic conventions: standard attribute names for describing model calls, so any OTel-compatible backend can render them meaningfully. Microsoft Foundry's agent-framework tracer emits spans that follow these conventions, which means Claude calls made through the agent framework show up in your tracing backend with the same well-known attribute vocabulary as any other instrumented model.
What the spans contain
Per Microsoft's documentation, the agent-framework tracer's spans carry GenAI semantic-convention attributes including:
| Attribute | Meaning |
|---|---|
gen_ai.provider.name | Which model provider served the call |
gen_ai.request.model | The model requested (e.g. your Claude deployment's model) |
gen_ai.usage.input_tokens | Input tokens consumed by the call |
gen_ai.usage.output_tokens | Output tokens generated |
gen_ai.input.messages / gen_ai.output.messages | The actual prompt and completion content — only when content recording is explicitly enabled |
Token counts on every span are quietly the most valuable part for enterprises: they turn your existing tracing backend into a per-call cost attribution system. A trace showing that one agent run burned most of its tokens in a single retry loop is exactly the kind of insight aggregate metrics cannot give you. One caution — do not assume a formal mapping between the Anthropic usage object's fields and gen_ai.* attributes beyond what Microsoft documents; no vendor publishes such a mapping, so treat the span attributes as the tracer's own accounting.
Content recording is off by default — three env vars to opt in
By default, spans describe calls without recording what was said: no prompts, no completions. Capturing message content requires setting three environment variables:
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=SPAN_AND_EVENT
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental
AZURE_EXPERIMENTAL_ENABLE_GENAI_TRACING=trueOnly with all of these set do gen_ai.input.messages and gen_ai.output.messages appear in your spans. The default-off posture is deliberate, and you should think hard before overriding it in production. Prompts and completions are user data: they can contain customer PII, contract text, source code, or anything else flowing through your application. Once recorded into spans, that content inherits the access controls, retention, and export paths of your tracing pipeline — usually a far larger audience than your application database. A common enterprise pattern is content recording ON in development and staging (where debugging value is highest and data is synthetic) and OFF in production, with targeted, time-boxed exceptions during incidents. See prompt-log content privacy for the general treatment of this problem across platforms.
Routing traces to Log Analytics
Emitting spans is half the job; they need a queryable destination. In the Azure ecosystem the standard sink is a Log Analytics workspace — the same store that receives your Foundry resource's diagnostic logs. Foundry Models resources route telemetry there via diagnostic settings (Microsoft documents log categories including Trace, described as detailed inference call traces, alongside RequestResponse and Audit), and OTel-based application traces flow into the workspace through Azure Monitor's OpenTelemetry ingestion. Once traces land, you query them with KQL and correlate spans against the request-id and apim-request-id headers your application logged per call — the join key between your traces and both vendors' support systems (see the two Foundry correlation IDs). Note that Log Analytics ingestion is billed by volume, and data can take up to 15 minutes to appear, so collect the categories you need rather than everything. The exact exporter wiring depends on your application framework — follow Microsoft's agent-framework tracing guide for the current setup steps.
How this compares across platforms
Foundry's agent-framework tracer is the most complete first-party OTel story among the Claude 3P platforms. AWS ingests OTel GenAI traces into CloudWatch's generative AI observability via the AWS Distro for OpenTelemetry, and Google's only documented OTel hook for Claude on Vertex is an otel_log column on BigQuery request-response logging (see the Vertex OTel log column). Anthropic itself documents no first-party OTel exporter for the Messages API, pointing at partner integrations instead. If standardized tracing of agentic Claude workloads is a hard requirement, Foundry currently has the most direct documented path.
Where to go next
Set up the underlying plumbing with Foundry diagnostic logs and Log Analytics for Claude, then close the loop on spend with CCU billing reconciliation.