eBPF und bpftrace: Moderne Kernel-Beobachtbarkeit ohne Kernel-Module

1. Was eBPF ist und warum es Kernel-Tracing verändert hat

eBPF, kurz für Extended Berkeley Packet Filter, ist eine virtuelle Maschine im Linux-Kernel, die kleine, verifizierte Programme direkt im Kernel-Kontext ausführt, ohne dass dafür ein eigenes Kernel-Modul kompiliert und geladen werden muss. Ein Verifier prüft jedes eBPF-Programm vor der Ausführung darauf, dass es terminiert, keine unerlaubten Speicherzugriffe vornimmt und den Kernel nicht destabilisieren kann.

Diese Kombination aus Sicherheit und Kernel-Nähe war vorher praktisch unmöglich: Klassische Kernel-Module laufen mit vollen Rechten und können bei einem Fehler das gesamte System zum Absturz bringen, während Userspace-Werkzeuge wie strace jeden beobachteten Vorgang über einen teuren Kontextwechsel zurück in den Userspace reichen müssen. eBPF-Programme werten Ereignisse direkt dort aus, wo sie entstehen, und liefern nur die relevanten, bereits aggregierten Daten an den Userspace zurück.

2. Anwendungsfelder von eBPF jenseits von Tracing

eBPF wird längst nicht mehr nur für Beobachtbarkeit eingesetzt. Netzwerk-Filterung und Load Balancing über XDP, Container-Netzwerke bei Kubernetes-Implementierungen wie Cilium und Security-Monitoring über Projekte wie Falco bauen alle auf demselben Kernel-Mechanismus auf. Für den Admin-Alltag auf einem Magento-Hosting-Server bleibt aber die Beobachtbarkeit der mit Abstand relevanteste Anwendung.

Der entscheidende Unterschied zu klassischem Tracing liegt in der Auswertungslogik: Statt jedes Ereignis roh in den Userspace zu kopieren, kann ein eBPF-Programm bereits im Kernel filtern, aggregieren und in Histogrammen zusammenfassen. Nur das Ergebnis dieser Auswertung verlässt den Kernel, was den Overhead gegenüber ptrace-basierten Werkzeugen um Größenordnungen reduziert.

3. bpftrace als High-Level-Sprache für eBPF

Rohes eBPF zu schreiben bedeutet in der Regel, C-Code gegen die BPF-Bytecode-Zielarchitektur zu kompilieren und über libbpf zu laden, ein Aufwand, der für schnelle Diagnosen auf einem Produktionsserver unpraktikabel ist. bpftrace schließt diese Lücke mit einer AWK-ähnlichen Skriptsprache, die Einzeiler und kurze Skripte in eBPF-Bytecode übersetzt und automatisch lädt.

Die Kernidee von bpftrace sind Probes, benannte Anknüpfpunkte im Kernel oder in Userspace-Programmen, an denen ein Skript-Block ausgeführt wird, sobald das Ereignis eintritt. Probe-Typen wie tracepoint für stabile Kernel-Ereignisse, kprobe für beliebige Kernel-Funktionen und uprobe für Userspace-Funktionen decken zusammen praktisch jede denkbare Beobachtungsstelle ab.

# bpftrace installieren (Debian/Ubuntu)
apt install bpftrace

# Einfachster Einstieg: Alle open()-Aufrufe systemweit live mitschneiden
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

4. Praxisbeispiel: Syscall-Latenzen messen

Eine der wertvollsten Fragen im Hosting-Alltag lautet: Wie lange dauern bestimmte Systemaufrufe tatsächlich, nicht im Durchschnitt über alle Prozesse, sondern als Verteilung. bpftrace beantwortet das mit eingebauten Histogramm-Funktionen, indem der Zeitpunkt beim Eintritt in den Syscall gespeichert und beim Verlassen die Differenz in ein Histogramm eingetragen wird.

Das folgende Skript misst die Latenz aller read-Aufrufe pro Prozessname und stellt sie als Histogramm dar. Anders als bei strace fällt dabei kein Overhead pro einzelnem Aufruf für einen Userspace-Kontextwechsel an, die Aggregation geschieht direkt im Kernel, sodass sich dieser Ansatz auch über Stunden auf einem produktiven System betreiben lässt.

# Latenz von read()-Aufrufen pro Prozessname als Histogramm
bpftrace -e '
tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @latenz_ns[comm] = hist(nsecs - @start[tid]);
    delete(@start[tid]);
}'

5. Praxisbeispiel: Datei-Öffnungen live verfolgen

Für die Frage, welcher Prozess auf welche Dateien zugreift, ohne dabei den gesamten Prozessbaum wie bei strace zu belasten, eignet sich ein Probe auf den openat-Tracepoint kombiniert mit einem Filter auf den Prozessnamen. Das macht sich besonders bezahlt, wenn unklar ist, welcher von mehreren PHP-FPM-Workern überhaupt die problematische Datei anfasst.

Ein weiterer typischer Anwendungsfall im Magento-Kontext ist das Aufspüren unerwarteter Zugriffe auf Konfigurationsdateien oder Backup-Verzeichnisse, etwa um zu prüfen, ob ein Cron-Job tatsächlich nur die erwarteten Pfade berührt oder versehentlich auf produktive Datenbank-Dumps zugreift.

