eBPF lets you observe kernel and userspace behavior without instrumenting the code. By 2026 it's the most powerful observability technology that doesn't require app changes. The ecosystem matured around three main use cases: profiling, networking, auto-instrumentation.
What eBPF gives you
Programs that run in the kernel, attached to events (syscalls, function entry/exit, network packets). Read kernel data without context switches. No app modification. Tiny overhead (<1% typical). Available on any modern Linux kernel.
Profiling with Parca
Sample stack traces at perf_events. Aggregates across all processes, all containers. Continuous, <1% overhead. Flamegraph view of 'what CPU was doing yesterday at 14:00 in service X'. Effectively free; underused.
Networking with Cilium Hubble
Layer-7 visibility on K8s pod-to-pod traffic. HTTP requests, gRPC calls, DNS queries, all visible without sidecars or service mesh. Identity-aware. The replacement for tcpdump-style debugging at K8s scale.
Auto-instrumentation with Pixie
Inspect HTTP, MySQL, PostgreSQL, gRPC traffic in real time without app changes. Captures full request/response pairs. Useful for debugging the questions instrumentation doesn't answer ('what's the actual SQL the ORM is sending?').
Deployment
Privileged DaemonSet — needs CAP_BPF or root. Some managed K8s platforms restrict eBPF; check before committing. Resource budget: ~50-200MB RAM per node for active eBPF agents. Worth it.