Instrument an application using OBI (eBPF)

Overview

OpenTelemetry eBPF Instrumentation (OBI) captures telemetry directly at the Linux kernel’s protocol layer.

Rather than requiring code-level instrumentation (SDKs/agents) in libraries or runtimes, OBI uses eBPF-based probes to observe runtime and network activity and automatically derive observability signals — without code changes, restarts, or added application dependencies.

Because OBI operates outside the application process, it is lightweight, safe to deploy in production, and consistent across different languages and frameworks.

For a general information about OBI, see the official OpenTelemetry OBI documentation.

What you can do with OBI

With OBI, you can:

• Instantly instrument Linux and Kubernetes workloads with zero code changes.
• Gain visibility into services written in multiple languages (Java, .NET, Go, Python, Ruby, Node.js, C/C++, Rust).
• Automatically capture distributed traces and RED (Rate, Errors, Duration) metrics.

• Observe service traffic over commonly used protocols such as HTTP/S, gRPC, gRPC-Web, MQTT, and others Capture database interactions for systems including PostgreSQL (and pgx), MySQL, MongoDB, Redis, and Couchbase

• Observe service traffic over commonly used protocols such as HTTP/S, gRPC, gRPC-Web, MQTT, and others.

• Capture database interactions for systems including PostgreSQL (and pgx), MySQL, MongoDB, Redis, and Couchbase

• Reduce onboarding time and operational risk while maintaining low overhead.

OBI lowers the barrier to adopting OpenTelemetry by making observability an infrastructure‑level capability rather than a manual, application‑by‑application effort.

When to use OBI

OBI is especially valuable when traditional instrumentation is difficult or slow to deploy, such as:

• Compiled languages and static binaries (Go, Rust, C/C++).
• Legacy applications.
• Third‑party or proprietary software.
• Large Kubernetes clusters.

In practice:

• Use OBI to instantly instrument Linux workloads or fill gaps where SDK instrumentation is missing.
• Keep existing OpenTelemetry SDK or agent‑based instrumentation for deep, in‑application visibility.
• Combine both approaches to achieve full coverage.

Compatibility with OpenTelemetry SDKs and agents

If an application is already instrumented using OpenTelemetry SDKs or language agents (for example, Java or Node.js), OBI automatically detects this and avoids re‑instrumenting the same process. This prevents duplicate telemetry and ensures safe coexistence in mixed environments.

OBI complements SDK‑based auto‑instrumentation by covering scenarios where SDKs are difficult or unavailable, such as compiled languages, legacy binaries, or proprietary applications.

Limitations

OBI is ideal for quickly establishing baseline observability, but it may not capture deep framework‑specific details or advanced distributed tracing for some runtimes (such as reactive Java, virtual threads, or highly asynchronous frameworks). In such cases, application‑level OpenTelemetry instrumentation remains the most complete option.

OBI works best when combined with existing SDK or agent‑based instrumentation.

Security, permissions, and capabilities

Like most eBPF programs, OBI requires elevated privileges. However, it allows specifying a minimal, fine‑grained set of required capabilities such as CAP_DAC_READ_SEARCH, CAP_SYS_PTRACE, CAP_PERFMON, CAP_BPF, CAP_CHECKPOINT_RESTORE, and others.

Some optional OBI functionality requires additional permissions. For example, enabling network observability probes using Linux Traffic Control requires CAP_NET_ADMIN.

Supported languages and protocols

OBI supports:

• Protocols: HTTP/S, gRPC, SQL, Redis, MongoDB
• Languages: Java, .NET, Go, Python, Ruby, Node.js, C/C++, Rust