OpenTelemetry eBPF Instrumentation v1.0: Zero-Code Now Safe

OpenTelemetry eBPF Instrumentation (OBI) shipped v1.0.0 on November 5, 2026, and the version number is the story. After a year of rapid iteration, the project now carries a formal stability contract — meaning you can instrument production services with it today without worrying about your configuration silently breaking on the next upgrade. The pitch has always been compelling: attach to any Go, Java, .NET, Node.js, Python, Ruby, C, or Rust service running on Linux and get traces, metrics, and service graphs with zero code changes and no process restarts. With v1.0, that pitch is finally backed by a promise.

What OBI Actually Does

OBI hooks into running processes at the kernel level using eBPF probes. It intercepts network calls, database queries, and application-level operations and translates them into OpenTelemetry spans and RED metrics — Rate, Errors, Duration — without touching a single line of source code. No SDK, no agent library, no restart required.

What that means in practice: you can observe a legacy Java service that nobody has touched in three years, a Go microservice your team shipped last week, and a Python ML worker you inherited from another team, all from the same DaemonSet, with the same telemetry format, exported to any OpenTelemetry-compatible backend. If your services speak HTTPS, OBI captures the transactions without decrypting them.

67% of production Kubernetes clusters already run some form of eBPF-based observability tool. OBI now gives teams a single standard to consolidate on, rather than a patchwork of vendor agents pointing at different backends.

Why v1.0 Is the Signal to Commit

Prior to v1.0, OBI was evolving fast enough that committing to it at scale felt risky. Environment variable names, the configuration schema, telemetry attribute names — any of these could shift between releases. That is no longer the case.

With v1.0, Config v2 is stable. Versioning follows semver: minor releases add compatible functionality, patch releases maintain full compatibility, and breaking changes require a major version bump. Release artifacts are signed and ship with SBOMs. The project has also published a configuration JSON schema, so your YAML editors and CI validators can catch config errors before they reach production.

If you evaluated OBI six months ago and decided to wait, the wait is over.

Protocol Coverage Expanded Significantly

v1.0 added instrumentation for MQTT, NATS, AMQP 1.0, MSSQL, Couchbase, Memcached, and Aerospike. Combined with existing support for HTTP/S, HTTP/2, gRPC, Kafka, PostgreSQL, MySQL, Redis, and MongoDB, OBI now covers the full stack of a typical microservices application. Framework route discovery works across Django, FastAPI, Flask, Rails, .NET, and PHP — so your traces show /api/v2/users/:id, not just /.

Trace-log correlation arrived in v1.0 as well. OBI enriches structured application logs with trace context automatically, linking log lines to the spans they belong to without any SDK integration on the application side.

The AI Instrumentation Angle

OBI v1.0 ships with built-in coverage for GenAI platforms: model provider calls, embedding requests, reranking, vector retrieval, and MCP interactions. If you are running an AI agent pipeline in Python or Go, OBI will capture traces across your LLM calls, your vector database reads, and your tool invocations — all without adding a single import to your application.

Optional payload extraction lets you capture the actual inputs and outputs of model calls, which is useful for debugging agent loops that are misbehaving in ways that latency numbers alone do not explain. For teams building on the Agent Skills standard or similar frameworks, end-to-end traces across the full agent stack are now one Helm install away.

Deploying OBI

The Kubernetes path is the simplest:

helm install obi \
  -n obi --create-namespace \
  open-telemetry/opentelemetry-ebpf-instrumentation

For more control, deploy as a DaemonSet to instrument every workload on every node. The key environment variables are the target executable pattern, your OTLP endpoint, and Kubernetes metadata enrichment:

containers:
  - name: autoinstrument
    image: otel/ebpf-instrument:v1.0.0
    securityContext:
      privileged: true
    env:
      - name: OTEL_EBPF_AUTO_TARGET_EXE
        value: '*/my-service'
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: 'http://otelcol:4318'
      - name: OTEL_EBPF_KUBE_METADATA_ENABLE
        value: 'true'

Not on Kubernetes? Download the signed binary for Linux amd64 or arm64 from the releases page, verify it with Cosign, and run it with sudo. It works against any process already running on the host.

What Is Still Experimental

Runtime metrics — CPU usage, heap size, GC pause times — are available for Go, Java, .NET, Node.js, and Python, but they fall outside the v1.0 stability guarantee. You can enable them today; just expect that metric names or attribute shapes may change in a future minor release.

Some scenarios also benefit from layering language-level SDK instrumentation on top of OBI. If you need custom business-level spans or want to tag traces with application-specific attributes, the two approaches work together — OBI handles the network and framework layer, your SDK handles the business logic layer.

Start Small

Deploy to a representative canary service first, verify that traces and metrics are reaching your backend, then expand. OBI runs at kernel level and needs privileged: true in Kubernetes or root on a Linux host — that warrants a staged rollout rather than a cluster-wide flip on day one.

The full documentation, including the Config v2 migration guide for upgrades from earlier releases, is at opentelemetry.io/docs/zero-code/obi.