BPFtrace bij hosting: serverproblemen sneller opsporen

Ik laat zien hoe bpftrace in Linux-omgevingen de tijd die nodig is om de oorzaak van een fout te achterhalen drastisch verkort, en daarbij Kernel-signalen bruikbaar maakt. In plaats van te gissen, meet ik systeemoproepen, I/O-latenties en netwerkgebeurtenissen live in de eBPF-Context – zonder diensten te onderbreken.

Centrale punten

De volgende punten geven een kort overzicht van de belangrijkste onderwerpen van dit artikel.

• Diepgaand inzicht in systeemaanroepen, I/O en netwerk, rechtstreeks vanuit de kernel
• Lage overhead dankzij veilige eBPF-programma’s in de kernel
• Snelle afbakening van proces-, I/O- en database-bottlenecks
• Flexibele tracering met filters, histogrammen en stacktraces
• Workflow in de praktijk voor acute incidenten binnen enkele minuten

Waarom bpftrace problemen bij hosting sneller aan het licht brengt

In moderne hostingstacks concurreren veel diensten om Bronnen, terwijl klassieke dashboards vaak alleen oppervlakkige waarden weergeven. Ik ga een stapje verder: bpftrace koppelt zich aan systeemaanroepen, tracepunten en functiehooks en laat me zien wat echt voor vertraging zorgt. Time-outs bij een onopvallend CPU-gebruik duiden vaak op I/O-latenties of blokkerende aanroepen. Juist daar blinkt bpftrace uit met tellingen, latentiehistogrammen en stacktraces rechtstreeks uit de Kernel. Zo wijs ik de bronnen van de belasting toe aan specifieke processen, containers of query's en onderneem ik gerichte actie.

Hoe eBPF en bpftrace samenwerken

eBPF voert kleine, geteste programma’s uit in de Kernel en levert gebeurtenissen uit de eerste hand. bpftrace compileert scripts tijdens de uitvoering naar eBPF-bytecode en koppelt deze aan probes, filters en acties. Ik kies bijvoorbeeld een tracepoint voor het lezen van bestanden, filter op een procesnaam en aggregeer latenties in een histogram. Het patroon „probe – filter – actie“ blijft overzichtelijk, zelfs als ik meerdere signalen tegelijk meet. Zo bouw ik binnen enkele minuten een observatie op die mij de cruciale Indicatoren benodigdheden.

Korte oneliners voor noodgevallen

Bij incidenten is snelheid van cruciaal belang. Ik gebruik korte, bondige zinnen die binnen enkele seconden een patroon laten zien. Enkele van mijn beproefde openingszinnen:

# „Luide“ bestandstoegangen tellen op basis van procesnaam (elke 5 seconden leegmaken)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'

# Latentiehistogram voor het lezen van bestanden (per proces)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
  @lat[comm] = hist(nsecs - @ts[tid]);
  delete(@ts[tid]);
}'

# TCP-herverzendingen bundelen met kernelstacks
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'

# SoftIRQ-tijden optellen (venster van 10 s)
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()-belasting op de database- of webserver zichtbaar maken
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'

Met deze „sondes“ kan ik snel vaststellen of een dienst abnormaal veel bestanden opent, de I/O vertraagt of het netwerk overbelast. Daarna verfijn ik de filters op PID, procesnamen of paden.

Proces- en hulpbronnendiagnose op live-servers

Als één account of container een gedeelde server vertraagt, tel ik het aantal systeemaanroepen per Proces en zoek naar „luidruchtige“ boosdoeners. Opvallend veel execve-aanroepen wijzen op een overmatig aantal processtarts, wat bijvoorbeeld op foutieve cronjobs duidt. Als een dienst ontelbare bestanden opent, zie ik dat meteen en beperk ik de controle met behulp van filters tot bepaalde paden. Voor drukbezochte webservers is dat van onschatbare waarde, omdat ik storende factoren snel kan afbakenen. Wie dieper in tooling-ideeën wil duiken, kan aanvullend kijken naar benaderingen voor eBPF-analysetools en past het principe toe op zijn eigen hosts.