# Alle Datei-Oeffnungen von php-fpm-Prozessen live anzeigen
bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "php-fpm"/
{
    printf("%d %s\n", pid, str(args->filename));
}'

6. Fertige Werkzeuge statt eigener Skripte: die BCC-Sammlung

Für viele Standard-Fragestellungen muss kein eigenes bpftrace-Skript geschrieben werden. Das BCC-Projekt, ein Schwesterprojekt mit demselben eBPF-Unterbau, liefert fertige Kommandozeilenwerkzeuge wie opensnoop für Datei-Öffnungen, execsnoop für neu gestartete Prozesse und biolatency für Block-I/O-Latenzen als Histogramm.

Diese Werkzeuge sind auf vielen Distributionen über das Paket bpfcc-tools verfügbar und decken bereits einen Großteil der täglichen Diagnose-Anforderungen ab, ohne dass ein eigenes bpftrace-Skript geschrieben werden muss. Ein eigenes Skript lohnt sich vor allem dann, wenn eine sehr spezifische Kombination aus Filterkriterien benötigt wird, die kein vorhandenes Tool abdeckt.

# BCC-Tools installieren (Debian/Ubuntu)
apt install bpfcc-tools

# Alle neu geoeffneten Dateien im System live anzeigen
opensnoop-bpfcc

# Block-Device-I/O-Latenz als Histogramm über 10 Sekunden
biolatency-bpfcc 10 1

7. Voraussetzungen und Grenzen von eBPF in der Praxis

eBPF setzt einen ausreichend aktuellen Kernel voraus, für stabile Tracepoints und volle bpftrace-Funktionalität empfiehlt sich Kernel 5.x oder neuer, sowie CONFIG_DEBUG_INFO_BTF für typinformationsbasierte Probes ohne eigenes Kernel-Headers-Paket. Auf älteren Enterprise-Distributionen mit lange gepflegten LTS-Kerneln ist die Verfügbarkeit einzelner Tracepoints daher zuerst zu prüfen.

In Containern und insbesondere in gemanagten Cloud-Umgebungen ist eBPF-Tracing oft eingeschränkt oder ganz deaktiviert, weil es erweiterte Capabilities wie CAP_BPF oder CAP_SYS_ADMIN auf dem Host benötigt, die aus Sicherheitsgründen selten an einzelne Container durchgereicht werden. Auf klassischen, dedizierten oder KVM-virtualisierten Hosting-Servern ist das in der Regel kein Problem.

8. Abgrenzung zu strace und ftrace

strace beobachtet einen einzelnen Prozess über ptrace und erzeugt dabei pro Syscall einen teuren Kontextwechsel, eBPF wertet Ereignisse dagegen direkt im Kernel aus und meldet nur die aggregierten Ergebnisse zurück, was systemweites, dauerhaftes Tracing überhaupt erst praktikabel macht. Für die punktuelle, tiefgehende Analyse eines einzelnen hängenden Prozesses bleibt strace trotzdem oft der schnellere Griff, weil kein Skript formuliert werden muss.

ftrace ist der ältere, ebenfalls im Kernel eingebaute Tracing-Mechanismus, den unter anderem perf nutzt, und war lange die Standardantwort auf Funktionsaufruf-Tracing im Kernel. eBPF baut konzeptionell auf denselben Tracepoints auf, die auch ftrace nutzt, bietet aber deutlich mehr Programmierbarkeit, weil eigene Filterlogik und Aggregation direkt im Kernel-Programm formuliert werden können, statt nur rohe Ereignisse zu protokollieren.

9. Best Practices für den produktiven Einsatz von bpftrace

Ein bpftrace-Skript sollte immer zunächst auf einem Testsystem mit ähnlicher Kernel-Version geprüft werden, bevor es auf einem produktiven Magento-Hosting-Server läuft, weil Tracepoint-Namen und verfügbare Felder zwischen Kernel-Versionen variieren können. Ein Skript, das auf einem Kernel klaglos läuft, kann auf einem anderen mit einer kryptischen Fehlermeldung abbrechen, wenn ein referenzierter Tracepoint dort schlicht nicht existiert.

Aggregationen wie @start[tid] sollten konsequent mit delete() wieder entfernt werden, sobald sie ausgewertet wurden, da bpftrace sonst über eine lange Laufzeit unbegrenzt Map-Einträge ansammelt und selbst Speicher verbraucht. Für Einzeiler auf der Kommandozeile ist das oft vernachlässigbar, für Skripte, die stundenlang im Hintergrund laufen sollen, ist es Pflicht.

Wer bpftrace regelmäßig für dieselbe Fragestellung einsetzt, etwa tägliche Latenzmessungen für Datenbank-Volumes, sollte das Skript versionieren und dokumentieren, welche Kernel-Version und welche Probe-Typen vorausgesetzt werden, damit ein Wechsel auf einen neueren Kernel nicht zu stillschweigend falschen Ergebnissen führt.

# Verfügbarkeit eines konkreten Tracepoints vor dem produktiven Einsatz pruefen
bpftrace -l 'tracepoint:syscalls:sys_enter_openat'

# Skript mit klar dokumentierter Kernel-Voraussetzung als Datei ablegen
# scripts/bpftrace/read-latency.bt (Kernel 5.10+, benoetigt CONFIG_DEBUG_INFO_BTF)

10. Zusammenfassung

11. FAQ: eBPF/bpftrace