OpenTelemetry has had a remarkable 2026. What started as a project to unify traces, metrics, and logs has grown into something considerably more ambitious — a full observability framework that now spans continuous profiling, GenAI instrumentation, declarative configuration, and a fundamentally new data pipeline architecture. Here’s what’s changed and what it means for teams running telemetry at scale.
Profiles: The Fourth Signal Enters Alpha
The biggest structural change in 2026 is the arrival of Profiles as the fourth OpenTelemetry signal, reaching public alpha in March 2026. Production profiling — continuously capturing low-overhead performance profiles — has been a powerful technique for decades, but the industry lacked a common protocol. Teams using pprof in Go, JFR in Java, or proprietary profilers had no unified way to collect, transport, and analyze profiling data alongside their other telemetry.
OTLP Profiles changes that by defining a unified wire format that round-trips to pprof with zero information loss. The format uses deduplicated stack representations and dictionary tables for efficient encoding, with string dictionary support enabling roughly 40% smaller wire size compared to naive approaches. Profile samples can carry trace_id and span_id attributes, opening up cross-signal correlation — you can now ask “what were the hot code paths for requests at the p99 latency?” and get a real answer.
An eBPF-based profiling agent, donated by Elastic and now shipping as an official OpenTelemetry Collector distribution, provides whole-system continuous profiling on Linux with automatic support for Go, Node.js, .NET, Ruby, and BEAM (Erlang/Elixir) runtimes — no per-application instrumentation required. The collector’s existing processing pipelines handle metrics enrichment and Kubernetes metadata augmentation for profiles the same way they do for traces and logs.
This is still alpha, so don’t bet critical production workloads on it yet. But the signal is real, the tooling is functional, and multiple vendors are already building backend support.
Declarative Configuration Goes Stable
Configuring OpenTelemetry SDKs has historically meant wrangling environment variables — OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_TRACES_SAMPLER, OTEL_RESOURCE_ATTRIBUTES, and dozens more. In March 2026, the declarative configuration specification reached stable 1.0, giving teams a structured YAML-based alternative.
The stable specification covers the JSON schema data model, YAML file representation, in-memory representation, plugin component provider mechanism, and SDK parse-and-create operations. Implementations exist in C++, Go, Java, JavaScript, and PHP, with .NET and Python in development. The Go implementation already powers the Collector’s internal telemetry configuration.
# file_format is the required version identifier
file_format: "1.0"
receivers:
otlp:
protocols:
grpc:
endpoint: "0.0.0.0:4317"
http:
endpoint: "0.0.0.0:4318"
processors:
batch:
timeout: 5s
sending_queue:
num_items: 1000
exporters:
otlp:
endpoint: "otel-collector:4317"
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp]Point the standard OTEL_CONFIG_FILE environment variable at your YAML file and the SDK handles the rest. The specification working group has committed to a “declarative configuration first” approach for future SDK features — new proposals must include their config schema alongside the API design.
GenAI Observability: Standardized LLM Instrumentation
With AI agents making LLM calls, tool invocations, and token exchanges behind every user interaction, observability for GenAI workloads has become critical. The Semantic Conventions for Generative AI provide a standardized way to record these operations as OpenTelemetry spans, metrics, and events.
Each LLM call produces a span with attributes like gen_ai.request.model (e.g., gpt-4o), gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, and gen_ai.response.finish_reasons. Tool calls appear as child execute_tool spans within the agent’s trace tree. When content capture is enabled, the full prompt messages, system instructions, tool schemas, and results are recorded as structured span attributes.
Standardized metrics like gen_ai.client.operation.duration (latency histograms) and gen_ai.client.token.usage (token consumption histograms) work with any OTLP-compatible backend — no vendor-specific dashboards needed. Major coding assistants already emit this telemetry: VS Code Copilot exports traces, metrics, and events for every agent interaction, OpenAI Codex exports OTel metrics for API requests and sessions, and Claude Code exports metrics with trace support in beta.
Adding GenAI instrumentation to your own applications follows the same pattern as any other OpenTelemetry integration. The conventions handle the attribute naming — you just create spans around your LLM calls and populate the standard attributes.
OTel-Arrow Phase 2: Rethinking Pipeline Architecture
The most architecturally ambitious 2026 development is OTel-Arrow Phase 2, published in June 2026. Phase 1 established OTAP (the OpenTelemetry Arrow Protocol) as an efficient transport format. Phase 2 asks a deeper question: what if Apache Arrow is the in-pipeline data representation, not just the wire format?
The OTel-Arrow Dataflow Engine, built in Rust, uses Arrow record batches as its primary internal representation. When telemetry stays on the OTAP path from ingestion through processing to export, the pipeline avoids the expensive OTLP protobuf decode → object-graph materialization → modify → re-encode cycle that dominates CPU cost in traditional pipelines.
The benchmarks are striking. A simple attribute rename operation that costs 92.5% CPU on the Collector at 200K logs/sec (after four rename rules) costs just 6.6% on the Dataflow Engine’s native OTAP path. Batch-size scaling shows the columnar representation at its best: the OTAP path drops from 21% CPU at 256 logs/batch to 7.8% at 4096 logs/batch. The throughput difference is 10–20x between OTAP and OTLP paths on the same runtime — 2.47M logs/sec vs 121K logs/sec on a single core.
The engine’s NUMA-friendly, thread-per-core, shared-nothing architecture achieves near-linear scaling — 14.6x speedup on 16 cores. And critically, its bounded execution model applies backpressure under overload instead of letting memory grow unbounded, making production behavior more predictable.
The Dataflow Engine is incubation-stage — APIs, configuration formats, and operational semantics are still evolving. But it demonstrates a credible path forward for observability pipelines that need to handle the growing volume from AI workloads, richer instrumentation, and broader OTel adoption.
Kubernetes SemConv, CNCF Graduation, and What’s Next
Beyond the headline features, 2026 brought several infrastructure-level advances. The Kubernetes Semantic Conventions reached release candidate status, standardizing how telemetry is enriched with Kubernetes metadata — pod names, container IDs, node labels, namespace information, and deployment topology. This matters because every major observability vendor was doing this differently, making cross-backend queries and vendor migrations painful.
OpenTelemetry also officially graduated from the CNCF, joining Kubernetes, Prometheus, and Envoy as top-level graduated projects. This signals production readiness and long-term governance stability — a meaningful milestone for teams making architectural bets on the framework.
For teams already running OpenTelemetry, the practical path forward is clear: adopt declarative configuration to replace environment-variable sprawl, start testing the eBPF profiling agent in non-critical environments, instrument GenAI workloads with the semantic conventions, and keep an eye on OTel-Arrow as the pipeline architecture matures. The project is moving fast, but each milestone has backwards compatibility baked in — your existing instrumentation keeps working while new capabilities layer on top.