Container- en Kubernetes-overzicht met cgroups

Op multi-tenant- of Kubernetes-hosts heb ik een duidelijke scheiding tussen tenants nodig. bpftrace biedt mij daarvoor de cgroup-Het perspectief als sleutel:

# Systeemaanroepen groeperen op cgroup (container) en procesnaam
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'

Zo kan ik zien welke container lawaai maakt, zonder handmatig afzonderlijke PID’s te hoeven verzamelen. Voor gerichte analyses pas ik extra filters toe:

# Alleen PHP-FPM bekijken (bijvoorbeeld in een app-container)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'

In Kubernetes meet ik vaak op de Knooppunt en groepeer op cgroup. De toewijzing van cgroup-ID's aan pod-/containernamen leg ik vast in mijn runbook (kubectl/CRI), zodat ik duidelijk naar de meetresultaten kan verwijzen.

I/O- en bestandssysteemlatenties betrouwbaar meten

Trage pagina's ondanks een „redelijke“ CPU duiden vaak op I/O-knelpunten. Ik meet lees- en schrijfbewerkingen per proces, registreer trage paden en stel latentiehistogrammen op. In WordPress-omgevingen kan ik hierdoor vaststellen of veel kleine PHP-bestanden of grote mediabestanden de doorvoer beperken. Vervolgens beslis ik of caching, de PHP-opcode-cache of het optimaliseren van het bestandssysteem het beste resultaat oplevert. Wie zich hier verder in wil verdiepen, vindt achtergrondinformatie over Schijfvertragingen in de opslag en kan meetpunten gericht aanpassen.

Off-CPU- en lock-wachttijden zichtbaar maken

Niet elke wachttijd is I/O: threads kunnen off-CPU blokkeren – bijvoorbeeld op Locks. Ik gebruik daarvoor Futex- en Scheduler-events.

# Futex-wachttijden (lock-contention) als histogram
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]);
}'

Met dergelijke profielen kan ik zien of PHP-FPM-workers of DB-threads op locks wachten. In combinatie met I/O-statistieken verbreek ik de verbinding Opslag- van Concurrentie-problemen.

Netwerkfouten, SoftIRQ's en hertransmissies zichtbaar maken

Klachten over sporadische time-outs schrijf ik vaak toe aan Netwerk-signalen terug. Ik houd TCP-hertransmissies, RST-gebeurtenissen en verbroken verbindingen rechtstreeks in de kernel in de gaten. Daarnaast kijk ik ook naar SoftIRQ’s, omdat overbelaste netwerkwachtrijen daar sporen achterlaten. Het patroon van hertransmissies in combinatie met toenemende SoftIRQ-tijden duidt op drops, bufferknelpunten of QoS-problemen. Een goede aanvulling bij het opsporen van de oorzaak zijn achtergrondartikelen over SoftIRQ en netwerkdoorvoer, die ik koppel aan bpftrace-metingen.

Praktijkvoorbeeld: WordPress-host met sporadische 504-time-outs

Een shared server geeft 504-fouten weer, de CPU zit slechts op 35%. Mijn werkwijze:

• Hypothese „Netwerk of I/O“. Ik start de hertransmissies en de SoftIRQ-tijdmeting. Resultaat: weinig hertransmissies, SoftIRQ’s stabiel.
• Overgang naar I/O: de vfs_read-latentiehistogram laat een lange staart zien tot 80 ms voor php-fpm. Veel openat-aanroepen per verzoek.
• Filter op paden onder wp-content en wp-includes: er zijn ontelbare kleine bestandslezingen.
• Controle van de locks: Futex-Histo zonder afwijkingen – geen lock-contention.
• Maatregel: de OPCache-configuratie aanpassen, statische assets agressiever in de cache opslaan. Hierdoor dalen het aantal openat-counts en de latentie.

