TL;DR:
- OpenTelemetry eBPF Instrumentation (OBI) hits its first alpha release, bringing zero-code, out-of-process instrumentation to production systems
- OBI instruments at the protocol level using eBPF, so you can capture metrics and traces across all languages and libraries without code changes, restarts, or performance impact
- It works well for getting started quickly or filling gaps in legacy apps, but should be paired with SDK-based instrumentation where you need custom spans or deep trace context
Introduction
Some parts of a system don’t lend themselves to quick instrumentation changes. You might have a production binary that hasn’t been rebuilt in years, or a stack made of several languages where each team manages telemetry differently. In those situations, getting consistent signals often means touching code you’d rather leave alone or coordinating updates across many services.
OpenTelemetry eBPF Instrumentation (OBI) approaches this from the kernel side. It attaches to low-level events, observes protocol traffic, and emits telemetry without requiring any changes to the application itself. No rebuilds, no dependency bumps, no rollout cycles — it runs entirely out-of-process.
The first alpha release is now out, with contributions from engineers at Grafana Labs, Splunk, Coralogix, Odigos, and others. The effort started as Grafana Beyla and moved under the OpenTelemetry umbrella earlier this year. Since then, support for additional protocols has landed, stability at higher load has improved, and the test suite runs noticeably faster.
This post looks at how OBI works, where it fits in an observability setup, and the cases where it’s a practical companion — or temporary substitute — for standard SDK instrumentation.
What OpenTelemetry eBPF Instrumentation Does
OpenTelemetry eBPF Instrumentation (OBI) approaches telemetry collection differently from standard OpenTelemetry SDKs and language agents.
How SDKs and Agents Usually Work
Traditionally, OpenTelemetry captures signals by running inside your application process:
- SDKs are libraries you include in your code. They generate spans/metrics/logs, handle context propagation, and export data to your backend.
- Agents (like Java agents or auto-instrumentation packages) hook into your runtime to wrap frameworks, intercept function calls, and emit telemetry without manual instrumentation.
Both approaches work well and give you detailed, semantically rich data. But they require you to touch the application — add dependencies, configure exporters, roll out updates, or coordinate version bumps across services.
Where OBI Differs
OBI skips all of that. It never runs in the process. Instead, it attaches at the kernel level and inspects protocol traffic — HTTP, gRPC, SQL, Redis, Kafka, and others — as it moves through the network stack.
Because it operates at the protocol layer, OBI can observe almost any service with a single setup command. Java, Go, Python, Node.js, Rust, or an old compiled C binary — if it speaks a supported protocol, OBI can generate metrics and traces for it.
Here’s what that looks like:
No application changes
Your code, env vars, and deployment files stay untouched. OBI hooks into the kernel and captures telemetry automatically. No restarts or rebuilds.
No new dependencies
Since OBI runs out-of-process, there’s no SDK or agent to install. No version upgrades to coordinate and no rebuilds when an SDK gets patched for security issues.
No performance impact on the app
The service doesn’t generate or export telemetry itself. OBI does the work in the kernel, where eBPF programs run with strict performance controls. The app’s CPU and memory footprint stays the same.
Consistent telemetry across every language
OBI keeps emitted signals aligned with the stable OpenTelemetry specification, without needing teams to upgrade SDK versions across different runtimes.
Broad protocol support
HTTP/HTTPS, HTTP/2, gRPC, SQL databases, Redis, MongoDB, Kafka, GraphQL, Elasticsearch, OpenSearch, and AWS S3. Context propagation is automatic across these protocols.
Production-safe by design
If an eBPF program misbehaves, the kernel stops it while the application keeps running normally. That isolation is one of the reasons OBI is safe to run in production environments.
For stacks with little instrumentation — legacy binaries, third-party components, or services that are hard to modify — OBI offers immediate visibility without code changes or coordination across teams.
Should You Use OBI for Everything?
OBI shines in places where traditional instrumentation is hard to apply. It’s great for pulling telemetry out of services you can’t easily modify, and it gives you immediate protocol-level visibility. What it doesn’t try to do is replace everything the OpenTelemetry SDKs offer.
Since OBI works by observing network activity, it can’t create custom spans, attach business attributes, or capture fine-grained context from inside your code — and that’s intentional. It focuses on protocol traffic; SDKs handle application logic.
Here’s where OBI tends to be the strongest:
OBI is a good fit when:
- You have little or no telemetry, or coverage is uneven across services.
- The service is a compiled binary or older application that’s difficult to change.
- The app relies on older libraries with limited or no OpenTelemetry support.
- You want consistent RED metrics and service graphs across environments without waiting for code changes.
OBI can also detect when a service already emits OpenTelemetry signals and will avoid duplicating that data. That makes it safe to roll out in environments where some teams use SDKs and others don’t.
When SDK instrumentation is a better choice:
- Services already use OpenTelemetry SDKs or agents, and the setup works reliably. There’s usually no upside in switching away from existing instrumentation unless you’re chasing specific performance or cost improvements.
- You need custom spans, domain-specific attributes, or context tied directly to business logic.
- The application uses reactive frameworks, Java virtual threads, or complex thread pools, where OBI’s distributed tracing isn’t mature yet.
OBI’s tracing support is strong for some runtimes — Go (HTTP/gRPC), Node.js (HTTP), Python (HTTP), NGINX (HTTP), and PHP (HTTP/FPM). For others, support depends on how the runtime manages threads, event loops, and connections. The distributed tracing documentation has the detailed breakdown.
In short:
OBI is excellent for metrics and service graphs, and it’s a powerful way to instrument systems you can’t touch. For distributed tracing in runtimes with complex threading models, SDK-based instrumentation still gives you broader and more detailed coverage.
Getting Started With OBI
OBI can run standalone, as a Docker image, or as a Kubernetes DaemonSet (or pod sidecar). The getting started guide walks through installation and configuration options.
The project includes integration tests that show working examples across different programming languages, database backends, and cloud services. There's also a Kubernetes test repository with manifests for different deployment patterns.
Once OBI is running, configure it to point at your OpenTelemetry Collector endpoint. From there, telemetry flows like any other OTel-instrumented app. If you're sending data to Last9, the setup is the same — configure the OTLP endpoint, and it works.
Where OBI Fits in Your Observability Setup
OBI is designed for one job: capturing telemetry from services that are hard or slow to instrument through traditional SDKs. It’s not meant to replace existing instrumentation. If a service already emits high-quality OpenTelemetry data, you keep it that way. OBI simply fills the gaps — legacy binaries, third-party components, or workloads you can’t modify easily.
For many teams, rolling out OBI is the quickest way to get baseline visibility across an entire stack. Once that foundation is in place, you can add deeper, application-level instrumentation where it provides value.
In practice, OBI becomes part of the broader instrumentation strategy: protocol-level coverage everywhere, and SDK-based detail where the application needs it.
Next Steps
The official documentation is a good place to start if you want to try OBI. The project has an active community, and the team runs a weekly SIG eBPF Instrumentation community call where you can ask questions and follow what's being developed.
The team is also available on CNCF Slack in #otel-ebpf-instrumentation. You can check out the GitHub repository to track releases or suggest features.
If you want to send OBI data to Last9, you can point it at your project’s OTLP endpoint, and it’ll work straight away. We accept OTLP natively, so there’s nothing special you need to configure on the OBI side.
This is useful when you want protocol-level signals to land in the same place as everything else you’re already collecting. Since our platform treats all OTLP sources the same way, OBI data shows up alongside SDK-based telemetry without needing separate pipelines or formats.
If some services already emit OpenTelemetry data and others don’t, sending OBI output to the same backend keeps things consistent.
If you need the exact steps, the OpenTelemetry docs walk through how to get your OTLP endpoint and credentials!
