eBPF — Kernel-Level Observability
debt(d7/e3/b3/t3)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and the code_pattern describes a situation where performance bottlenecks are invisible to application-level profilers (Blackfire, Xdebug). Tools like bpftrace, bcc, perf, and strace exist but require deliberate expert-level investigation — there is no automated flag that tells you eBPF should be used or that it is being misused. Misuse (wrong kernel version, unsafe programs) only surfaces at runtime, not via static analysis.
Closest to 'simple parameterised fix' (e3). The quick_fix describes adopting bpftrace/bcc tooling to trace PHP-FPM latency — this is an operational/tooling change rather than application code changes, but it does require learning the toolchain, selecting the right probe points, and possibly adjusting kernel version. It's more than a one-line patch but doesn't span multiple application files — it's a contained operational intervention.
Closest to 'localised tax' (b3). eBPF/bpftrace is an observability tooling choice applied at the infrastructure/ops layer. It doesn't permeate application code, doesn't require code changes in the PHP application, and its footprint is largely confined to the ops/SRE workflow. The applies_to scope (web, cli) is broad but the choice imposes no structural burden on application maintainers beyond knowing the tooling exists.
Closest to 'minor surprise (one edge case)' (t3). The misconception field states that developers wrongly assume eBPF requires kernel module development skills — in reality bpftrace provides a high-level scripting interface. This is a moderate but not catastrophic misconception: it causes developers to avoid the tool unnecessarily rather than use it dangerously. Common mistakes (kernel version requirements, APM sufficiency) add minor edge-case surprises but the overall concept behaves roughly as advertised once the scripting-vs-kernel-module distinction is understood.
Also Known As
TL;DR
Explanation
eBPF allows verified programs to run in the Linux kernel at event hooks: system calls, network events, CPU samples, function entry/exit. Unlike traditional kernel modules, eBPF programs are verified for safety before loading and cannot crash the kernel. Tools built on eBPF: bpftrace (ad-hoc tracing scripts), Cilium (eBPF-based Kubernetes networking), Falco (security monitoring), and Pixie (Kubernetes observability without instrumentation). For PHP: eBPF can trace PHP function calls, memory allocation, and system calls without any PHP code changes — the ultimate zero-instrumentation observability.
Common Misconception
Why It Matters
Common Mistakes
- Running eBPF on kernels < 4.18 — many features require Linux 5.x+.
- Unsafe eBPF programs in production — the kernel verifier prevents crashes, but complex programs need testing.
- eBPF for application-level tracing when APM is sufficient — eBPF shines for system-level and cross-process tracing.
- Not understanding that eBPF programs are JIT-compiled by the kernel — they run efficiently but need proper management.
Code Examples
# No tracing — diagnosing PHP performance issues:
# Mystery: PHP workers spending time in kernel
# Tool: strace (high overhead, sequential only)
# Coverage: one process at a time
# Production impact: 10-100x slowdown on traced process# bpftrace — trace all PHP system calls with low overhead:
# Trace slow system calls (> 1ms) for any PHP process:
bpftrace -e '
tracepoint:syscalls:sys_enter_read
/comm == "php-fpm"/ {
@start[tid] = nsecs;
}
tracepoint:syscalls:sys_exit_read
/comm == "php-fpm" && @start[tid]/ {
$dur = (nsecs - @start[tid]) / 1000000;
if ($dur > 1) printf("%s: read took %dms\n", comm, $dur);
delete(@start[tid]);
}
'
# Shows which file reads are slow — no PHP changes needed