eBPF: Kernel Observability Without Recompiling

Actualizado: 2026-05-03

eBPF (extended Berkeley Packet Filter) is one of the most transformative technologies of recent years in Linux, yet it remains unknown outside specialised circles. It’s the foundation many modern observability, networking, and security tools build on — Cilium, Pixie, Falco, Tetragon, and others. This article covers what it is, why it matters, and where you’ll find it in your stack, probably without knowing it.

Key takeaways

• eBPF lets you load programs into the kernel dynamically, without recompiling or rebooting, with static safety verification.
• It’s the foundation of Cilium, Pixie, Falco, Tetragon, and other key Cloud Native ecosystem tools.
• It provides fine observability with small overhead — a fundamental improvement over earlier tools like SystemTap.
• bpftrace is the most accessible entry point for exploring eBPF in practice.
• The verifier’s restrictions (512-byte stack, bounded loops) are intentional — they’re what makes the model safe.

The Core Idea

Traditionally, modifying Linux kernel behaviour required three costly options:

• Compiling a module and loading it (risk: a bug causes kernel panic).
• Patching the kernel and recompiling (impractical in production).
• Using userspace utilities that only saw what the kernel exposed (limited).

eBPF changes this. It lets you load small programs into the kernel that execute in response to events (syscalls, network packets, file accesses, process changes). These programs:

• Load dynamically — no recompilation or reboot required.
• Are statically verified before executing — the kernel verifier rejects programs that could hang it, access disallowed memory, or loop endlessly.
• Run in a virtual machine inside the kernel, with restricted types and limited stack.
• Are JIT-compiled to native code for performance.

The result: you instrument the kernel in real time, with safety similar to userspace and performance close to native code.

Why It Matters

Before eBPF, observing what happened inside the kernel required heavy tools (SystemTap, DTrace in its limited Linux versions) that significantly slowed the system. eBPF changed that equation: fine observability with small overhead.

Use cases that open up:

• Syscall and process tracing with no extra agent or reboots.
• Packet filtering without going through iptables/nftables (better performance).
• Visibility into encrypted traffic by observing before and after encryption in the kernel.
• Runtime security auditing with details auditd doesn’t capture.
• Application profiling with function-level stack resolution without instrumenting the binary.

This complements OpenTelemetry and Grafana Stack observability well: eBPF contributes kernel-level visibility those tools don’t reach.

Tools Built on eBPF

The ecosystem of products depending on eBPF is notable:

• Cilium^[1]: Kubernetes networking with eBPF instead of iptables. Better performance and observability (Hubble) in the same package. See the dedicated article at cilium-red-ebpf.
• Pixie^[2]: Kubernetes observability capturing HTTP, MySQL, DNS, etc. without instrumenting applications.
• Falco^[3]: runtime threat detection. Originally with kernel module; migrated to eBPF for greater compatibility.
• Tetragon^[4]: runtime security enforcement with declarative policies.
• bcc/bpftrace: libraries and tools for writing eBPF programs more accessibly.
• Parca: continuous low-overhead profiling of production processes.

If you use Cilium or Pixie, you’re already using eBPF whether you know it or not.

A bpftrace Example

To see eBPF in action, bpftrace is the simplest entry. Count syscalls per process in one line:

sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

This program loads into the kernel, fires on every syscall, indexes by process name (comm), and increments a counter. Prints results on Ctrl-C. Without touching app code, without restarting anything.

Other useful one-liners:

• read() latency per process: bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } kretprobe:vfs_read /@start[tid]/ { @ns[comm] = hist(nsecs - @start[tid]); delete(@start[tid]); }'
• TCP retransmissions: bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[comm] = count(); }'

Restrictions Worth Knowing

eBPF is not magic and has intentionally designed limits:

• Strict verifier. The verifier rejects programs it considers unsafe even if they would work. Sometimes you have to rewrite logic to pass verification.
• No free recursion. Loops are allowed in modern kernels but with bounded iterations.
• Limited stack (512 bytes). You can’t create large structures on the stack.
• Kernel compatibility. Advanced features require relatively new kernels. RHEL 9, Debian 12, and Ubuntu 22.04 are reasonable; RHEL 7 has very limited support.
• Learning curve. Writing eBPF directly is complex. Most use bpftrace or frameworks like bcc.

How to Start

Three resources and steps to go deeper:

1. ebpf.io^[5] — centralised site with tutorials, ecosystem, and references.
2. Brendan Gregg has the best public resources on tracing and eBPF — his book BPF Performance Tools (2019) remains current.
3. Practical lab: install bpftrace on your Linux, try the documentation one-liners, then write your own. For serious programming, learn Rust or C with the libbpf-rs / Aya framework.

Conclusion

eBPF has redefined what’s possible to observe and modify on a modern Linux system. It sits beneath many of the Kubernetes and observability tools you already use — understanding at least the concepts helps you choose between alternatives and debug when those tools behave unexpectedly. You don’t have to write eBPF directly to benefit, but knowing it’s there expands your repertoire.

1. Cilium
2. Pixie
3. Falco
4. Tetragon
5. ebpf.io