Videre til indhold 
Jeg viser, hvordan bpftrace i Linux-miljøer drastisk reducerer den tid, det tager at finde fejlårsagen, og samtidig Kernen-signaler. I stedet for at gætte måler jeg systemkald, I/O-forsinkelser og netværkshændelser i realtid i eBPF-kontekst – uden at stoppe tjenesterne.
Centrale punkter
Følgende stikord giver et hurtigt overblik over hovedpunkterne i denne artikel.
- Dyb indsigt i systemkald, I/O og netværk direkte fra kernen
- Lavt overhead takket være sikre eBPF-programmer i kernen
- Hurtig indsnævring af proces-, I/O- og databaseflaskehalse
- Fleksibel sporing med filtre, histogrammer og stacktraces
- Arbejdsgang i praksis ved akutte hændelser på få minutter
Hvorfor bpftrace gør det lettere at opdage problemer i hostingmiljøet
I moderne hosting-stacks konkurrerer mange tjenester om Ressourcer, mens klassiske dashboards ofte kun viser overfladiske værdier. Jeg går et niveau dybere: bpftrace hænger sig på systemkald, tracepunkter og funktionshooks og viser mig, hvad der virkelig bremser systemet. Timeouts med ubetydelig CPU-udnyttelse tyder ofte på I/O-forsinkelser eller blokerende opkald. Netop her udmærker bpftrace sig med tællinger, forsinkelseshistogrammer og stacktraces direkte fra Kernen. På den måde tildeler jeg belastningskilderne til bestemte processer, containere eller forespørgsler og handler målrettet.
Hvordan eBPF og bpftrace fungerer sammen
eBPF kører små, testede programmer i Kernen og leverer begivenheder fra første hånd. bpftrace kompilerer scripts under kørsel til eBPF-bytecode og knytter dem til prober, filtre og handlinger. Jeg vælger for eksempel et sporingspunkt for fil-læsninger, filtrerer efter et procesnavn og aggregerer ventetider i et histogram. Mønsteret „probe – filter – handling“ forbliver overskueligt, selv når jeg måler flere signaler samtidigt. På den måde opbygger jeg på få minutter en observation, der giver mig de afgørende Indikatorer forsyninger.
Hurtige one-liners til nødsituationer
I akutte situationer er det afgørende at handle hurtigt. Jeg bruger korte, præcise sætninger, der på få sekunder afslører et mønster. Her er nogle af mine gennemprøvede indledninger:
# Tælle „højlydte“ filadgange efter procesnavn (nulstilles hvert 5. sekund)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
#-latenshistogram for filaflæsninger (pr. proces)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
# Samling af TCP-retransmissioner med kernel-stacks
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# Sammenlægning af SoftIRQ-tider (10-sekunders vindue)
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); }'
Gør # accept()-belastningen synlig på database- eller webserveren
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
Med disse „sonder“ kan jeg hurtigt finde ud af, om en tjeneste åbner unormalt mange filer, om I/O er overbelastet, eller om netværket er overbelastet. Derefter finjusterer jeg filtrene til PID, procesnavne eller stier.
Proces- og ressourcediagnose på live-servere
Hvis en enkelt konto eller container bremser en delt server, tæller jeg systemkald pr. Proces og finder „støjende“ kilder. Et påfaldende stort antal execve-kald tyder på overdreven opstart af processer, hvilket f.eks. afslører fejlbehæftede cron-jobs. Hvis en tjeneste åbner utallige filer, ser jeg det med det samme og indsnævrer kontrollen ved hjælp af filtre til bestemte stier. For stærkt belastede webservere er det guld værd, fordi jeg hurtigt kan afgrænse forstyrrende faktorer. Hvis man ønsker at dykke dybere ned i værktøjsidéer, kan man supplerende se på tilgange til eBPF-analyseværktøjer og overfører princippet til sine egne servere.
Container- og Kubernetes-visning med cgroups
I multi-tenant- eller Kubernetes-værter har jeg brug for en klar adskillelse mellem klienter. bpftrace giver mig muligheden for at cgroup-Perspektivet som nøgle:
# Samle systemkald efter cgroup (container) og procesnavn
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
På den måde kan jeg se, hvilken container der er støjende, uden manuelt at skulle indsamle de enkelte PID’er. Til mere målrettede analyser anvender jeg yderligere filtre:
# Se kun på PHP-FPM (f.eks. i en app-container)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
I Kubernetes måler jeg ofte på Knudepunkt og gruppér efter cgroup. Jeg dokumenterer sammenhængen mellem cgroup-ID’er og pod-/containernavne i mit runbook (kubectl/CRI), så jeg klart kan henvise til måleresultaterne.
Pålidelig måling af I/O- og filsystemforsinkelser
Tunge sider på trods af en „okay“ CPU tyder ofte på I/O-flaskehalse. Jeg måler læse- og skriveoperationer pr. proces, registrerer langsomme stier og opretter latenstidshistogrammer. I WordPress-miljøer kan jeg på den måde se, om det er mange små PHP-filer eller store mediefiler, der bremser gennemstrømningen. Derefter beslutter jeg, om caching, PHP-opcode-cache eller en finjustering af filsystemet skal prioriteres først. Hvis du vil dykke dybere ned i emnet, kan du finde baggrundsinformation om Diskforsinkelser i lagringssystemet og kan målrettet justere målepunkterne.
Vis ventetider for Off-CPU og Lock
Ikke al ventetid er I/O: Tråde kan off-CPU blokere – for eksempel på låse. Til det bruger jeg Futex- og Scheduler-begivenheder.
# Futex-ventetider (lock-contention) som 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]);
}'
Med sådanne profiler kan jeg se, om PHP-FPM-workere eller DB-tråde venter på låse. I kombination med I/O-historikker afbryder jeg Opbevaring- fra Samtidighed-problemer.
Vis netværksfejl, SoftIRQ'er og genudsendelser
Klager over sporadiske timeouts tilskriver jeg ofte Netværk-signaler. Jeg overvåger TCP-retransmissioner, RST-hændelser og forbindelsesafbrydelser direkte i kernen. Derudover kigger jeg på SoftIRQ’er, fordi overbelastede netværkskøer efterlader spor der. Mønsteret med genudsendelser plus stigende SoftIRQ-tider tyder på tabte pakker, bufferflaskehalse eller QoS-problemer. Et godt supplement til fejlfinding er baggrundsartikler om SoftIRQ og netværksgennemstrømning, som jeg knytter sammen med bpftrace-målinger.
Casestudie: WordPress-host med sporadiske 504-timeouts
En delt server viser en 504-fejl, og CPU-udnyttelsen ligger kun på 35%. Min fremgangsmåde:
- Hypotese „Netværk eller I/O“. Jeg starter retransmissioner og måling af SoftIRQ-tid. Resultat: få retransmissioner, SoftIRQ'er stabile.
- Skift til I/O: vfs_read-latens-histo viser en lang hale op til 80 ms for php-fpm. Mange openat-kald pr. anmodning.
- Filtrer efter stier under wp-content og wp-includes: utallige små filaflæsninger dominerer.
- Krydsjek af Locks: Futex-Histo uden afvigelser – ingen Lock-Contention.
- Foranstaltning: Tilpas OPCache-konfigurationen, og cache statiske ressourcer mere aggressivt. Herefter falder antallet af »openat«-tilfælde og ventetiderne.
Med mindre end 15 minutters aktiv sporing står det klart: Det er ikke netværket, men Fil-IO og manglende caching forårsager timeoutene.
Databaser og PHP-FPM: Hurtig lokalisering af flaskehalse
I MySQL/MariaDB ser jeg på systemkald, låse og I/O-forsinkelser i DB-processer Jeg overvåger accept/connect-faser for at se, om forbindelserne går i stå, eller om TLS-håndtryk hænger sig fast. For PHP-FPM tjekker jeg, om execve og filadgang er usædvanligt høj, hvilket tyder på manglende caching. Ved hjælp af stacktraces ved bestemte syscalls kan jeg se, hvor i koden anmodningerne venter. På den måde udelukker jeg trin for trin netværk, app og database og finder den snævreste flaskehals. Sted.
Bedste praksis for produktive servere
Jeg starter hver sporing med en klar Problemstilling og indsnævrer søgninger med filtre. Tidsbegrænsninger eller intervaller holder datamængden på et overskueligt niveau. Til tilbagevendende analyser gemmer jeg scripts med nyttige standardfiltre som PID, cgroup eller procesnavne. Inden jeg anvender dem på kundernes servere, tester jeg krævende scripts på staging-systemer. På den måde holder jeg overheadet lavt og undgår unødvendige Bivirkninger.
Målekvalitet, overhead og grænseværdier i praksis
bpftrace forbliver inden for et encifret procenttal i CPU-overhead med målrettede prober, hvis jeg overholder følgende:
- Filtrering ved indgangen: Jeg filtrerer tidligt (f.eks. efter comm/PID) i stedet for først at sortere i Maps.
- Prøveudtagning: Til meget varme prøver bruger jeg sampling, f.eks. 1% af begivenhederne:
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Brug af stacktraces med måde: kstack/ustack kun efter behov – tæl først, derefter dybdegående.
- Bufferstørrelse: Når der er spidsbelastning ved begivenheder, øger jeg ringbufferen:
export BPFTRACE_PERF_RB_PAGES=4096 - Hold vinduet kort: Intervaller (5–30 s) og en tydelig afslutning forhindrer uoverskuelige data.
Hvis jeg ser „dropped events“, øger jeg bufferen, reducerer stakdybden eller skærper filtrene. For at opnå større nøjagtighed foretrækker jeg Tracepoints (stabil ABI) i forhold til kprobes (kernelfunktionsnavne kan variere).
Sikkerhed, styring og regler for flerbrugerdrift
Når det gælder shared hosting, lægger jeg stor vægt på Databeskyttelse og klare rammer. Jeg sporer tekniske signaler, ikke kundedata, og dokumenterer årsag, omfang og varighed. I multi-tenant-miljøer fastlægger jeg faste retningslinjer: hvem der må starte, hvilke filtre der er nødvendige, og hvornår jeg afslutter sporingen. Logfiler med følsomme stier minimerer eller pseudonymiserer jeg. Dermed får jeg brugbare tekniske data uden at overskride tenant-grænserne og overholder Overensstemmelse i.
Installation og forudsætninger på moderne Linux-servere
Til bpftrace bruger jeg Linux 5.x, fordi funktionerne og Stabilitet der er mærkbart bedre, selvom 4.9 regnes for nedre grænse. Jeg installerer bpftrace via apt eller dnf og tilføjer kernel-headere, så snart der opstår behov for mere komplekse probes. Derefter tjekker jeg cgroup-opsætninger, container-runtimes og sikkerhedsmoduler, der regulerer adgangen til probes. En kort test med enkle tracepoints sikrer, at signaturer og symboler passer. Så står intet i vejen for en struktureret opstart, og jeg kan begynde at Målinger køre.
Bærbarhed: BTF, symbolopløsning og stabile prober
Når det gælder robuste scripts, satser jeg på BTF-Typeoplysninger (vmlinux), der hjælper bpftrace med feltopløsningen. Mangler de, foretrækker jeg at bruge tracepoints frem for kprobes. Til uprobes (Userland) har jeg brug for uredigerede binærfiler eller separate debug-symboler – det er især værd at gøre ved PHP-FPM eller mysqld. Jeg tjekker versionerne med „bpftrace –info“ og har en lille kompatibilitetsblok klar i skripterne, hvis eventnavne varierer afhængigt af kernen.
Arbejdsgang i praksis: Fra symptom til årsag på 15 minutter
Først formulerer jeg Hypotese: Netværk, I/O, CPU eller database? Så sætter jeg en hurtig trace på det mest sandsynlige niveau, for eksempel retransmissioner eller fillatenstider. Hvis de første minutter tyder på et mønster, finjusterer jeg filtrene, tilføjer stacktraces og begrænser køretiden. Bekræftes mistanken, måler jeg dybere ned i den berørte tjeneste og registrerer kun relevante stier. Med denne indsnævring undgår jeg at arbejde i blinde og kommer hurtigt frem til det snævreste Årsag.
Runbook: 15-minutters første indsats
- Minut 0–2: Vælg hypotese (netværk/I/O/CPU/database). Start Baseline-One-Liner.
- Minut 3–5: Identificer den første afvigelse (f.eks. højt antal openat, retransmissioner, Futex-histogrammer).
- Minut 6–8: Skærp filtre (comm/PID/cgroup, stier) og tilføj latenstidshistogrammer.
- Minut 9–12: Aktiver kun stacktraces ved hotspot for at synliggøre bestemte steder i koden.
- Minut 13–15: Udarbejde en foranstaltning (caching, begrænsninger, konfigurationsændring) og teste den kortvarigt.
Sammenligningstabel: Probes og fordele i hverdagen
Den følgende tabel viser typiske Prøver, deres anvendelsesområde og en central fordel i forbindelse med hosting. Jeg bruger dem som en huskeliste, når jeg hurtigt vil vælge det rette målepunkt.
| Prøvetype | Brug | Eksempel | Fordel |
|---|---|---|---|
| tracepoint:syscalls | Tælle/filtrere systemkald | sys_enter_openat, execve | „Højt“ Processer Find |
| k-prøve/kret-prøve | Måling af kernefunktioner | vfs_read, tcp_retransmit | I/O- og netværks-Forsinkelser synlig |
| uprobes/uretprobes | Sporing af Userland-funktioner | mysqld, php-fpm-ikoner | Lokalisere DB-/app-hotspots |
| tracepoint:net/* | Genkende netværksarrangementer | TCP-gentagelser, RST | Timeout-Årsager indsnævre |
| perf events | CPU- og scheduler-perspektiv | on-cpu/off-cpu-profiler | Find flaskehalse i planlægningen |
Resumé til administratorer og DevOps-medarbejdere
bpftrace giver mig en skarp Linse på kerne- og applikationssignaler, som traditionel overvågning ofte overser. Jeg starter i det små, filtrerer målrettet og styrer køretiderne, så måleresultaterne forbliver klare. Med få linjer i et script kan jeg identificere processtøj, filforsinkelser, netværksretransmissioner og databaseventetider. Denne fremgangsmåde forkorter Mean Time to Resolution på produktive værter mærkbart. Den, der integrerer bpftrace i sin arbejdsgang, løser hosting-hændelser målrettet og holder hjemmesider samt API'er mærkbart lydhør.
