OBI v1.0: Obi v1.0: Making Observability Easier To Scale
Observability Courtney GannonKey takeaways
- OpenTelemetry eBPF Instrumentation collects application traces and metrics without code changes, helping organizations gain visibility into legacy and mixed Linux and Kubernetes environments.
- Version 1.0 establishes a stable, documented configuration model, giving platform and application teams a more predictable basis for rollout, upgrades, and long-term operation.
- The technology works alongside existing OpenTelemetry instrumentation and detects already-instrumented applications, helping organizations avoid duplicate data while extending coverage.
When a service is difficult to instrument, teams often have to choose between investing engineering time in code changes and operating with gaps in their application telemetry. That tradeoff is especially familiar in large Linux and Kubernetes environments, where services span different languages, owners, and stages of modernization.
OpenTelemetry eBPF Instrumentation (OBI) offers another option. It collects application telemetry out of process using eBPF, helping teams gain visibility without adding instrumentation code to each application. OBI v1.0 makes that approach generally available with a stable, documented contract for the configuration and telemetry surfaces teams use to deploy and operate it.
Bring More Services Into View
OBI can help teams establish a baseline of traces and metrics across applications where manual instrumentation is difficult, delayed, or inconsistent. This can be useful when onboarding legacy services, expanding observability across many workloads, or identifying gaps in a mixed environment.
OBI is designed to work alongside OpenTelemetry SDKs and agents. That lets teams use automatic instrumentation to fill gaps while continuing to use existing instrumentation where it provides the detail they need. OBI also detects already-instrumented applications to help avoid duplicate telemetry. See the OBI project documentation for supported environments and instrumentation details.
Make Rollout Behavior Easier To Manage
Adopting an observability capability across teams requires more than collecting data. Operators need configuration they can review, validate, and roll out consistently.
OBI v1 makes Configuration v2 the stable configuration model for both standalone OBI and the OBI Collector receiver. The model uses OpenTelemetry declarative configuration structure for supported providers, while keeping OBI-specific capture settings under the OBI extension. Migration and validation commands help teams move from Configuration v1 and check their v2 files. A canary rollout remains a useful way to compare behavior before expanding a migration. The configuration migration guide covers the process and its limitations.
Set Expectations for Production Use
The v1 milestone defines which documented surfaces are stable, including Configuration v2, supported CLI flags and environment variables, release artifacts, telemetry, and the support matrix. That gives platform and application teams a clearer basis for evaluating upgrades and coordinating changes.
The declarative configuration support is intentionally a defined subset; it does not provide every upstream declarative configuration capability. Configuration v1 remains available for backward compatibility, but it is frozen. Teams should consult the versioning policy and telemetry contract when planning deployments and upgrades.
Start With a Visibility Gap
OBI is a practical starting point when teams need to extend observability across Linux workloads without making application-by-application code changes. It can help reduce the instrumentation work required to establish baseline visibility, while OpenTelemetry provides a common framework for collecting and exporting telemetry.
Explore the OBI v1.0 release and project documentation to see whether OBI fits your environment. For an initial rollout, choose a representative service or workload, validate the configuration, and compare the resulting telemetry with your operational needs.
OBI v1.0 is a step toward making application visibility easier to adopt and more predictable to operate—across teams, services, and stages of modernization.
We’re Looking for Feedback!
Want to talk about OpenTelemetry? Join Antoine Toulme, Product Manager and OpenTelemetry Maintainer, and me, every Monday at 8:30 a.m. PT/11:30 a.m. ET for Observability HQ when we lead and OpenTelemetry drop-in.
You can also meet us and the other Splunk OTel maintainers and contributors at KubeCon North America in Salt Lake City in November. Pop into an Observability HQ and we’ll give you a 20% off discount code for KubeCon!
Related Articles

Introducing ShellSweepPlus: Open-Source Web Shell Detection

Strengthen Your Security Operations in the Era of Agentic AI
