OBI: eBPF Auto-Instrumentation for Kubernetes

Most teams want consistent telemetry, but production services rarely move at the same speed. Some can accept SDK changes quickly. Others are legacy workloads that nobody wants to restart during an incident. OpenTelemetry eBPF Instrumentation, commonly called OBI, attacks that gap from the Linux kernel.

What Is OBI?

OBI is a zero-code auto-instrumentation tool in the OpenTelemetry ecosystem. It uses eBPF probes to inspect application executables and the OS networking layer, then emits OpenTelemetry data without requiring code changes, language agents, or application restarts.

The project targets Linux services and Kubernetes workloads. It captures spans for web transactions, RED metrics, network flow data, trace context, and selected runtime signals. OBI is still in v0, so pin versions instead of tracking latest.

Key Features

• Zero-code traces and metrics: collect HTTP/S, gRPC, database, queue, and service traffic signals without changing application source.
• Broad runtime coverage: supports Java, .NET, Go, Python, Ruby, Node.js, C, C++, Rust, and other Linux workloads.
• Kubernetes-native discovery: decorates telemetry with pod and service metadata so responders can map symptoms back to cluster objects.
• Network observability: captures flow counters, TCP RTT, retransmits, socket I/O, and service-to-service traffic patterns.
• GenAI visibility: adds telemetry for OpenAI, Anthropic, Gemini, Bedrock, MCP over JSON-RPC, vector retrieval, embeddings, and rerank APIs.

Installation

For a first cluster test, deploy OBI as a sidecar and export telemetry to an OpenTelemetry Collector. The official Kubernetes docs also cover DaemonSet mode for node-wide coverage.

kubectl patch deployment api -p '{"spec":{"template":{"spec":{"shareProcessNamespace":true}}}}'

Then add an otel/ebpf-instrument sidecar with privileged: true, OTEL_EBPF_AUTO_TARGET_EXE=*, and OTEL_EXPORTER_OTLP_ENDPOINT=http://otelcol:4318. Enable Kubernetes metadata with OTEL_EBPF_KUBE_METADATA_ENABLE=true and a ServiceAccount that can list and watch pods, services, nodes, and ReplicaSets.

Incident Workflow

OBI is most useful when you need fast telemetry from services that were not already instrumented. During an outage, deploy it to one namespace, then compare request rate, error rate, latency, retransmits, and dependency edges against your existing dashboards.

Use the data to answer practical questions: which service fails first, whether the issue is application-level or network-level, and whether traces cross old and new workloads.

Operational Tips

Treat OBI as a bridge, not a replacement for deliberate instrumentation. SDKs still provide richer domain spans and business attributes. OBI gives you coverage when source changes are slow, risky, or impossible.

Control cardinality before sending data to long-term storage. Start with RED metrics and a narrow trace sample, then expand only after dashboards and alerts prove useful.

Finally, pin versions and test upgrades. OBI is moving quickly, and telemetry names or behavior can change while the project remains pre-1.0.

Conclusion

OBI is worth tracking because it makes OpenTelemetry adoption less dependent on every service team finishing code-level instrumentation at the same time. For SREs running Kubernetes, that means faster visibility during migrations, incidents, and inherited-service cleanup.

At Akmatori, we help SRE teams build intelligent automation that responds to incidents and manages infrastructure. For GPU-accelerated AI workloads, check out Gcore cloud infrastructure with global edge locations.