Met minder dan 15 minuten actieve tracering is het duidelijk: niet het netwerk, maar Bestands-IO en ontbrekende caching veroorzaken de time-outs.

Databases en PHP-FPM: knelpunten snel opsporen

Bij MySQL/MariaDB bekijk ik de systeemaanroepen, vergrendelingen en I/O-vertragingen van de DB-processen . Ik volg de accept/connect-fasen om te zien of verbindingen haperen of dat TLS-handshakes vastlopen. Voor PHP-FPM controleer ik of het aantal execve-aanroepen en bestandstoegangen opvallend hoog is, wat duidt op een gebrek aan caching. Met stacktraces bij bepaalde syscalls kan ik vaststellen op welke plek in de code verzoeken wachten. Zo sluit ik stap voor stap het netwerk, de app en de database uit en vind ik de meest waarschijnlijke Plaats.

Best practices voor productieve servers

Ik begin elke tracering met een duidelijke Vraagstelling en beperk de probes met filters. Tijdslimieten of intervallen zorgen ervoor dat de hoeveelheid gegevens beheersbaar blijft. Voor terugkerende analyses sla ik scripts op met zinvolle standaardfilters zoals PID, cgroup of procesnamen. Voordat ik ze op de hosts van klanten gebruik, test ik veeleisende scripts op staging-systemen. Zo blijft de overhead laag en voorkom ik onnodige Bijwerkingen.

Meetkwaliteit, overhead en limieten in de praktijk

bpftrace blijft, met gerichte probes, binnen een CPU-overhead van minder dan 10 procent, als ik het volgende in acht neem:

• Filteren bij de inlaat: Ik filter al vroeg (bijvoorbeeld op comm/PID), in plaats van pas in Maps te sorteren.
• Bemonstering: Voor zeer hete monsters gebruik ik sampling, bijvoorbeeld 1% van de gebeurtenissen:

  tracepoint:syscalls:sys_enter_openat
  / rand() % 100 == 0 / { @[comm] = count(); }

• Stacktraces spaarzaam gebruiken: kstack/ustack alleen indien nodig – eerst tellen, dan verdiepen.
• Buffergrootte: Bij pieken in het aantal evenementen vergroot ik de ringbuffer:

  export BPFTRACE_PERF_RB_PAGES=4096

• Houd het venster kort: Intervallen (5–30 s) en een duidelijk einde voorkomen dat de gegevens door elkaar raken.

Als ik „dropped events“ zie, vergroot ik de buffer, verklein ik de stackdiepte of verscherp ik de filters. Voor nauwkeurigheid geef ik de voorkeur aan Tracepunten (stabiele ABI) ten opzichte van kprobes (de namen van kernel-functies kunnen variëren).

Beveiliging, governance en regels voor multi-tenant

Bij shared hosting let ik strikt op Gegevensbescherming en duidelijke reikwijdtes. Ik traceer technische signalen, geen klantgegevens, en documenteer de aanleiding, de omvang en de duur. Voor multi-tenant-omgevingen stel ik vaste richtlijnen vast: wie er mag starten, welke filters nodig zijn en wanneer ik het traceren beëindig. Logs met gevoelige paden minimaliseer of pseudonimiseer ik. Hierdoor verkrijg ik bruikbare technische gegevens zonder de grenzen van de tenants te overschrijden, en houd ik de Naleving in.

Installatie en vereisten op moderne Linux-servers

Voor bpftrace gebruik ik Linux 5.x, omdat de functies en Stabiliteit daar merkbaar beter zijn, ook al geldt 4.9 als ondergrens. Ik installeer bpftrace via apt of dnf en voeg kernel-headers toe zodra er complexere probes nodig zijn. Vervolgens controleer ik cgroup-configuraties, container-runtimes en beveiligingsmodules die de toegang tot probes regelen. Een korte test met eenvoudige tracepoints zorgt ervoor dat handtekeningen en symbolen kloppen. Zo staat niets een gestructureerde start meer in de weg en kan ik de eerste Metingen rijden.

