OpenTelemetry eBPF Instrumentation has reached version 1.0, giving platform teams a stable release of a tool designed to capture application metrics and traces from running Linux workloads without source-code changes. The milestone matters for more than its broad protocol list. OBI 1.0 introduces an explicit compatibility model for configuration, deployment interfaces, supported environments, and telemetry evolution. That makes zero-code observability easier to treat as maintained platform infrastructure rather than a clever bootstrap technique.
OBI uses eBPF probes, supplemented by runtime-specific instrumentation, to observe applications and the operating system networking layer. It can produce rate, error, and duration metrics, distributed traces, runtime measurements, service relationships, and network signals, then export them through OpenTelemetry-compatible pipelines. The central promise is immediate visibility across heterogeneous services. The harder operational question has always been what happens after the first successful deployment: whether an upgrade changes metric names, labels, span relationships, or configuration behavior under dashboards and alerts.
Version 1.0 addresses that second question. OpenTelemetry’s announcement emphasizes predictability, supported migration paths, and documented contracts. For organizations evaluating eBPF instrumentation at fleet scale, those commitments may be more consequential than any individual new integration.
Stability is the headline feature
OBI 1.0 establishes compatibility commitments around Config v2, its generated schema, documented deployment interfaces, and the environments the project supports. Config v1 remains available for backward compatibility, but it is frozen: it will receive neither fixes nor new features. The project also provides configuration validation and migration commands, creating a clearer boundary between legacy behavior and the configuration contract that will evolve after 1.0.
This is important because observability agents occupy a sensitive position. They run broadly, often with elevated Linux capabilities, and feed data into alerts, service-level objectives, capacity decisions, and incident workflows. A seemingly minor attribute or naming change can silently split a metric series, break a query, or disconnect a span from the service graph operators expect to see. Installation may be zero-code; lifecycle management never is.
OBI’s answer is not to promise that telemetry will never change. OpenTelemetry semantic conventions continue to mature, especially for newer domains. Instead, the project distinguishes telemetry based on stable conventions from signals whose conventions are still developing. It may also correct output that claims to follow a stable convention but does not actually conform. Published schemas, release notes, and migration guidance are intended to give operators a supported route through those changes.
That is a pragmatic contract. Freezing every metric and span would preserve mistakes and prevent alignment with the wider OpenTelemetry ecosystem. Changing them without a machine-readable description would push all risk onto users. OBI 1.0 aims for a middle course: controlled evolution with artifacts that teams can validate before a rollout.
Telemetry schemas become operational tooling
OBI describes its output in a schema registry compatible with OpenTelemetry Weaver, a tool for defining and validating telemetry against semantic conventions. Where a change can be represented as a transformation, OpenTelemetry telemetry schemas can document the path between versions. Changes requiring operator judgment remain in release and migration guidance.
This approach elevates telemetry definitions from documentation to a testable interface. A platform team can compare what a new OBI build intends to emit with what its collectors, processors, dashboards, and alert rules expect. It also encourages a better release discipline: instrumentation changes can be reviewed as changes to a data contract, not discovered after production graphs look different.
The benefit compounds in Kubernetes environments. A DaemonSet-style deployment can update instrumentation across many nodes and applications at once. That broad reach is OBI’s advantage, but it also magnifies incompatibility. A canary that runs the new configuration against representative services, exports to an isolated pipeline, and compares query results is therefore a core upgrade control rather than optional ceremony.
Broader coverage strengthens the platform case
The releases leading to 1.0 expanded OBI well beyond basic HTTP observation. The current support includes major application languages, HTTP/2 and gRPC, messaging systems such as Kafka, NATS and MQTT, and databases including PostgreSQL, MySQL, Microsoft SQL Server and Redis. Additional client-side coverage reaches systems such as MongoDB, Couchbase, Aerospike, Elasticsearch, and OpenSearch. OBI can also collect selected runtime metrics for Go, Java, .NET, Node.js, and Python.
Several improvements make the data more useful in real incident response. Route discovery covers popular frameworks including Django, FastAPI, Flask, Rails, .NET, and PHP frameworks. Route templates reduce the risk of creating one metric series for every unique URL. Trace-log correlation can add trace context to supported application logs, helping an operator move from a failing request to the relevant log records. Network measurements include signals such as TCP retransmissions and failed connections.
The project has also added instrumentation for AI application dependencies, including model providers, OpenAI-compatible gateways, Ollama, embeddings, reranking, vector retrieval, and Model Context Protocol interactions. Detailed extraction is not simply enabled everywhere; payload capture and relevant features require explicit configuration. That restraint matters because payload instrumentation can introduce privacy, security, and cost concerns that ordinary RED metrics do not.
Together, this coverage supports a platform-level deployment model. A team can establish baseline service maps and request health across mixed runtimes, including services that are difficult to rebuild or whose owners have not yet adopted OpenTelemetry SDKs. But coverage breadth should not be confused with equal depth. The support matrix records protocol-specific propagation capabilities and limitations, and some runtime metrics remain experimental.
OBI does not eliminate application instrumentation
OBI can observe executable behavior, network exchanges, and supported runtime details, but it cannot infer every business operation. It will not automatically know that a span represents a premium customer checkout, a fraud review, or a batch that must complete before a regulatory cutoff. Those details live inside application logic and still require language agents, OpenTelemetry APIs, or manual spans and attributes.
The most useful architecture is therefore layered. OBI provides fast, consistent baseline visibility, while application teams add domain-specific context where it changes a decision. OBI has begun supporting this hybrid model by capturing application-authored spans in documented Go configurations and offering opt-in manual span capture for some Node.js cases. The goal is not to make teams choose permanently between eBPF and SDK instrumentation; it is to let them start broad and deepen visibility where the value justifies the work.
Operators should also account for the deployment envelope. OBI supports Linux on amd64 and arm64, generally with kernel 5.8 or newer, or supported RHEL-family 4.18 kernels with required eBPF backports. BTF is required. Deployments need root or the Linux capabilities demanded by the enabled features. Those privileges deserve a security review, a minimal-capability configuration, and explicit ownership for upgrades.
A practical adoption path for platform teams
OBI 1.0 is a milestone, not a reason for an immediate fleet-wide rollout. A disciplined evaluation should test both the telemetry and the operating model.
- Choose a representative service. Start with a Linux workload that exercises the protocols, framework, TLS behavior, and concurrency patterns common in the production estate. A trivial demo proves installation, not suitability.
- Define the baseline questions. Decide which request rates, errors, latency distributions, dependencies, and trace paths must be visible. Compare OBI output with existing application metrics or controlled load tests.
- Review capabilities and data exposure. Enable only the kernel capabilities and instrumentation features required. Treat payload capture, headers, database statements, and AI prompts as separate data-governance decisions.
- Adopt Config v2. Validate configuration in CI and use the migration tooling for existing installations. Config v1’s frozen status makes it a compatibility bridge, not a sensible foundation for new deployments.
- Canary every upgrade. Run old and new telemetry through comparable pipelines, then test dashboards, alerts, cardinality, service graphs, and sampling behavior before expanding the rollout.
- Keep SDK instrumentation where it adds meaning. Preserve or add manual spans for business processes, custom events, and attributes that cannot be derived from kernel observation points.
Teams embedding OBI as an OpenTelemetry Collector receiver need an additional version check. The receiver follows a separate pre-1.0 release line, so the stable OBI executable contract does not automatically make every integration surface stable. Pinning versions and reading the receiver-specific guidance is essential.
What the 1.0 milestone changes
The strategic value of OBI 1.0 is that it makes broad automatic instrumentation more governable. eBPF observability has often been framed as a shortcut around developer adoption: deploy an agent and obtain visibility without waiting for code changes. OBI’s milestone reframes the problem. The durable product is not merely automatic collection; it is automatic collection with versioned interfaces, declared support boundaries, supply-chain artifacts, and a migration process.
That distinction will determine whether platform teams can standardize on OBI. Signed artifacts, checksums, software bills of materials, validation across kernels and architectures, and fixes to parser, buffer, lifecycle, and export behavior all support the less glamorous work of operating instrumentation safely. A long protocol list attracts trials. Predictable change management sustains production use.
OBI 1.0 therefore should not be read as a claim that zero-code instrumentation is complete. Semantic conventions will evolve, experimental features will mature, and application-specific insight will remain outside eBPF’s reach. The release instead provides a credible contract for that evolution. For Kubernetes and cloud-native teams, that is what moves OBI from an observability experiment toward a platform capability.
