Zero-code observability with eBPF, and the one question to ask before you bet your estate on it.
Every so often a demo actually stops me. Odigos did. I sat down with their team on 7 June 2026, and I will be honest up front: I was impressed. That is exactly why I went and did the homework afterwards, because the tools that impress you in a demo are the ones you most need to pressure-test. So I asked them the questions a careful buyer asks, then checked their answers against the wider world. Here is the balanced read, the good and the awkward, so you can decide for yourself.
What is Odigos?
Odigos is an open-source observability control plane that auto-instruments your applications using eBPF and OpenTelemetry, with no code changes, no SDK to import, and no redeploy. You point it at your Kubernetes workloads and it starts producing distributed traces from running services. It is a Y Combinator company (W23), the open-source project has well over 3,000 GitHub stars, and it was built by people who maintain OpenTelemetry itself. That last part matters more than the star count.
First, what is eBPF?
The whole approach rests on eBPF, so it is worth thirty seconds. eBPF is a feature built into the Linux operating system that lets small, safe programs run deep inside the kernel, the layer every application sits on top of. In plain terms, it lets a tool watch what your software is actually doing from the outside, without you changing a line of code and without meaningfully slowing anything down. It began life in networking and security, and observability tools worked out they could use the same trick to capture traces and metrics almost for free. That is the engine under Odigos.
What it does well
The pitch is simple enough to explain to someone who has never written a line of code. Pick your namespaces, and it instruments them on the fly. In their demo I watched a slow checkout get traced to a database lock wait, and a stalled AI call traced to a token limit, with nobody touching the application code.
Three things stand out once you look past the polish:
It cracks the hard languages. Compiled languages like Go have always been painful to instrument without code changes. Odigos uses eBPF and the official OpenTelemetry Go instrumentation to get traces out of them anyway.
It is vendor-neutral by design. Because it emits OpenTelemetry and runs inside your own cluster, you point the data at whatever backend you like and switch later without re-instrumenting. Instrument once, route anywhere. Nothing has to leave your environment, which makes the security conversation shorter.
It is helping write the standard, not just sell against it. Odigos is a founding contributor to the OpenTelemetry eBPF Instrumentation (OBI) project, alongside Grafana Labs, Splunk and Coralogix. A vendor shaping the open standard is a different proposition from one fencing you in.
The honest ledger
No tool is a free lunch, and the gaps here are real.
It is Kubernetes and Linux native. eBPF lives in the node kernel and needs a reasonably modern one. When I pushed them on older estates, they were refreshingly straight about it: you need a Linux kernel of 4.18 or newer and Kubernetes 1.21 or newer, and while bare metal is supported, they told me it was not yet running in production at a customer. The shiny cluster is the easy part. The legacy back end nobody can safely re-instrument, the VMs and the older systems that hold the actual money, are where the hard questions live. Coverage beyond Kubernetes is the question, not the headline.
Depth has limits today. Independent testers have found database calls surfacing as generic operations rather than full statements, and the richest Go auto-instrumentation reported as part of the paid tier rather than the free one. Worth confirming against your own workloads.
The space is consolidating fast. With Beyla folded into OBI and several vendors converging on one standard, some capabilities are still maturing and the competitive map is moving under everyone's feet.
Speed is not the same as meaning. eBPF shows you the plumbing in minutes. It does not tell you whether the customer journey is actually working. You still have to define your SLOs and your business logic. That work does not disappear, it just starts sooner.
Is Odigos the right tool for you?
If you run a modern, Kubernetes-native estate and you are tired of waiting on an engineering backlog to get distributed tracing, Odigos is genuinely worth a serious look, and the vendor-neutral, in-cluster design makes it an easy one to trial. If your weight sits in legacy infrastructure, treat it as one piece of the picture and ask hard questions about coverage and data depth before you bet the estate on it.
That is the question I would want answered before I put my name next to anything. Not because the demo was weak. Because it was strong, and strong demos are exactly when you should ask.
Do you have an Odigos story, good or bad? I would like to hear it, especially from anyone running it past a proof of concept. Reply, or book a slot and tell me what you found.
Disclosure: I have spoken with the Odigos team and may collaborate with them on future content. The opinion here is my own and stays honest, including the parts they would rather I left out.
Sources / further reading
Odigos open-source project and docs: github.com/odigos-io/odigos
Odigos on Y Combinator (W23): ycombinator.com
OpenTelemetry eBPF Instrumentation (OBI), first release: opentelemetry.io
OTel Go auto-instrumentation (eBPF): github.com/odigos-io
Grafana Beyla / OBI background: grafana.com
|
Get the next one One signal a week. No noise. | |
|
If this was useful, Metrics & Mayhem sends one short, practical piece like it to IT operations leaders most weeks. No fluff, no vendor noise.
Prefer to start with the book? Read a free chapter. |