OpenTelemetry eBPF Instrumentation reaches v1.0.0
We’re excited to announce v1.0.0 of OpenTelemetry eBPF Instrumentation—OBI!
OBI brings OpenTelemetry observability to running Linux applications without requiring changes to their source code. It uses eBPF, together with runtime-specific instrumentation, to capture application metrics and traces across services, languages, and frameworks. You can start with request rates, errors, latency, and service dependencies, then build deeper visibility as your needs grow.
This release fulfills the flagship goal we set for 2026: establishing a stable foundation for OBI. It represents a year of expanding instrumentation coverage, improving correctness, strengthening release tooling, and building the compatibility and telemetry migration practices that users need to operate OBI over time.
For users, the most important change is predictability: knowing what to expect from an upgrade and how to move forward when something changes.
OBI 1.0 establishes documented compatibility commitments for configuration and deployment, including Config v2, its generated schema, documented deployment interfaces, and supported environments.
For telemetry, the commitment is a reliable migration path as OBI and OpenTelemetry evolve. OBI emits a mixture of telemetry that follows stable semantic conventions and telemetry whose conventions are still developing. The latter can change as those conventions mature. We will also correct bugs in telemetry that follows stable conventions when its actual behavior does not conform to them.
To make that evolution manageable, OBI describes its telemetry in a Weaver-compatible schema registry. OpenTelemetry Weaver helps us define, validate, and review that telemetry against the conventions it should follow. Published telemetry schemas describe transformations between versions where those changes can be represented, while release notes and migration guidance explain changes that need additional action.
For teams maintaining dashboards, alerts, and processing pipelines, this provides a way to plan upgrades and adapt deliberately. The promise is a supported path forward as telemetry evolves, with the definitions, tooling, and guidance needed to understand and manage that change.
That foundation comes with substantial progress across the project.
Broader visibility into application dependencies. Across the releases leading to 1.0, OBI added instrumentation for systems including MQTT, NATS, AMQP 1.0, MSSQL, Couchbase, Memcached, and Aerospike. For teams operating mixed technology stacks, that means more opportunities to understand database and messaging activity through one instrumentation approach. The support matrix documents coverage, trace propagation capabilities, and limitations for each protocol.
Better traces and more useful service detail. Improvements to HTTP/2 and gRPC propagation strengthened handling of existing connections, multiplexed traffic, and individual stream contexts. Framework route discovery expanded to Django, FastAPI, Flask, Rails, .NET, and several PHP frameworks. Route templates help teams distinguish slow endpoints without turning every unique URL into a separate metric series.
A path from automatic instrumentation to application-specific insight. OBI can capture application-authored spans through supported OpenTelemetry Go Trace API and Auto SDK configurations. Node.js also gained opt-in manual span capture for applications without a registered SDK. These capabilities let developers add detail about business operations while using OBI for the surrounding automatic instrumentation, subject to the documented runtime requirements.
More context for investigating incidents. Trace-log correlation can enrich supported application logs with trace context, helping teams move from a request’s path to the logs associated with it. Mattia Meleleo’s walkthrough of zero-code trace-log correlation shows it working across two services and explains how to enable it. OBI also added runtime metrics across Go, Java, .NET, Node.js, and Python, alongside network measurements such as TCP retransmissions and failed connections. Runtime metrics remain experimental, with availability depending on the runtime and enabled features.
Instrumentation for AI applications. OBI’s coverage expanded to model providers, embeddings, reranking, vector retrieval, and MCP interactions. The work includes tool-call and retrieval instrumentation, along with OpenAI-compatible gateways and native Ollama support. These capabilities help teams investigate AI dependencies alongside the rest of their application. Detailed extraction requires explicit payload-capture and feature configuration; it is not enabled automatically for every deployment.
Much of the work behind 1.0 is less visible than a new protocol, but essential to operating instrumentation. Contributors hardened parsers and corrected lifecycle and export behavior, addressed buffer-safety and connection-disruption bugs, and improved trace-parent relationships. Release tooling added signed artifacts, checksums, and software bills of materials, while validation expanded across kernels and architectures. These investments help users evaluate and operate the software they deploy.
For existing users, Config v2 is the configuration contract for 1.0. Available
since v0.11.0, it includes a generated schema and the obi config validate and
obi config migrate commands. Config v1 remains supported for backward
compatibility, but is frozen and receives no fixes or new features. Follow the
configuration migration guide, review configuration supplied
through environment variables, and compare telemetry in a canary deployment
before rolling out broadly. Users embedding OBI in a Collector should also
review the receiver’s separate v0 release line when
selecting versions.
If you’re new to OBI, start with a representative service on a supported Linux host or Kubernetes cluster. Export to your OpenTelemetry Collector or compatible backend, inspect the resulting metrics and traces, and expand from there. Language agents and manual instrumentation remain valuable when you need application-specific context beyond what OBI can observe automatically.
OBI began with the donation of Grafana Beyla and reached its first alpha release through collaboration across organizations and the wider OpenTelemetry community. That collaboration has carried the project to 1.0.
We want to give special thanks to contributors whose sustained work helped make this milestone possible:
- Nikola Grcevski and Mario Macias, for developing OBI’s instrumentation foundation and extending its runtime support, service discovery, framework integration, and configuration.
- Nimrod Avni, for configuration schema generation, Collector integration, protocol coverage, and the telemetry registry and Weaver validation work.
- Mattia Meleleo, for trace-log correlation, trace-context handling, Go instrumentation improvements, and release preparation.
- Rafael Roquetto, for eBPF infrastructure, buffer handling, parser hardening, and performance improvements.
- Giuseppe Ognibene, for network observability, BPF verifier testing, runtime metrics, and instrumentation and exporter correctness.
- Stephen Lang, for strengthening CI, integration tests, and ARM coverage, alongside application instrumentation improvements.
- Marc Tudurí, for expanding protocol instrumentation, Python asynchronous tracing, and Python and .NET runtime metrics.
- Haibin Zhang, for expanding GenAI instrumentation, including embeddings, reranking, Qwen, and MCP.
Thank you, too, to every community member who contributed code, reviewed changes, improved documentation, reported a bug, or shared experience running OBI. Reproductions, deployment feedback, and questions about unexpected behavior have all helped us build a better project. This release belongs to everyone who helped get it here.
With 1.0 released, we’re turning that momentum toward planning OBI’s work for 2027—and we want you to help shape it.
If there’s an issue you’ve been following, a protocol or runtime you want supported, or a feature that would make OBI more useful in your environment, tell us. Add your use case to an existing issue, open a feature request, or bring your ideas to a SIG eBPF Instrumentation meeting. Tell us what you’re trying to accomplish, what gets in your way today, and what a successful solution would enable.
Try OBI 1.0, share your experience, and help us choose what to build next.