Draagbaarheid: BTF, symboolresolutie en stabiele sondes

Voor robuuste scripts vertrouw ik op BTF-Type-informatie (vmlinux) die bpftrace helpt bij het oplossen van velden. Als deze ontbreken, geef ik de voorkeur aan tracepoints boven kprobes. Voor uprobes (Userland) heb ik niet-gestripte binaire bestanden of aparte debug-symbolen nodig – vooral bij PHP-FPM of mysqld is dat de moeite waard. Ik controleer versies met „bpftrace –info“ en zorg voor een klein compatibiliteitsblok in scripts, voor het geval dat eventnamen per kernel verschillen.

Workflow in de praktijk: van symptoom naar oorzaak in 15 minuten

Eerst formuleer ik de Hypothese: Netwerk, I/O, CPU of database? Dan zet ik telkens een snelle trace in op het meest waarschijnlijke niveau, bijvoorbeeld hertransmissies of bestandslatenties. Als de eerste minuten een patroon laten zien, verfijn ik de filters, voeg ik stacktraces toe en beperk ik de looptijd. Als het vermoeden wordt bevestigd, meet ik dieper in de betreffende dienst en leg ik alleen nog relevante paden vast. Met deze focus voorkom ik dat ik op goed geluk te werk ga en kom ik snel tot de meest specifieke oorzaak. Oorzaak.

Runbook: Eerste aanpak in 15 minuten

• Minute 0–2: Hypothese selecteren (netwerk/I/O/CPU/DB). Baseline-One-Liner starten.
• Minute 3–5: De eerste afwijking identificeren (bijv. een hoog aantal openat-counts, heruitzendingen, Futex-histogrammen).
• Minute 6–8: Filters verfijnen (comm/PID/cgroup, paden) en latentiehistogrammen toevoegen.
• Minute 9–12: Activeer stacktraces alleen bij de hotspot om bepaalde delen van de code zichtbaar te maken.
• Minute 13–15: Maatregel vaststellen (caching, limieten, configuratiewijziging) en kort testen.

Vergelijkingstabel: Probes en voordelen in het dagelijks leven

De volgende tabel toont typische Probes, hun toepassingsgebied en een belangrijk voordeel in de context van hosting. Ik gebruik ze als spiekbriefje als ik snel het juiste meetpunt wil kiezen.

Type monster	Gebruik	Voorbeeld	Voordeel
tracepoint:syscalls	Systeemaanroepen tellen/filteren	sys_enter_openat, execve	„Luid“ Processen Zoek
kprobe/kretprobe	Kernelfuncties meten	vfs_read, tcp_retransmit	I/O- en netwerk-Latencies zichtbaar
uprobes/uretprobes	Userland-functies traceren	mysqld, php-fpm-symbolen	DB-/app-hotspots lokaliseren
tracepoint:net/*	Netwerkevenementen herkennen	TCP-herverzendingen, RST	Time-out-Oorzaken beperken
perf events	CPU- en scheduler-perspectief	on-cpu/off-cpu-profielen	Knelpunten in de planning opsporen

Samenvatting voor beheerders en DevOps

bpftrace geeft me een scherpe Lens op kernel- en applicatiesignalen die bij klassieke monitoring vaak over het hoofd worden gezien. Ik begin klein, filter gericht en beheer de looptijden, zodat de meetresultaten duidelijk blijven. Met slechts enkele regels script herken ik procesruis, bestandsvertragingen, netwerkhertransmissies en database-wachttijden. Deze aanpak verkort de Mean Time to Resolution op productieve hosts merkbaar. Wie bpftrace in zijn workflow integreert, lost hostingincidenten doelgericht op en houdt websites en API’s merkbaar responsief.