OpenTelemetry’s eBPF tool reaches 1.0, with limits to its zero-code promise

A slow request can cross several services before anyone knows where the time went. Seeing that journey usually requires instrumentation: software that records the request’s progress. OpenTelemetry’s eBPF Instrumentation tool, OBI, offers a starting point for supported Linux applications without asking developers to edit their source code.

The project announced OBI 1.0 on October 30, 2026. The milestone’s central promise is a more predictable foundation for operating the tool, including documented configuration and deployment commitments. It does not mean every signal it produces is now permanently fixed.

Observing the traffic, then naming it

According to the official overview, OBI inspects application executables and the operating system’s networking layer using eBPF. It captures request rates, errors, durations and trace spans—the records that describe parts of a request’s journey. That can expose relationships between services while leaving application code untouched.

The platform boundary is concrete. The documentation lists Linux on amd64 or arm64, BTF kernel support, and root access or the capabilities needed for the enabled features. Kernel support begins at 5.8, with a documented exception for RHEL-family 4.18 systems carrying the required backports. This is not a monitoring agent for every operating system.

Deployment is also a choice. The setup guide offers Kubernetes, Helm, Docker and a standalone process. It specifically warns that automatically assigned service names and URLs may differ from what operators expect, and directs tracing users to route configuration. Capturing activity and giving it useful names are separate jobs.

For example, a team evaluating the tool should check whether the services and routes in its traces match the system it actually operates. Otherwise, a technically successful installation can still leave a confusing map. That is an operational implication of the naming warning, rather than a reported test result.

A stable foundation still needs upgrade work

The release announcement distinguishes configuration compatibility from evolving telemetry conventions. Some conventions remain under development; changes can require migrations. OBI describes its telemetry through a Weaver-compatible registry, with schemas, release notes and migration guidance intended to help operators adapt.

Config v2 is the 1.0 configuration contract. Config v1 remains supported for compatibility but is frozen. The maintainers recommend checking environment-variable configuration and comparing telemetry in a canary deployment before a wider rollout. Existing dashboards and alerts still need attention during an upgrade.

Automatic observation has another boundary: meaning inside the application. The overview says language agents or manual instrumentation remain necessary for custom spans, business events and application-specific attributes that eBPF cannot derive. Seeing a request’s path does not, by itself, explain the business decision made along it.

That leaves a useful adoption question: which missing information can traffic observation recover, and which information must the application explicitly supply? OBI can lower the effort needed to start seeing a system. Teams still have to decide what they need to understand.