Hoppa till innehåll 
Jag visar hur bpftrace i Linux-miljöer drastiskt förkortar tiden det tar att hitta felkällan och samtidigt Kärnan-signaler. Istället för att gissa mäter jag systemanrop, I/O-fördröjningar och nätverkshändelser i realtid i eBPF-Sammanhang – utan att avbryta tjänsterna.
Centrala punkter
Följande punkter ger en snabb översikt över de viktigaste delarna i denna artikel.
- Djupgående inblick i systemanrop, I/O och nätverk direkt från kärnan
- Låg overhead tack vare säkra eBPF-program i kärnan
- Snabb avgränsning av flaskhalsar i processer, I/O och databaser
- Flexibel spårning med filter, histogram och stacktraces
- Arbetsflöde i praktiken för akuta händelser i minuter
Varför bpftrace gör det lättare att upptäcka problem i webbhotellet
I moderna hosting-stackar konkurrerar många tjänster om Resurser, medan traditionella instrumentpaneler ofta bara visar ytliga värden. Jag går ett steg djupare: bpftrace kopplar sig till systemanrop, spårningspunkter och funktionshakar och visar mig vad som verkligen bromsar systemet. Timeouts med obetydlig CPU-belastning tyder ofta på I/O-fördröjningar eller blockerande anrop. Det är just där bpftrace utmärker sig med räkningar, latenshistogram och stacktraces direkt från Kärnan. På så sätt kopplar jag belastningskällorna till specifika processer, containrar eller sökningar och vidtar riktade åtgärder.
Hur eBPF och bpftrace samverkar
eBPF kör små, verifierade program i Kärnan och levererar händelser direkt från källan. bpftrace kompilerar skript till eBPF-bytecode under körning och kopplar dem till prober, filter och åtgärder. Jag väljer till exempel en spårningspunkt för filinläsningar, filtrerar på ett processnamn och sammanställer fördröjningarna i ett histogram. Mönstret „probe – filter – åtgärd“ förblir överskådligt, även när jag mäter flera signaler samtidigt. På så sätt bygger jag på några minuter en observation som ger mig de avgörande Indikatorer förnödenheter.
Snabba oneliners för nödfall
I akuta situationer är det hastigheten som räknas. Jag använder kortfattade enradare som visar ett mönster på några sekunder. Här är några av mina beprövade inledningar:
# Räkna „högljudda“ filåtkomster efter processnamn (töm var 5:e sekund)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
# Latenshistogram för filavläsningar (per process)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
# Sammanfoga TCP-återutsändningar med kärnstaplar
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# Summera SoftIRQ-tider (10 sekunders fönster)
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); }'
# visa belastningen från accept() på databas- eller webbservern
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
Med dessa „sonder“ kan jag snabbt ta reda på om en tjänst öppnar onormalt många filer, om I/O-operationen går trögt eller om nätverket överbelastas. Därefter finjusterar jag filtren till PID, processnamn eller sökvägar.
Process- och resursdiagnostik på live-servrar
Om ett enskilt konto eller en enskild behållare bromsar upp en delad server, räknar jag systemanrop per Process och hittar „högljudda“ källor. Ett påfallande stort antal execve-anrop tyder på överdrivna processstarter, vilket till exempel avslöjar felaktiga cron-jobb. Om en tjänst öppnar otaliga filer ser jag det omedelbart och begränsar granskningen med hjälp av filter till specifika sökvägar. För högtrafikerade webbservrar är detta guld värt, eftersom jag snabbt kan isolera störande faktorer. Den som vill fördjupa sig i verktygsidéer kan även titta på tillvägagångssätt för eBPF-analysverktyg och tillämpar principen på sina egna värddatorer.
Container- och Kubernetes-vy med cgroups
I multi-tenant- eller Kubernetes-värdar behöver jag en tydlig åtskillnad mellan klienter. bpftrace ger mig möjligheten att cgroup-Perspektivet som nyckel:
# Sammanställa systemanrop efter cgroup (container) och processnamn
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
På så sätt kan jag se vilken container som är högljudd utan att behöva samla in enskilda PID:er manuellt. För mer detaljerade analyser använder jag ytterligare filter:
# Endast visa PHP-FPM (t.ex. i en app-container)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
I Kubernetes mäter jag ofta vid Nod och gruppera efter cgroup. Jag dokumenterar kopplingen mellan cgroup-ID:n och pod-/containernamnen i min runbook (kubectl/CRI) så att jag tydligt kan hänvisa till mätresultaten.
Mäta I/O- och filsystemets latenser på ett tillförlitligt sätt
Långsamma sidor trots en „hyfsad“ processor tyder ofta på I/O-flaskhalsar. Jag mäter läs- och skrivoperationer per process, loggar långsamma vägar och skapar histogram över latens. I WordPress-miljöer kan jag på så sätt avgöra om det är många små PHP-filer eller stora mediefiler som hämmar genomströmningen. Därefter avgör jag om caching, PHP-opcode-cache eller en finjustering av filsystemet bör tillämpas först. Den som vill fördjupa sig ytterligare hittar bakgrundsinformation om Skivfördröjningar i lagringssystemet och kan anpassa mätpunkterna på ett målinriktat sätt.
Visa väntetider för Off-CPU och Lock
Inte all väntetid är I/O: Trådar kan off-CPU blockera – till exempel på lås. Jag använder Futex- och Scheduler-händelser för detta.
# Futex-väntetider (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ådana profiler kan jag se om PHP-FPM-arbetare eller databastrådar väntar på lås. I kombination med I/O-historik avbryter jag Förvaring- från Samtidighet-problem.
Visa nätverksfel, SoftIRQ:er och återutsändningar
Jag brukar ofta tillskriva klagomål om sporadiska timeouts till Nätverk-signaler. Jag övervakar TCP-återutsändningar, RST-händelser och anslutningsavbrott direkt i kärnan. Dessutom tittar jag på SoftIRQ:er, eftersom överbelastade nätverksköer lämnar spår där. Mönstret med återutsändningar i kombination med ökande SoftIRQ-tider tyder på bortfall, buffertflaskhalsar eller QoS-problem. Ett bra komplement för felsökningen är bakgrundsartiklar om SoftIRQ och genomströmning i nätverket, som jag kopplar samman med mätningar från bpftrace.
Fallstudie: WordPress-värd med sporadiska 504-timeouts
En delad server visar 504-fel, och CPU-användningen ligger bara på 35%. Min procedur:
- Hypotes: „Nätverk eller I/O“. Jag startar återutsändningar och mäter SoftIRQ-tiden. Resultat: få återutsändningar, SoftIRQ-värdena är stabila.
- Övergång till I/O: vfs_read-latenshistoriken visar en lång svans upp till 80 ms för php-fpm. Många openat-anrop per begäran.
- Filtrera efter sökvägar under wp-content och wp-includes: otaliga små filavläsningar dominerar.
- Korskontroll av lås: Futex-Histo utan avvikelser – ingen låskonflikt.
- Åtgärd: Justera OPCache-konfigurationen och cacha statiska resurser mer aggressivt. Därefter minskar antalet öppningar och latensen.
Med mindre än 15 minuters aktiv spårning står det klart: Det är inte nätverket, utan Fil-I/O och avsaknad av caching orsakar tidsöverskridningarna.
Databaser och PHP-FPM: Snabbt identifiera flaskhalsar
När det gäller MySQL/MariaDB tittar jag på systemanrop, låsningar och I/O-fördröjningar för DB-processer Jag övervakar accept/connect-faserna för att se om anslutningarna stockar sig eller om TLS-handshakes fastnar. För PHP-FPM kontrollerar jag om execve och filåtkomst är onormalt höga, vilket tyder på bristande caching. Med hjälp av stacktraces vid vissa systemanrop kan jag se vid vilken kodpunkt förfrågningarna väntar. På så sätt utesluter jag stegvis nätverk, app och databas och hittar den mest troliga orsaken. Plats.
Bästa praxis för produktiva servrar
Jag inleder varje spårning med en tydlig Frågeställning och begränsar proberna med filter. Tidsbegränsningar eller intervall gör att datamängden förblir hanterbar. För återkommande analyser sparar jag skript med lämpliga standardfilter som PID, cgroup eller processnamn. Innan jag använder dem på kundernas servrar testar jag krävande skript på staging-system. På så sätt hålls overheaden låg och jag undviker onödiga Biverkningar.
Mätkvalitet, overhead och gränsvärden i praktiken
bpftrace håller sig inom en ensiffrig procentandel i CPU-överbelastning med riktade prober, om jag beaktar följande:
- Filtrering vid inloppet: Jag filtrerar tidigt (t.ex. på comm/PID) istället för att först sortera bort i Maps.
- Provtagning: För mycket heta prover använder jag sampling, t.ex. 1% av händelserna:
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Använd stacktraces sparsamt: kstack/ustack endast vid behov – räkna först, fördjupa sedan.
- Buffertstorlek: Vid toppbelastningar under evenemang ökar jag ringbuffertens storlek:
export BPFTRACE_PERF_RB_PAGES=4096 - Håll fönstret öppet en kort stund: Intervall (5–30 s) och ett tydligt slut förhindrar att data blir oöverskådlig.
Om jag ser „dropped events“ ökar jag buffertstorleken, minskar stackdjupet eller skärper filtren. För att uppnå noggrannhet föredrar jag Tracepoints (stabila ABI) jämfört med kprobes (kärnfunktionernas namn kan variera).
Säkerhet, styrning och regler för fleranvändarmiljöer
När det gäller delade webbhotell är jag mycket noga med Uppgiftsskydd och tydliga avgränsningar. Jag spårar tekniska signaler, inte kunddata, och dokumenterar anledning, omfattning och varaktighet. För miljöer med flera kunder fastställer jag fasta riktlinjer: vem som får starta, vilka filter som krävs och när jag avslutar spårningen. Loggar med känsliga sökvägar minimerar eller pseudonymiserar jag. På så sätt får jag användbara tekniska data utan att överskrida gränserna mellan kunderna och upprätthåller Efterlevnad i.
Installation och krav på moderna Linux-servrar
För bpftrace använder jag Linux 5.x, eftersom funktioner och Stabilitet är märkbart bättre där, även om 4.9 anses vara en nedre gräns. Jag installerar bpftrace via apt eller dnf och lägger till kärnhuvuden så snart mer komplexa prober behövs. Därefter kontrollerar jag cgroup-konfigurationer, container-runtimes och säkerhetsmoduler som reglerar åtkomsten till proberna. Ett kort test med enkla tracepoints säkerställer att signaturer och symboler stämmer. På så sätt står inget i vägen för en strukturerad start, och jag kan börja Mätningar köra.
Portabilitet: BTF, symbolupplösning och stabila prober
För robusta skript förlitar jag mig på BTF-Typinformation (vmlinux) som hjälper bpftrace vid fältupplösning. Om den saknas föredrar jag att använda tracepoints istället för kprobes. För uprobes (Userland) behöver jag obearbetade binärfiler eller separata felsökningssymboler – särskilt när det gäller PHP-FPM eller mysqld lönar det sig. Jag kontrollerar versionerna med „bpftrace –info“ och har ett litet kompatibilitetsblock redo i skripten, ifall händelsenamn varierar beroende på kärnan.
Arbetsflöde i praktiken: Från symptom till orsak på 15 minuter
Först formulerar jag Hypotes: Nätverk, I/O, CPU eller databas? Då sätter jag upp en snabb spårning på den mest troliga nivån, till exempel vid återutsändningar eller fillatenser. Om de första minuterna tyder på ett mönster, finjusterar jag filtren, lägger till stacktraces och begränsar körtiden. Om misstanken bekräftas mäter jag djupare in i den berörda tjänsten och registrerar endast relevanta vägar. Med detta avgränsade område undviker jag att gå i blindo och kommer snabbt fram till den snävaste Orsak.
Handbok: 15-minuters första insats
- Minut 0–2: Välj hypotes (nätverk/I/O/CPU/databas). Starta Baseline-One-Liner.
- Minut 3–5: Identifiera den första avvikelsen (t.ex. högt antal openat, återutsändningar, Futex-historik).
- Minut 6–8: Förbättra filtren (comm/PID/cgroup, sökvägar) och lägg till latenshistogram.
- Minut 9–12: Aktivera stacktraces endast vid hotspot för att synliggöra specifika delar av koden.
- Minut 13–15: Identifiera åtgärden (caching, gränsvärden, konfigurationsändring) och testa den kort.
Jämförelsetabell: Probes och fördelar i vardagen
Följande tabell visar typiska Prover, deras tillämpningsområde och en viktig fördel i samband med webbhotell. Jag använder dem som en liten hjälp när jag snabbt vill välja rätt mätpunkt.
| Provtyp | Användning | Exempel | Förmån |
|---|---|---|---|
| tracepoint:syscalls | Räkna/filtrera systemanrop | sys_enter_openat, execve | „Höga“ Processer Hitta |
| kprobe/kretprobe | Mäta kärnfunktioner | vfs_read, tcp_retransmit | I/O- och nätverks-Fördröjningar synlig |
| uprobes/uretprobes | Spåra Userland-funktioner | mysqld, php-fpm-symboler | Lokalisera DB-/app-hotspots |
| tracepoint:net/* | Identifiera nätverksaktiviteter | TCP-återutsändningar, RST | Timeout-Orsaker begränsa |
| perf events | Ur CPU:ns och schemaläggarens perspektiv | on-cpu/off-cpu-profiler | Hitta flaskhalsar i schemaläggningen |
Sammanfattning för administratörer och DevOps
bpftrace ger mig en skarp Lins på signaler från kärnan och applikationer som ofta förbises vid traditionell övervakning. Jag börjar i liten skala, filtrerar målmedvetet och styr körtiderna så att mätresultaten förblir tydliga. Med några få rader skript kan jag upptäcka processbrus, filfördröjningar, nätverksåterutsändningar och databasväntetider. Denna metod förkortar Mean Time to Resolution på produktiva värdar märkbart. Den som integrerar bpftrace i sin arbetsflöde löser hostingincidenter på ett målinriktat sätt och håller webbplatser och API:er märkbart lyhörd.
