Zero-code observability: OpenTelemetry meets eBPF with OBI

OpenTelemetry has more or less won the observability standard war, and for good reason — vendor-neutral traces, metrics and logs, one wire format (OTLP), one collector to ship it all wherever you want. The catch is the part nobody enjoys: actually instrumenting the code. SDKs mean touching every service, in every language, and redeploying. For a greenfield Go service that’s fine. For forty mixed-language services — half of which nobody wants to redeploy — it’s a project.

This is exactly where eBPF earns its keep, and where OBI — OpenTelemetry eBPF Instrumentation (the project donated to OpenTelemetry, formerly Grafana Beyla) comes in.

What eBPF buys you

eBPF lets you run small, safe programs inside the Linux kernel, attached to events — syscalls, network sockets, function entry/exit. For observability that means you can watch an application’s HTTP, gRPC and SQL traffic from the kernel, without the application knowing or caring. No library to import, no redeploy, no language-specific SDK.

OBI is the OpenTelemetry-native take on this. You run it next to your workloads (a sidecar, or a node-level DaemonSet), point it at the processes you care about, and it emits standard OTLP:

• RED metrics — rate, errors, duration — for HTTP/S and gRPC services
• Spans/traces for those same requests
• A surprising amount of language-specific detail (e.g. Go runtime internals), with plain network-level visibility for everything else

The signals are ordinary OpenTelemetry, so they flow into the same collector and backend as your hand-instrumented services. Your dashboards don’t care where the data came from.

How I actually use it

I treat OBI and SDK instrumentation as complementary, not either/or:

• OBI for breadth, instantly. Drop it into a cluster and you get uniform RED metrics and request traces across everything — including legacy and third-party services you can’t or won’t modify. Day-one coverage with zero code changes.
• SDKs for depth, where it pays. When you need custom business spans, baggage, or attributes the kernel can’t see, reach for the OpenTelemetry SDK in that specific service.

For platform and SRE work this ordering matters: OBI gets a whole estate observable in an afternoon, then you invest SDK effort only where the extra fidelity is worth it — rather than blocking all observability behind a multi-quarter instrumentation programme.

The honest caveats

eBPF isn’t magic:

• It needs kernel access (CAP_BPF / privileged-ish) and a recent-enough kernel — worth checking against locked-down or managed node pools.
• Cross-service trace context propagation is the hard part: the kernel sees individual requests, but stitching them into distributed traces across services still benefits from cooperation (headers, or OBI’s propagation support) — it’s improved a lot, but verify it against your topology.
• Encrypted in-process traffic and some runtimes limit what it can see.

None of that undercuts the core win. If your observability story stalls because “we haven’t instrumented that yet,” eBPF flips the default: everything is observable first, and SDKs become a deliberate upgrade rather than a prerequisite.

And because it’s all self-hosted OpenTelemetry, the data stays in your own collector and backend — which matters a great deal when you’re running this for teams whose telemetry can’t leave their own infrastructure.

Want a unified, self-hosted observability setup across a mixed estate without a year of instrumentation work? Get in touch.