Zum Inhalt springen 
Ich zeige, wie bpftrace Hosting in Linux-Umgebungen die Zeit bis zur Fehlerursache drastisch verkürzt und dabei Kernel-Signale nutzbar macht. Statt Rätselraten messe ich Systemcalls, I/O-Latenzen und Netzwerk-Events live im eBPF-Kontext – ohne Dienste anzuhalten.
Zentrale Punkte
Die folgenden Stichpunkte geben einen schnellen Überblick über die Schwerpunkte dieses Beitrags.
- Tiefer Einblick in Systemcalls, I/O und Netzwerk direkt aus dem Kernel
- Geringer Overhead dank sicherer eBPF-Programme im Kernel
- Schnelle Eingrenzung von Prozess-, I/O- und DB-Engpässen
- Flexibles Tracing mit Filtern, Histos und Stacktraces
- Praxis-Workflow für akute Vorfälle in Minuten
Warum bpftrace Probleme im Hosting schneller sichtbar macht
In modernen Hosting-Stacks konkurrieren viele Dienste um Ressourcen, während klassische Dashboards oft nur Oberflächenwerte zeigen. Ich gehe eine Ebene tiefer: bpftrace hängt sich an Systemcalls, Tracepoints und Funktionshaken und zeigt mir, was wirklich bremst. Timeouts mit unauffälliger CPU-Auslastung deuten häufig auf I/O-Latenzen oder blockierende Aufrufe hin. Genau dort punktet bpftrace mit Zählungen, Latenz-Histogrammen und Stacktraces direkt aus dem Kernel. So weise ich Lastverursacher konkreten Prozessen, Containern oder Abfragen zu und handle gezielt.
Wie eBPF und bpftrace zusammenspielen
eBPF führt kleine, geprüfte Programme im Kernel aus und liefert Ereignisse aus erster Hand. bpftrace kompiliert Skripte zur Laufzeit in eBPF-Bytecode und hängt sie an Probes, Filter und Aktionen. Ich wähle etwa einen Tracepoint für Datei-Reads, filtere auf einen Prozessnamen und aggregiere Latenzen in einem Histogramm. Das Muster „Probe – Filter – Aktion“ bleibt überschaubar, selbst wenn ich mehrere Signale gleichzeitig messe. So baue ich in Minuten eine Beobachtung, die mir die entscheidenden Indikatoren liefert.
Schnelle One-Liner für den Ernstfall
In Vorfällen zählt Tempo. Ich nutze kompakte One-Liner, die in Sekunden ein Muster zeigen. Einige meiner bewährten Starter:
# „Laute“ Dateizugriffe nach Prozessname zählen (alle 5s leeren)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
# Latenz-Histogramm für Datei-Reads (per Prozess)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
# TCP-Retransmissions mit Kernel-Stacks bündeln
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# SoftIRQ-Zeiten aufsummieren (10s-Fenster)
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
@soft[args->vec] = sum(nsecs - @t[args->vec]);
delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'
# accept()-Last am DB- oder Webserver sichtbar machen
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
Mit diesen „Sonden“ finde ich rasch, ob ein Dienst abnormal viele Dateien öffnet, I/O lahmt oder das Netz retranst. Danach verfeinere ich Filter auf PID, Prozessnamen oder Pfade.
Prozess- und Ressourcendiagnose auf Live-Servern
Wenn ein einzelner Account oder Container einen Shared-Server ausbremst, zähle ich Systemcalls pro Prozess und finde „laute“ Verursacher. Auffällig viele execve-Aufrufe weisen auf exzessive Prozessstarts hin, was etwa fehlerhafte Cronjobs verrät. Öffnet ein Dienst unzählige Dateien, sehe ich es sofort und schränke die Prüfung mithilfe von Filtern auf bestimmte Pfade ein. Für stark frequentierte Webserver ist das Gold wert, weil ich Störer rasch abgrenze. Wer tiefer in Tooling-Ideen einsteigen will, schaut sich ergänzend Ansätze zu eBPF-Analysewerkzeugen an und überträgt das Prinzip auf eigene Hosts.
Container- und Kubernetes-Sicht mit cgroups
In Multi-Tenant- oder Kubernetes-Hosts brauche ich eine klare Mandantentrennung. bpftrace bietet mir dafür die cgroup-Sicht als Schlüssel:
# Systemcalls nach cgroup (Container) und Prozessname bündeln
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
So erkenne ich, welcher Container laut ist, ohne einzelne PIDs manuell zu sammeln. Für fokussierte Analysen setze ich zusätzliche Filter:
# Nur PHP-FPM betrachten (z. B. in einem App-Container)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
In Kubernetes messe ich häufig am Node und gruppiere nach cgroup. Die Zuordnung von cgroup-IDs zu Pod/Container-Namen dokumentiere ich in meinem Runbook (kubectl/CRI), damit ich Messergebnisse klar referenzieren kann.
I/O- und Dateisystem-Latenzen zuverlässig messen
Langsame Seiten trotz „okayer“ CPU deuten oft auf I/O-Engpässe hin. Ich messe Lese- und Schreiboperationen pro Prozess, protokolliere langsame Pfade und baue Latenz-Histogramme. In WordPress-Umgebungen erkenne ich dadurch, ob viele kleine PHP-Dateien oder große Mediendateien den Durchsatz drosseln. Danach entscheide ich, ob Caching, PHP-Opcode-Cache oder ein Dateisystem-Tuning zuerst greift. Wer tiefer einsteigen will, findet Hintergründe zu Disk-Latenzen im Storage und kann Messpunkte gezielt anpassen.
Off-CPU- und Lock-Wartezeiten sichtbar machen
Nicht jede Wartezeit ist I/O: Threads können off-CPU blockieren – etwa auf Locks. Ich nutze dafür Futex- und Scheduler-Events.
# Futex-Wartezeiten (Lock-Contention) als Histogramm
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
@futex[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
Mit solchen Profilen sehe ich, ob PHP-FPM-Worker oder DB-Threads auf Locks warten. Kombiniert mit I/O-Histos trenne ich Storage– von Concurrency-Problemen.
Netzwerk-Fehler, SoftIRQs und Retransmissions sichtbar machen
Beschwerden über sporadische Timeouts führe ich häufig auf Netzwerk-Signale zurück. Ich überwache TCP-Retransmissions, RST-Events und Verbindungsabbrüche direkt im Kernel. Ergänzend werfe ich einen Blick auf SoftIRQs, weil überlastete Netzwerk-Queues dort Spuren hinterlassen. Das Muster aus Retransmits plus steigenden SoftIRQ-Zeiten weist auf Drops, Pufferengpässe oder QoS-Probleme hin. Eine gute Ergänzung für die Ursachenfindung sind Hintergrundartikel zu SoftIRQ und Netzwerkdurchsatz, die ich mit bpftrace-Messungen verknüpfe.
Fallbeispiel: WordPress-Host mit sporadischen 504-Timeouts
Ein Shared-Server meldet 504-Fehler, die CPU liegt nur bei 35%. Mein Ablauf:
- Hypothese „Netz oder I/O“. Ich starte Retransmits und SoftIRQ-Zeitmessung. Ergebnis: wenige Retransmits, SoftIRQs stabil.
- Wechsel auf I/O: vfs_read-Latenz-Histo zeigt Long-Tail bis 80 ms für php-fpm. Viele openat-Aufrufe pro Request.
- Filter auf Pfade unter wp-content und wp-includes: unzählige kleine Datei-Reads dominieren.
- Gegenprobe Locks: Futex-Histo ohne Auffälligkeit – keine Lock-Contention.
- Maßnahme: OPCache-Config anpassen, statische Assets aggressiver cachen. Danach sinken openat-Counts und Latenzen.
Mit weniger als 15 Minuten aktivem Tracing ist klar: Nicht Netzwerk, sondern Datei-IO und fehlendes Caching verursachen die Timeouts.
Datenbanken und PHP-FPM: Engpässe schnell eingrenzen
Bei MySQL/MariaDB schaue ich mir Systemcalls, Locks und I/O-Latenzen der DB-Prozesse an. Ich verfolge accept/connect-Phasen, um zu sehen, ob Verbindungen stocken oder TLS-Handshakes hängen. Für PHP-FPM prüfe ich, ob execve und Dateizugriffe auffällig hoch sind, was auf fehlendes Caching hindeutet. Mit Stacktraces bei bestimmten syscalls erkenne ich, an welcher Code-Stelle Requests warten. So schließe ich Netz, App und Datenbank schrittweise aus und finde die engste Stelle.
Best Practices für produktive Server
Ich starte jedes Tracing mit einer klaren Fragestellung und grenze Probes mit Filtern ein. Zeitliche Limits oder Intervalle halten die Datenmenge beherrschbar. Für wiederkehrende Analysen speichere ich Skripte mit sinnvollen Default-Filtern wie PID, cgroup oder Prozessnamen. Vor dem Einsatz auf Kunden-Hosts teste ich anspruchsvolle Skripte auf Staging-Systemen. So bleibt der Overhead gering, und ich verhindere unnötige Seiteneffekte.
Messgüte, Overhead und Limits in der Praxis
bpftrace bleibt mit gezielten Probes im einstelligen Prozentbereich CPU-Overhead, wenn ich Folgendes beachte:
- Filtern am Eintritt: Ich filtere früh (z. B. auf comm/PID), statt erst in Maps auszusortieren.
- Sampling: Für sehr heiße Probes verwende ich Sampling, z. B. 1% der Events:
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Stacktraces sparsam: kstack/ustack nur bei Bedarf – zuerst zählen, dann vertiefen.
- Puffergröße: Bei Event-Spitzen erhöhe ich den Ringbuffer:
export BPFTRACE_PERF_RB_PAGES=4096 - Fenster kurz halten: Intervalle (5–30 s) und klares Ende verhindern Datensalat.
Sehe ich „dropped events“, erhöhe ich Puffer, reduziere Stacktiefe oder verschärfe Filter. Für Genauigkeit bevorzuge ich Tracepoints (stabile ABI) gegenüber kprobes (Kernel-Funktionsnamen können variieren).
Sicherheit, Governance und Multi-Tenant-Regeln
Auf Shared-Hosts achte ich strikt auf Datenschutz und klare Scopes. Ich trace technische Signale, nicht Kundendaten, und dokumentiere Anlass, Umfang und Dauer. Für Multi-Tenant-Umgebungen lege ich feste Richtlinien fest: wer starten darf, welche Filter notwendig sind und wann ich das Tracing beende. Logs mit sensiblen Pfaden minimiere oder pseudonymisiere ich. Dadurch erhalte ich verwertbare Technikdaten, ohne Tenant-Grenzen zu verletzen, und halte die Compliance ein.
Installation und Voraussetzungen auf modernen Linux-Servern
Für bpftrace setze ich Linux 5.x ein, weil Features und Stabilität dort spürbar besser sind, auch wenn 4.9 als Untergrenze gilt. Ich installiere bpftrace über apt oder dnf und ergänze Kernel-Header, sobald komplexere Probes nötig werden. Danach prüfe ich cgroup-Setups, Container-Runtimes und Sicherheitsmodule, die Zugriff auf Probes regeln. Ein kurzer Test mit einfachen Tracepoints stellt sicher, dass Signaturen und Symbole passen. So steht einem strukturierten Start nichts im Weg, und ich kann erste Messungen fahren.
Portabilität: BTF, Symbolauflösung und stabile Probes
Für robuste Skripte setze ich auf BTF-Typinformationen (vmlinux), die bpftrace bei der Feldauflösung helfen. Fehlen sie, greife ich bevorzugt zu Tracepoints statt kprobes. Für uprobes (Userland) brauche ich ungestrippte Binaries oder separate Debug-Symbole – gerade bei PHP-FPM oder mysqld lohnt sich das. Ich prüfe Versionen mit „bpftrace –info“ und halte einen kleinen Kompatibilitätsblock in Skripten bereit, falls Event-Namen je nach Kernel variieren.
Praxis-Workflow: Vom Symptom zur Ursache in 15 Minuten
Zuerst formuliere ich die Hypothese: Netzwerk, I/O, CPU oder DB? Dann setze ich je einen schnellen Trace auf die wahrscheinlichste Ebene, zum Beispiel Retransmissions oder Dateilatenzen. Deuten die ersten Minuten auf ein Muster, verfeinere ich Filter, hänge stacktraces dazu und begrenze die Laufzeit. Bestätigt sich der Verdacht, messe ich tiefer im betroffenen Dienst und erfasse nur noch relevante Pfade. Mit diesem Korridor vermeide ich Blindflug und komme zügig zur engsten Ursache.
Runbook: 15-Minuten-Erstangriff
- Minute 0–2: Hypothese wählen (Netz/I/O/CPU/DB). Baseline-One-Liner starten.
- Minute 3–5: Ersten Ausreißer identifizieren (z. B. hoher openat-Count, Retransmits, Futex-Histos).
- Minute 6–8: Filter schärfen (comm/PID/cgroup, Pfade) und Latenz-Histogramme hinzufügen.
- Minute 9–12: Stacktraces nur am Hotspot aktivieren, um Code-Stellen sichtbar zu machen.
- Minute 13–15: Maßnahme ableiten (Caching, Limits, Config-Änderung) und kurz gegentesten.
Vergleichstabelle: Probes und Nutzen im Alltag
Die folgende Tabelle zeigt typische Probes, ihr Einsatzfeld und einen Kernnutzen im Hosting-Kontext. Ich nutze sie als Spickzettel, wenn ich schnell die passende Messstelle wählen will.
| Probe-Typ | Einsatz | Beispiel | Nutzen |
|---|---|---|---|
| tracepoint:syscalls | Systemcalls zählen/filtern | sys_enter_openat, execve | „Laute“ Prozesse finden |
| kprobe/kretprobe | Kernel-Funktionen messen | vfs_read, tcp_retransmit | I/O- und Netz-Latenzen sichtbar |
| uprobes/uretprobes | Userland-Funktionen tracen | mysqld, php-fpm Symbole | DB-/App-Hotspots lokalisieren |
| tracepoint:net/* | Netzwerk-Events erkennen | TCP Retransmits, RST | Timeout-Ursachen eingrenzen |
| perf events | CPU- und Scheduler-Sicht | on-cpu/off-cpu Profile | Scheduling-Engpässe finden |
Zusammenfassung für Admins und DevOps
bpftrace gibt mir eine scharfe Linse auf Kernel- und Applikationssignale, die klassisches Monitoring oft übersieht. Ich starte klein, filtere fokussiert und steuere Laufzeiten, damit die Messergebnisse klar bleiben. Mit wenigen Skriptzeilen erkenne ich Prozesslärm, Dateilatenzen, Netz-Retransmits und DB-Wartezeiten. Dieses Vorgehen verkürzt die Mean Time to Resolution auf produktiven Hosts spürbar. Wer bpftrace in seinen Workflow integriert, löst Hosting-Vorfälle zielgerichtet und hält Webseiten sowie APIs spürbar reaktionsfähig.
