OpenTelemetry (OTel) is the vendor-neutral standard for emitting telemetry — traces, metrics, and logs in a common schema that any observability backend can ingest. Enterprises adopt it so that switching from one monitoring vendor to another doesn't mean re-instrumenting every service. Naturally, teams standardizing on OTel ask: where does Claude-on-Vertex traffic plug in?
The documented answer is narrower than most expect. Google's only OTel hook for Claude on Vertex AI is a flag on the request-response logging configuration: enableOtelLogging. When set, each logged call gains an otel_log JSON column — the log record "in OpenTelemetry schema format," written in addition to the default request-response columns — in the same BigQuery table the feature already populates.
Turning it on
The flag lives in the same setPublisherModelConfig REST call that configures logging itself, so all of that feature's constraints apply unchanged: for Anthropic models the configuration is REST-only, it must target a regional endpoint (the global and multi-regional endpoints don't support request-response logging at all), it covers rawPredict/streamRawPredict calls, changes take a few minutes to propagate, and the feature is in Preview. See the setup guide for the full call structure; the relevant fragment is:
{
"publisherModelConfig": {
"loggingConfig": {
"enabled": true,
"samplingRate": 1.0,
"bigqueryDestination": {"outputUri": "bq://PROJECT.DATASET.TABLE"},
"enableOtelLogging": true
}
}
}One structural consequence follows immediately: because the OTel output rides on request-response logging, it is subject to the same samplingRate and the same 10 MB BigQuery row limit as everything else in the table. An OTel record exists only for calls that were sampled and small enough to record.
What the column adds — and what it doesn't
The standard columns already carry the substance: full_request and full_response hold the complete call as queryable JSON (including the usage token counts), metadata holds request latency, and model/api_method/logging_time cover the dimensions (see the schema guide). The otel_log column does not add new facts about the call; its value is format. OTel-schema records can be lifted out of BigQuery and shipped into an OTel-native pipeline — a collector, or any backend that speaks the standard — without you writing a bespoke mapping from Google's table schema. Google's page doesn't enumerate the column's exact contents beyond "OpenTelemetry schema format," so inspect a real row before building on specific field names.
Equally important is what this hook is not: it is not a live exporter. Nothing is pushed to an OTel collector or an OTLP endpoint; records land in a BigQuery table, and getting them into your tracing backend is your export job. It is a log record per call, not a distributed trace — it won't stitch a multi-step agent run into spans. Application-level tracing, if you want it, comes from instrumenting your own code around the AnthropicVertex client.
How this compares across platforms
| Platform | Documented OTel story for Claude traffic |
|---|---|
| Vertex AI | enableOtelLogging → otel_log column in BigQuery (this article) — the only documented hook. |
| Amazon Bedrock | CloudWatch gen-AI observability ingests OTel traces from ADOT-instrumented frameworks; AgentCore telemetry has built-in OTel and GenAI semantic-convention support. |
| Microsoft Foundry | Agent-framework tracing emits spans following the OTel GenAI semantic conventions (token usage attributes; message content opt-in via environment flags). |
| Claude API (1P) | No first-party OTel exporter documented; Anthropic points to partner integrations (e.g. Honeycomb's usage integration, explicitly OpenTelemetry-based). |
The pattern: on AWS and Azure, OTel enters through application-side instrumentation; on Vertex, the only documented hook is platform-side, at rest, in BigQuery. Teams wanting uniform OTel coverage across platforms usually instrument their own client layer everywhere and treat platform hooks like otel_log as a supplementary, server-attested record.
Where to go next
The observability stack pattern covers assembling these pieces into one architecture; Foundry's OTel agent tracing details the Azure side of the comparison.