The OTel GenAI Attributes Most SDKs Still Ignore (May 2026)
- v1.30 Standardization: OpenTelemetry has formalized GenAI semantic conventions, rendering custom span naming conventions obsolete.
- SDK Wrapper Flaws: Popular auto-instrumentation tools (like early versions of OpenLLMetry) often fail to append the mandatory
gen_ai.systemandgen_ai.request.modelattributes. - OTLP Exporter Dominance: Native OTLP is now the standard for routing traces to platforms like Langfuse, Arize, and Grafana.
- Trace vs. Span: You must clearly delineate the overall application trace from the specific LLM generation span to properly calculate P95 latencies.
OpenTelemetry's GenAI semantic conventions hit v1.30—and most SDK wrappers still emit wrong span names. If you rely on auto-instrumentation libraries, you are likely shipping non-compliant LLM traces that will fail your next observability audit.
For any modern LLM Evals Engineer, telemetry is the lifeblood of production evaluation. Without perfectly structured span attributes, your evaluation pipelines cannot accurately calculate token costs, map multi-agent reasoning loops, or isolate API latency from retrieval latency.
The OpenTelemetry v1.30 GenAI Reality
The days of haphazardly logging JSON payloads to stdout are over. OpenTelemetry (OTel) is the undisputed industry standard for distributed tracing. With the stabilization of the GenAI semantic conventions, enterprises now have a unified schema for LLM observability.
However, adoption is dangerously lagging behind the specification. Many engineering teams install an SDK wrapper, see traces appear in their dashboard, and assume the job is done. They do not realize their span attributes are completely disjointed from the official specification.
Why OpenLLMetry and Traceloop Aren't Always Enough
The OpenLLMetry SDK (maintained by Traceloop) was a massive leap forward for the ecosystem. It provides auto-instrumentation for popular frameworks like LangChain and LlamaIndex. However, treating auto-instrumentation as a black box is a massive mistake.
SDK wrappers frequently fall behind the bleeding-edge OTel spec updates. When new attributes become mandatory in the OTel semantic conventions, auto-instrumentation libraries can take months to update.
You must understand how to manually inject span attributes to maintain compliance and avoid losing critical LLM metric granularity.
Essential LLM Span Attributes You Must Implement
To ship compliant traces, your spans must contain specific genai semantic conventions otel attributes.
- gen_ai.system: Identifies the specific provider (e.g., openai, anthropic, cohere).
- gen_ai.request.model: The exact model version requested by your code (e.g., gpt-4o-2024-05-13).
- gen_ai.response.model: The actual model that served the response, critical for tracking silent API deprecations.
- gen_ai.usage.input_tokens & gen_ai.usage.output_tokens: The foundation for all cost-tracking dashboards.
If your spans are missing these, your downstream evaluation platforms will fail to parse the trace data correctly.
Configuring the OTLP Exporter for Enterprise Stacks
Capturing perfect spans is useless if you cannot route them to your observability backend. This is where the OTLP (OpenTelemetry Protocol) exporter comes in. OTLP is vendor-agnostic.
You configure your application to blast OTLP payloads to a centralized collector, which then fans the data out to your specialized tools. This architecture prevents vendor lock-in.
You can simultaneously send identical LLM traces to Grafana for infrastructure monitoring and to an evaluation platform for quality scoring.
Routing to Langfuse and Arize
Leading evaluation platforms natively accept OTLP ingestion. When configuring the otlp exporter langfuse arize integrations, you simply point your OTLP endpoint to their respective ingestion URLs and pass your API keys as headers.
If you are currently evaluating which backend to send these traces to, check out our comparison of the best LLM evaluation platforms to see how they handle native OTel ingestion.
LLM Observability in Grafana 2026
For platform engineering teams, llm observability grafana 2026 is the ultimate goal. Grafana Tempo effortlessly ingests OTLP traces.
By ensuring your gen_ai span attributes are strictly compliant, you can build Grafana dashboards that dynamically track token burn rates across different microservices.
You can instantly visualize exactly which specific agentic loop is causing your P95 latency spikes, all without leaving your core infrastructure monitoring suite.
Frequently Asked Questions (FAQ)
OpenTelemetry (OTel) is an open-source observability framework that standardizes how telemetry data (traces, metrics, logs) is generated and exported. For LLMs, it ensures that token usage, API latency, and prompt details are captured uniformly, preventing vendor lock-in with proprietary observability tools.
GenAI semantic conventions are the standardized naming rules for LLM telemetry data introduced in OTel v1.30. They dictate exactly how attributes like model names, token counts, and system providers must be labeled within a trace for universal compatibility.
You can manually instrument LangChain by writing custom OTel spans around your chain invocations, or use auto-instrumentation libraries like OpenLLMetry. OpenLLMetry automatically hooks into LangChain’s execution layer and emits spans formatted to OTel standards.
Compliant LLM traces must include attributes such as gen_ai.system (the provider), gen_ai.request.model (the requested model), and token usage attributes like gen_ai.usage.input_tokens. These are critical for downstream cost and performance analysis.
In 2026, leading platforms like Langfuse, Arize AI, Grafana (via Tempo), and Datadog natively support OTLP ingestion. This allows you to point your standard OpenTelemetry exporter directly to their endpoints without using proprietary SDKs.
No. OpenTelemetry is the broad, foundational standard and protocol for all software observability. OpenLLMetry is a specific, open-source project (maintained by Traceloop) that provides auto-instrumentation specifically for LLM frameworks to emit OpenTelemetry-compliant data.
You configure the OpenTelemetry OTLP exporter in your application code to send trace data directly to a Grafana Tempo endpoint. Once ingested, Grafana uses the standardized gen_ai span attributes to build dashboards for latency and token usage.
The OTLP exporter is the standardized mechanism OTel uses to transmit telemetry data. To configure it for Langfuse, you set your OTEL_EXPORTER_OTLP_ENDPOINT to the Langfuse ingestion URL and pass your public/secret keys securely via OTEL_EXPORTER_OTLP_HEADERS.
A trace represents the entire journey of a user request (e.g., a full RAG pipeline execution). A span is a single operation within that trace (e.g., the specific call to the OpenAI API). Metrics are aggregated numerical data, like the average token cost per minute.
By ensuring every LLM API call is wrapped in a discrete OTel span, your backend (like Grafana or Arize) can aggregate the duration of these specific spans. The backend then calculates the P95 latency by finding the duration threshold that 95% of your LLM calls fall below.