eBPF and bpftrace

Traditional metrics can show that something is wrong without revealing why. A service might pause for 400 milliseconds even though CPU usage is low and everything else looks normal. Tracing every system call could expose the delay, but on a busy service it would generate enormous output and add unnecessary overhead.

A better approach is to capture only the relevant events and summarize them as they happen, perhaps as a latency distribution.

This is a core use case for eBPF. Small programs attach to selected events in the kernel or user-space applications. They can filter, count, time, and aggregate data before sending the results to user space. bpftrace makes this capability accessible through a compact tracing language.

This chapter distinguishes eBPF from bpftrace, explains probes, maps, filtering, counting, distributions, and event correlation, and develops a safe workflow for choosing supported probes, bounding overhead, handling permissions, and diagnosing latency.