OpenTelemetry OBI for Zero-Code Kubernetes Tracing
Getting application traces into Kubernetes usually means language agents, SDK changes, restarts, and a lot of coordination with app teams. OpenTelemetry eBPF Instrumentation changes that model by using eBPF probes to collect HTTP, HTTPS, and gRPC telemetry directly from Linux hosts and Kubernetes nodes.
What Is OBI?
OBI is the OpenTelemetry project for zero-code application observability. According to the official docs, it can capture distributed traces and RED metrics for Linux services without modifying application code or configuration. It supports Java, .NET, Go, Python, Ruby, Node.js, C, C++, and Rust, and it can export data through standard OTLP pipelines.
That matters for SRE teams because it lowers the cost of first-time instrumentation. You can get service-level visibility into mixed estates, including third-party binaries and legacy workloads, before you commit to deeper SDK-based tracing.
Key Features
- Zero-code tracing for HTTP/S, gRPC, JSON-RPC, MQTT, Memcached, and more
- Kubernetes-native deployment with metadata decoration for pods, nodes, and workloads
- Encrypted traffic visibility for TLS/SSL traffic without application changes
- Database and GenAI coverage for PostgreSQL, MySQL, MongoDB, Redis, Couchbase, OpenAI, Claude, Gemini, and Bedrock calls
- Low-overhead OTLP export that fits existing OpenTelemetry Collector pipelines
Why v0.8.0 Is Worth Watching
The upstream v0.8.0 release expands protocol support and makes OBI more practical for real production clusters. Highlights include generic Go tracing improvements, JSON-RPC support across all languages, bounded full HTTP body extraction, named CIDR labels for network metrics, and broader GenAI payload extraction.
For busy platform teams, that means fewer blind spots when services do not share a single language stack or telemetry library strategy.
Installation
A simple Kubernetes starting point is the official Helm chart:
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
helm install obi open-telemetry/opentelemetry-ebpf-instrumentation \
-n obi --create-namespace
If you want Kubernetes metadata on traces, enable OBI with the permissions and metadata settings described in the official setup docs. OBI requires Linux with eBPF support, BTF, and either root or the required fine-grained capabilities.
Usage
Once deployed, point OBI at your collector and instrument the workloads you care about first. For example, metadata decoration can be enabled with the documented Kubernetes setting:
attributes:
kubernetes:
enable: true
That gives traces richer context like namespace, deployment, pod, and node names, which is exactly what you want during incident response.
Operational Tips
Treat OBI as a fast visibility layer, not a full replacement for language SDKs. The official docs are clear that you still need language-level instrumentation when you want custom spans, business events, or app-specific attributes. Also check the Cilium compatibility guide before enabling network features on eBPF-heavy clusters.
Conclusion
OBI is one of the more interesting observability projects to watch right now. It gives SRE teams a practical way to roll out OpenTelemetry tracing across Kubernetes without waiting on every service owner to change code. If you want faster coverage with less coordination, OBI is worth testing in a non-critical cluster this week.
Looking for an AI-powered platform to help your SRE team? Akmatori helps teams automate incident response and infrastructure management. Backed by Gcore, we're building the future of intelligent operations.