1. eBPF in a few words #
A virtual machine in the kernel.
The principle #
eBPF (extended Berkeley Packet Filter) lets you load small programs into the Linux kernel, without a module or a reboot. Before running, each program goes through a verifier (no infinite loops, no out-of-bounds memory access), then it is compiled to native code (JIT) and attached to an event.
For observability, this means seeing every system call, every packet, every function of a process, with very low overhead and without changing applications.
2. Hook points #
Where a program can attach.
Types of hooks #
| Hook | Triggered by | Example use |
|---|---|---|
| tracepoint | Stable kernel instrumentation point | System calls, scheduler, network |
| kprobe / kretprobe | Entry / exit of a kernel function | Latency of vfs_read |
| uprobe / uretprobe | Entry / exit of a program function | OpenSSL's SSL_write: seeing HTTP before encryption |
| perf event | Timer or hardware counter | Sampling CPU profiling |
| XDP / TC | Network packet (before or within the stack) | Filtering, load balancing, network flows |
| LSM | Security checks | Detecting suspicious executions |
Good to know: Tracepoints are stable across kernel versions; kprobes depend on internal functions and can break during an upgrade.
3. Maps, BTF and CO-RE #
Exchanging data and staying portable.
Maps #
An eBPF program does no I/O: it writes to maps (hash tables, arrays, ring buffers) that the user-space agent reads. Aggregation therefore happens in the kernel (counters, histograms) and only the result goes up: this is what makes eBPF so efficient.
Portability #
BTF (BPF Type Format) describes the structures of the running kernel; CO-RE (Compile Once, Run Everywhere) adjusts the program on the fly. The same binary thus works on several kernel versions.
uname -r # 5.8+ recommandé, 5.15+ idéal
ls /sys/kernel/btf/vmlinux # BTF disponible ?
bpftool feature probe | grep -i "map_type" | head| Tool | Category |
|---|---|
| bpftrace, bcc | One-off command-line diagnostics |
| Grafana Beyla / OpenTelemetry eBPF Instrumentation | RED metrics and application traces |
| Cilium Hubble | Kubernetes network flows |
| Pyroscope, Parca, OpenTelemetry eBPF profiler | Continuous profiling |
| Tetragon, Falco | Security observability |
My progress
Sign in to track your progress and take notes. Sign in
💬 Questions about this lesson
No questions yet: be the first to ask for help or share your configuration.
Recommended Articles
Zero-code instrumentation with Grafana Beyla (OpenTelemetry eBPF Instrumentation)
Get RED metrics and HTTP/gRPC traces from any application without changing it: Grafana Beyla and ...
eBPF in production: security, prerequisites and limits
What to know before deploying eBPF agents: privileges and capabilities, kernel versions, managed ...
Instrumenting applications for Pyroscope: SDKs, Alloy and eBPF
Send profiles to Pyroscope from Go, Java, Python and Node.js with the SDKs, collect pprof endpoin...
Beyla and Alloy: zero-code RED metrics and traces with beyla.ebpf
Enable Beyla eBPF instrumentation in Alloy: service discovery, RED metrics to Mimir, traces to Te...
eBPF best practices for observability
Checklist for adopting eBPF in observability: choosing tools, gradual rollout, agent security, co...
Diagnosing with bpftrace and the bcc tools
Everyday eBPF diagnostic tools: bpftrace one-liners (system calls, files, latencies), bcc tools (...
Observing the Kubernetes network with Cilium Hubble
Make a Kubernetes cluster's network flows visible with Cilium Hubble: architecture, the hubble ob...
Continuous profiling with eBPF: Parca, Pyroscope and the OpenTelemetry profiler
Continuously profile every process on a host with eBPF: principle, Parca and parca-agent, Pyrosco...
OTLP explained: understanding the OpenTelemetry protocol
The OTLP protocol explained simply. Understand the differences between gRPC and HTTP for exportin...