The kernel technology behind zero-code observability, in plain English, and where it stops short.
If you have read anything about modern observability lately, you have run into the same four letters over and over: eBPF. It is the engine under a wave of zero-code tools, including Odigos, that promise traces and metrics with no SDK and no redeploy. It is genuinely clever, and it is not magic. Here is what eBPF actually is, in plain English, and the honest limits before you lean a whole strategy on it.
What is eBPF?
eBPF stands for extended Berkeley Packet Filter, though the name now undersells it. It is a feature of the Linux kernel, the layer every application runs on top of, that lets small, sandboxed programs run deep inside the kernel with no change to the kernel's source code, no module to load, and no reboot. A built-in verifier checks every program before it runs and rejects anything that could crash or hang the system, so the power comes with guardrails. In plain terms, eBPF lets a tool watch what your software and your network are really doing, from the outside, with very little overhead.
A thirty-second history
The original BPF arrived in 1992 as a way to filter network packets for tools like tcpdump. The extended version landed in the Linux kernel in 2014 and turned that narrow trick into a general-purpose way to observe and shape almost anything the kernel touches: system calls, network traffic, function entry and exit. It is now stewarded by the eBPF Foundation under the Linux Foundation, formed in 2021, whose members include Meta, Google, Microsoft, Netflix and Isovalent. That breadth matters: eBPF is becoming a cross-industry standard, and it is even spreading beyond Linux through the eBPF for Windows project.
What it does well
For observability, three things make eBPF compelling:
No code changes. Because it hooks kernel events rather than your application, you get traces, metrics and profiles without importing an SDK or redeploying. That is what zero-code instrumentation actually means.
Low overhead, broad reach. Programs are compiled and run inside the kernel, so they capture system-wide signals, every process on the node, network flows and system calls, at a cost most workloads will not feel.
One mechanism, many jobs. The same technology powers networking, continuous profiling, security monitoring and tracing. Learn it once and it pays back across the stack.
The honest ledger
eBPF is powerful, not free. The gaps are real.
It needs a modern Linux kernel. Most useful features want kernel 4.x or newer, and the richest capabilities, like BTF and CO-RE that let one binary run across kernel versions, want 5.8 or newer. Older estates such as RHEL or CentOS 7 are simply not supported. The legacy systems that hold the actual money are often the ones eBPF cannot reach.
It is privileged by nature. eBPF programs run in the kernel and need elevated capabilities. That is a security conversation, not a tick box, and some managed Kubernetes platforms restrict the node-level access these agents require.
It shows the plumbing, not the meaning. eBPF captures generic runtime and protocol telemetry brilliantly. It does not know your customer journey or your business logic. You still have to define your SLOs and add instrumentation for the spans that matter to your domain.
It is not trivial to build with. Writing and debugging eBPF is kernel-level work, and when something fails to load the feedback can be thin. Most teams consume eBPF through a tool rather than writing it themselves, which is fine, as long as you know that is the trade.
So, is eBPF for you?
If you run modern, Kubernetes-native Linux workloads, eBPF is one of the best things to happen to observability in years, and you are almost certainly already benefiting from it through the tools you use. If your weight sits in older infrastructure or locked-down managed platforms, treat it as one valuable layer rather than the whole answer, and check kernel versions and node access before you commit. Either way, hold on to the last point: eBPF gets you the data faster, it does not decide what the data means. That part is still your job.
Where have you seen eBPF earn its place, or fall short? I would like to hear it, especially from anyone running it in anger. Reply, or book a slot and tell me what you found.
|
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. |
Sources / further reading
What is eBPF (project explainer): ebpf.io
eBPF Foundation (Linux Foundation): ebpf.foundation
eBPF overview: en.wikipedia.org/wiki/eBPF
eBPF for Windows: github.com/microsoft/ebpf-for-windows