Skip to content

CONCEPT Cited by 1 source

eBPF profiling

eBPF profiling is the practice of collecting profile samples (CPU stacks, memory allocations, latency buckets, off-CPU time, custom events) from production hosts by attaching small verifier-gated eBPF programs to kernel hooks — perf events, kprobes / uprobes, tracepoints, scheduler hooks — and streaming the samples through ring-buffer maps to a user-space consumer.

It is distinct from traditional profiling mechanisms along three axes:

Axis perf / ptrace / DTrace eBPF profiling
Safety custom kernel modules risk the kernel verifier-gated sandbox
Overhead context-switch heavy in-kernel, ring-buffer-out
Customisation ship-and-hope or wait for a distro write a small program, attach

The load-bearing property for profiling specifically is the custom-action-at-sample-time ability: an eBPF program can read thread-local storage, look up cgroup IDs, check PMU counter values, or filter/enrich samples before they cross into user-space — see concepts/runtime-metadata-attach and concepts/in-kernel-filtering.

Why hyperscalers adopted it

Quote from Meta's Strobelight post (2025-01-21):

"Strobelight's profilers are often, but not exclusively, built using eBPF... eBPF allows the safe injection of custom code into the kernel, which enables very low overhead collection of different types of data and unlocks so many possibilities in the observability space that it's hard to imagine how Strobelight would work without it."

(Source: sources/2025-03-07-meta-strobelight-a-profiling-service-built-on-open-source-technology)

eBPF is the kernel primitive that makes fleet-wide continuous profiling economically feasible — the cost per profiler-host-hour is low enough that patterns/default-continuous-profiling can run on every production machine without perturbing the workloads being profiled.

Canonical instances

Seen in

Last updated · 550 distilled / 1,221 read