OpenTelemetry just moved two hard pieces of observability into stable territory: OpenTelemetry eBPF Instrumentation (OBI) is v1, and the OpenTelemetry Transformation Language (OTTL) reached a stable release inside collector distributions. Put bluntly: you can now collect kernel-granular signals with a stable eBPF API and reliably transform them inside collectors without chasing breaking language changes.
That combination is more than incremental. OBI reaching stable status standardizes how eBPF probes surface traces, metrics, and logs, and OTTL's stability makes in-collector normalization and enrichment a supported operation in the collector distributions teams actually run. The practical consequence is collectors are no longer just high-throughput drains — they're the canonical place to reshape telemetry that originates at the kernel and network level.
Why that matters
eBPF gives you data you couldn't get before: syscall timings, socket-level traces, cross-process context, per-pid/namespace activity with low overhead. Historically, that richness came with two costs: fragile, vendor-specific agents and a combinatorial explosion of cardinality. Making OBI stable removes the "vendor SDK" excuse — there is now a supported, production-grade path for kernel-level telemetry. OTTL's stabilization is the other half: a reliable syntax and semantics for filtering, sampling, and transforming those high-cardinality signals inside the collector, upstream of export to long-term storage or dashboards.
Grafana shipped practical UX improvements the same week — cross-dashboard variables and editable notebooks — that make consuming these richer signals easier for on-call and postmortem workflows. And recent CNCF updates show broader momentum for standardization across the ecosystem, not just in tracing.
Operational fallout (short version)
This is good, but it will bite teams that treat collectors as passive. Two concrete, non-negotiable realities:
- eBPF requires host-level privileges and kernel features. Owning OBI means owning kernel-compat testing, seccomp profile design, capability governance (CAP_BPF and CAP_SYS_ADMIN), and upgrade windows for node images.
- High-cardinality kernel signals demand disciplined sampling and transformation. Without OTTL rules you will blow budgets and dashboards with unfiltered pid/address combinations.
- Collectors now carry more CPU and memory responsibility; expect to move resource class and autoscaling decisions from apps to observability infra.
Do these three things now
- Audit node kernel versions and BPF capability (CAP_BPF and CAP_SYS_ADMIN). If you can't guarantee supported kernels, treat OBI as experimental.
- Add OTTL transforms to CI and run them in replay against realistic traffic to validate sampling rules — not as an afterthought, but as gated infra config. (See our prior write-up on OTTL for specifics.)
- Re-budget collector resources and retention strategy for the inevitable increase in cardinality when kernel signals are included.
This was the right call
Stabilizing both OBI and OTTL is the right move. If the community had left eBPF in vendor SDKs, every operator would end up with brittle heuristics and regex-heavy transforms. With stable APIs and a stable in-collector language, teams can build repeatable, audited transformation pipelines instead of ad-hoc scrubbing at the dashboard layer.
But it's not frictionless. Platform teams that still think of telemetry as "free logs" will be surprised by costs and new trust boundaries: who may deploy eBPF probes, who defines OTTL rules, and how those rules are reviewed. That's where real governance is needed, not another dashboard.
Watch this space over the next year: expect prebuilt OBI+OTTL rule sets from vendors and a handful of common patterns to emerge (network-latency hypertuning, syscall anomaly detection, sidecar-less service maps). The teams that win will be the ones who treat collectors as first-class infra—testing transforms in CI, locking down eBPF rollout, and budgeting for the compute it takes to get observability that actually helps you find the problem.