Every fleet has at least one service nobody wants to touch. A vendored binary with no build pipeline, a Python app whose team left the company, a Java service where an agent rollout means a three-week change window. SDK-based instrumentation assumes you can recompile and redeploy everything, and in practice you can't. I wrote up the full comparison on DevToolLab; here's the short version.
Why 2026 changed the category
eBPF-based instrumentation solves the "can't touch the code" problem by attaching probes in the kernel and reading traffic off the wire. The reference implementation just changed hands: Grafana Labs donated its Beyla agent to OpenTelemetry, where it now ships as OpenTelemetry eBPF Instrumentation (OBI). The first alpha came out of a joint effort between Grafana, Splunk, Coralogix and Odigos, and version 0.13.0 landed under Apache 2.0 on September 4, 2026. If your notes on this space still say "Beyla," they're out of date.
What you actually get, and what you don't
OBI's own docs (checked September 8, 2026) say data capture happens "without any modifications to application code or configuration," across Java, .NET, Go, Python, Ruby, Node.js, C, C++ and Rust, with protocol coverage for HTTP/S, HTTP/2, gRPC, Kafka, NATS, MQTT and more, including TLS traffic without decrypting it.
What it doesn't give you is intent. eBPF sees a POST to /checkout that took 240ms and returned 500. It has no idea whether that's a declined card or a database timeout, because that distinction lives in your business logic and never touches a socket. Grafana makes this point themselves: eBPF is the floor of coverage across your whole fleet, SDK spans are the depth you add where the domain actually matters.
The five worth knowing
| Tool | Collects | License | Price |
|---|---|---|---|
| OpenTelemetry eBPF Instrumentation | Spans, RED metrics | Apache 2.0, v0.13.0 | Free |
| Coroot | Metrics, logs, traces, profiles | Apache 2.0, 1.26.0 | Free CE; $1/core/mo Standard |
| Odigos | Distributed traces | Apache 2.0, v1.36.0 | Free, self-hosted |
| Pixie | Full-body requests, in-cluster | Apache 2.0, CNCF Sandbox | Free |
| groundcover | Full-stack, bring-your-own-cloud | Proprietary | $30/node/mo (Pro) |
OBI is the pick if you already run an OpenTelemetry Collector: it's a producer, not a platform, and emits OTLP and nothing else. It's still pre-1.0 though; read the Limitations page before betting on it.
Coroot is the most complete open-source option and the only one collecting all four signal types from eBPF alone. The differentiator is its service map, which includes dependencies you never declared because the agent watches every socket, not just the ones you instrumented. Pricing is metered on CPU cores rather than hosts, $1/core/month for Standard, which undercuts most of the category.
Odigos targets the specific case that breaks SDK instrumentation hardest: compiled Go binaries you can't easily rebuild. Worth knowing before you evaluate it: the open-source README still says "tracing without code changes," but the commercial site now leads with "production context platform" and a 14-day trial. The agent is real and Apache 2.0; the website describes a different product built on top.
Pixie is the one that keeps everything in-cluster: no data leaves, queries run locally, and the project's own numbers put overhead under 5% of cluster CPU. It's also been sitting at CNCF Sandbox maturity since 2021, so treat it as maintained, not accelerating.
groundcover is the commercial answer for teams that want a predictable per-node bill without a sales call: $30/host/month Pro, deployed inside your own cloud so telemetry never crosses out.
What this actually costs against Datadog
Same 50-node cluster, 8 vCPU each, list prices from each vendor's own pricing page as of September 8, 2026:
Datadog Infra Pro + APM (annual) $2,550/mo $30,600/yr
groundcover Pro $1,500/mo $18,000/yr
Coroot Standard $ 400/mo $ 4,800/yr
OBI / Odigos / Pixie / Coroot CE $ 0/mo $ 0/yr
That's a 6.4x gap between Datadog and Coroot Standard alone. Two caveats: Datadog's per-GB log ingestion isn't in that table because it's workload-specific and usually the line that actually surprises people, and the $0 row is a license cost, not a total cost. You still pay for the storage backend and the engineer running it.
Getting it running
OBI deploys as a DaemonSet, one per node, instrumenting whatever it finds. The full manifest (with the unprivileged capability set instead of privileged: true) is in the original writeup. Three things that decide whether it works on the first try: the ServiceAccount needs a ClusterRole that can watch Pods, ReplicaSets, Services and Nodes or spans come back unlabeled; OTEL_EBPF_AUTO_TARGET_EXE=* instruments everything on the node, which you want for a DaemonSet but not a sidecar; and on large clusters you want the optional k8s-cache service so every agent isn't hammering the API server directly.
If you're generating that YAML by hand, DevToolLab's Kubernetes YAML Generator and YAML Validator catch the boilerplate and the indentation errors before kubectl apply does.
The short version
Already running an OTel Collector: OBI. Want one install and a service map: Coroot. Mostly Go services you can't rebuild: Odigos. Data can't leave the cluster: Pixie. Want a supported product with a bill you can predict: groundcover.
eBPF changed what's reachable, not what's meaningful. It gets you RED metrics and a dependency map across your entire fleet in an afternoon, including the services no SDK will ever touch. It still won't tell you why a checkout failed. Instrument broadly with eBPF since it's nearly free, then spend your SDK budget on the two or three services where a span actually needs to carry a business fact.
Top comments (0)