Einführung
Produktions-Profilierung war schon immer die Domäne der Mutigen. Jahrelang standen SREs vor einem unbequemen Kompromiss: entweder schwergewichtige Profilierungswerkzeuge anhängen, die messbare Latenz einführten und riskierten, Produktions-Workloads zu destabilisieren, oder blind fliegen und sich auf Metrik-Dashboards verlassen, die Symptome zeigten, aber niemals Ursachen. Das Aufkommen von eBPF als Mainstream-Linux-Kernel-Technologie hat dieses Kalkül grundlegend verändert. Mit eBPF können Sie nahezu jede Schicht des Kernels und des Userspace mit vernachlässigbarem Overhead instrumentieren und die Art von tiefen Observability-Daten erzeugen, die zuvor nur in Staging-Umgebungen verfügbar waren.
eBPF, was für extended Berkeley Packet Filter steht, entwickelte sich von seinen Ursprüngen als Netzwerk-Paketfilter-Mechanismus zu einer universellen In-Kernel-Virtual-Machine. Programme, die für eBPF geschrieben werden, werden vom Kernel vor der Ausführung verifiziert, wodurch sichergestellt wird, dass sie das System nicht zum Absturz bringen, in Endlosschleifen geraten oder auf nicht autorisierten Speicher zugreifen können. Diese Sicherheitsgarantie macht eBPF einzigartig geeignet für Produktions-Profilierung. Sie können Probes an Kernel-Funktionen, Tracepoints, Userspace-Funktionseinstiege und Hardware-Performance-Counter anhängen, ohne den Kernel neu zu kompilieren oder Dienste neu zu starten.
Dieser Leitfaden behandelt die praktischen Workflows, die SRE-Teams täglich zur Diagnose von Performance-Problemen in Linux-Produktionssystemen verwenden. Wir werden CPU-Profilierung, Latenz-Analyse, Speicherleck-Erkennung, Netzwerk-Tracing und I/O-Profilierung mit der Standard-eBPF-Toolchain durchgehen. Jeder hier gezeigte Befehl und jedes Skript wurde in Produktionsumgebungen mit Kernel 5.15 und neuer verwendet.
Warum eBPF die Produktions-Profilierung Verändert
Traditionelle Profilierungswerkzeuge verursachen Kosten, die sie in der Produktion unpraktikabel machen. Das Ausführen von strace auf einem ausgelasteten Dienst kann ihn um den Faktor 100x oder mehr verlangsamen, da strace ptrace verwendet, um jeden Syscall abzufangen und für jede Aufrufung zwischen dem getrackten Prozess und dem Tracing-Prozess hin und her wechselt. Selbst perf, das Hardware-Performance-Counter verwendet und viel leichter als strace ist, erfordert noch das Schreiben von Sampling-Daten auf die Festplatte und kann bei hohen Abtastraten erheblichen I/O-Druck erzeugen.
eBPF ändert die Gleichung auf drei wichtige Weisen. Erstens laufen eBPF-Programme innerhalb des Kernels und eliminieren den Context-Switch-Overhead von ptrace-basierten Werkzeugen. Wenn Sie einen kprobe oder Tracepoint anhängen, führt das eBPF-Programm sich inline mit dem Kernel-Codepfad aus und fügt typischerweise nur Dutzende von Nanosekunden pro Aufruf hinzu. Zweitens können eBPF-Programme Daten im Kernel mit Maps aggregieren, was bedeutet, dass Sie Histogramme, Zählungen und Zusammenfassungen berechnen können, ohne jedes Ereignis in den Userspace zu kopieren. Ein Latenz-Histogramm, das mit strace Millionen von Ereignissen pro Sekunde erzeugen würde, produziert mit eBPF eine einzige Map-Lesung pro Intervall. Drittens garantiert der eBPF-Verifier die Sicherheit: Ihr Programm kann keine Null-Pointer dereferenzieren, auf Speicher außerhalb der Grenzen zugreifen oder unendlich loopen.
Die praktische Auswirkung ist dramatisch. Werkzeuge wie biolatency können jede Block-I/O-Anfrage auf einem System verfolgen, das Hunderttausende von IOPS verarbeitet, und ein Latenz-Histogramm mit weniger als 1% CPU-Overhead produzieren. Sie können funclatency gegen eine heiße Funktion in Ihrem Anwendungsserver ausführen, während Sie Spitzen-Traffic bedienen. Dies war mit früheren Generationen von Tracing-Werkzeugen einfach nicht möglich.
Einrichtung der eBPF-Toolchain
Das eBPF-Ökosystem hat sich um drei primäre Toolsets konsolidiert: bcc-tools, bpftrace und libbpf-basierte CO-RE-Programme. Jedes dient einem anderen Anwendungsfall, und eine gut ausgestattete SRE-Workstation sollte alle drei verfügbar haben.
Auf Ubuntu- und Debian-Systemen installieren Sie die vollständige Toolchain:
sudo apt-get update
sudo apt-get install -y bpfcc-tools bpftrace linux-headers-$(uname -r)
sudo apt-get install -y libbpf-dev bpftool
Auf RHEL- und Fedora-Systemen:
sudo dnf install -y bcc-tools bpftrace kernel-devel-$(uname -r)
sudo dnf install -y libbpf-devel bpftool
Überprüfen Sie, ob Ihr Kernel BTF unterstützt, das für moderne bpftrace-Funktionen und CO-RE-Programme erforderlich ist:
ls /sys/kernel/btf/vmlinux
bpftool btf dump file /sys/kernel/btf/vmlinux format raw | head -c 100
Wenn BTF nicht verfügbar ist, müssen Sie sicherstellen, dass Ihr Kernel mit CONFIG_DEBUG_INFO_BTF=y kompiliert wurde. Die meisten Distributions-Kernel ab 2022 beinhalten BTF-Unterstützung.
Das bcc-tools-Paket bietet Dutzende von gebrauchsfertigen Werkzeugen, die die häufigsten Profilierungsszenarien abdecken. Diese werden typischerweise als Executables mit einem -bpfcc-Suffix auf Debian-basierten Systemen oder direkt unter /usr/share/bcc/tools/ auf RHEL installiert. Bpftrace bietet eine High-Level-Skriptsprache zum Schreiben von benutzerdefinierten One-Linern und kurzen Skripten. Libbpf und CO-RE (Compile Once, Run Everywhere) Programme werden zum Erstellen von portablen, produktionsreifen eBPF-Werkzeugen verwendet, die als eigenständige Binärdateien ausgeliefert werden.
CPU-Profilierungs-Workflows
CPU-Profilierung ist der häufigste Ausgangspunkt bei der Untersuchung von Performance-Problemen. Das Ziel ist es zu identifizieren, welche Funktionen die meiste CPU-Zeit verbrauchen, ob im Kernel- oder Userspace, und Flame-Graphs zu erzeugen, die Hotspots visuell offensichtlich machen.
Der einfachste Ansatz verwendet das bcc-profile-Werkzeug, um Stack-Traces mit einer festen Frequenz zu sampeln:
sudo profile-bpfcc -F 99 -a --stack-storage-size 16384 30 > /tmp/cpu-stacks.txt
Dies sampelt alle CPUs bei 99 Hz für 30 Sekunden. Die 99-Hz-Frequenz vermeidet Aliasing mit Timer-basierter Aktivität, die oft bei 100 Hz läuft. Die Ausgabe enthält gefaltete Stack-Traces, die direkt in Brendan Greggs FlameGraph-Werkzeuge eingespeist werden können:
git clone https://github.com/brendangregg/FlameGraph.git
cat /tmp/cpu-stacks.txt | FlameGraph/stackcollapse-bpf.pl | FlameGraph/flamegraph.pl > cpu-flame.svg
Für gezieltere Profilierung ermöglicht bpftrace das Profilieren eines bestimmten Prozesses und Filtern nach CPU:
sudo bpftrace -e 'profile:hz:99 /pid == 12345/ { @[ustack(perf), comm] = count(); }' > stacks.bt
Wenn Sie das CPU-Scheduling-Verhalten verstehen müssen anstatt der Ausführungszeit, zeigt das cpudist-Werkzeug, wie lange Threads auf der CPU laufen, bevor sie de-scheduled werden:
sudo cpudist-bpfcc -p 12345 10 1
Dies druckt ein Histogramm der On-CPU-Dauern für Prozess 12345 über ein 10-Sekunden-Intervall. Kurze On-CPU-Zeiten kombiniert mit hohen Context-Switches deuten auf Lock-Contention hin. Lange On-CPU-Zeiten mit niedrigem Durchsatz deuten auf Berechnungsengpässe hin.
Zur Untersuchung von CPU-Migrationsproblemen in NUMA-Systemen können Sie Scheduler-Ereignisse tracen:
sudo bpftrace -e 'tracepoint:sched:sched_migrate_task {
printf("pid=%d comm=%s from_cpu=%d to_cpu=%d\n",
args->pid, args->comm, args->orig_cpu, args->dest_cpu);
}'
Latenz-Analyse
Die Latenz-Analyse ist der Bereich, in dem eBPF wirklich glänzt, weil es die Zeit zwischen beliebigen Ereignissen messen kann, ohne den gemessenen Codepfad zu stören. Die bcc-tools-Sammlung umfasst mehrere speziell entwickelte Latenz-Werkzeuge.
Die Block-I/O-Latenz wird mit biolatency gemessen, das die Zeit von der Block-I/O-Anfrage bis zur Fertigstellung verfolgt:
sudo biolatency-bpfcc -D 10 1
Das -D-Flag schlüsselt die Latenz nach Disk-Device auf, was es einfach macht, langsame Laufwerke zu identifizieren. Die Ausgabe ist ein Zweierpotenzen-Histogramm, das die Verteilung der Latenzen in Mikrosekunden zeigt.
Die Run-Queue-Latenz, die misst, wie lange Threads in der Scheduler-Warteschlange warten, bevor sie CPU-Zeit erhalten, wird mit runqlat gemessen:
sudo runqlat-bpfcc -p 12345 10 1
Hohe Run-Queue-Latenz bedeutet, dass Ihre Prozesse auf CPU warten, was auf CPU-Sättigung hinweist. Wenn Sie im Normalbetrieb Latenzen über 10 Millisekunden sehen, benötigen Sie entweder mehr CPU-Kapazität oder müssen untersuchen, was CPU verbraucht.
Die Funktionslatenz misst die Ausführungszeit einer bestimmten Kernel- oder Userspace-Funktion:
sudo funclatency-bpfcc -p 12345 'c:malloc' 10 1
Dies traced malloc-Aufrufe in der libc des Prozesses 12345 und zeigt ein Latenz-Histogramm. Sie können jede Funktion tracen, die ein Symbol in der Binärdatei oder Shared Library hat. Für Kernel-Funktionen:
sudo funclatency-bpfcc 'vfs_read' 10 1
Für Anwendungsebene-Latenz-Tracing mit bpftrace können Sie die Zeit zwischen zwei Probe-Punkten messen:
sudo bpftrace -e '
uprobe:/usr/bin/myapp:process_request { @start[tid] = nsecs; }
uretprobe:/usr/bin/myapp:process_request /@start[tid]/ {
@latency_us = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}
END { clear(@start); }
'
Speicher-Analyse
Speicherprobleme in der Produktion reichen von graduellen Leaks, die über Tage OOM-Kills verursachen, bis zu Cache-Ineffizienzen, die die Performance degradieren. eBPF bietet mehrere Werkzeuge für jede Kategorie.
Das memleak-Werkzeug verfolgt Speicherallokations- und Freigabe-Aufrufe und trackt ausstehende Allokationen zur Leak-Identifikation:
sudo memleak-bpfcc -p 12345 --combined-only 30
Dies hängt sich an Prozess 12345 an und druckt nach 30 Sekunden Stack-Traces von Allokationen, die nicht freigegeben wurden, sortiert nach ausstehenden Bytes insgesamt. Dies ist unschätzbar wertvoll für das Aufspüren von Leaks in lang laufenden Diensten, ohne sie mit aktiviertem spezialisiertem Allokator-Debugging neu zu starten.
Für Kernel-Speicherallokations-Tracking:
sudo memleak-bpfcc --combined-only 30
Ohne pid-Flag verfolgt memleak Kernel-Allokationen über kmalloc und kfree, was Kernel-Speicherlecks identifizieren kann, die von Treibern oder Kernel-Modulen verursacht werden.
Das Cache-Verhalten hat einen enormen Einfluss auf die Anwendungsperformance. Das cachestat-Werkzeug liefert Statistiken pro Sekunde über den Page-Cache:
sudo cachestat-bpfcc 5
Die Ausgabe umfasst Hits, Misses, Dirty Pages und Lese-/Schreibverhältnisse. Ein hohes Miss-Verhältnis zeigt an, dass Ihr Working Set den verfügbaren Speicher übersteigt, und Sie sollten erwägen, ob Ihre Anwendung mehr RAM oder bessere Zugriffsmuster benötigt.
OOM-Kills können in Echtzeit getrackt werden, um zu verstehen, welche Prozesse getötet werden und warum:
sudo bpftrace -e 'kprobe:oom_kill_process {
printf("OOM kill: pid=%d comm=%s pages=%d\n",
((struct task_struct *)arg1)->pid,
((struct task_struct *)arg1)->comm,
arg0);
}'
Für einen einfacheren Ansatz erfasst das bcc oomkill-Werkzeug dies automatisch:
sudo oomkill-bpfcc
Dies druckt eine Zeile jedes Mal, wenn der OOM-Killer aufgerufen wird, einschließlich der Details des auslösenden und getöteten Prozesses.
Netzwerk-Tracing
Netzwerk-Performance-Probleme sind notorisch schwer zu diagnostizieren, weil sie Interaktionen zwischen der Anwendung, dem Kernel-TCP-Stack und der Netzwerkinfrastruktur beinhalten. eBPF bietet chirurgische Werkzeuge für jede Schicht.
Das tcplife-Werkzeug verfolgt TCP-Session-Lebensdauern und zeigt, wann Verbindungen aufgebaut und geschlossen werden, zusammen mit übertragenen Bytes:
sudo tcplife-bpfcc -D
Das -D-Flag beinhaltet Zeitstempel. Jede Zeile zeigt die PID, den Prozessnamen, lokale und Remote-Adressen, Ports, Dauer und gesendete/empfangene Bytes. Dies ist essentiell für die Identifikation von Verbindungs-Churn, unerwarteten kurzlebigen Verbindungen oder Diensten, die Verbindungen länger als erwartet offen halten.
TCP-Retransmissions sind ein kritischer Indikator für die Netzwerkgesundheit:
sudo tcpretrans-bpfcc -l
Das -l-Flag beinhaltet Tail-Loss-Probes. Jedes Retransmission-Ereignis wird mit Quell- und Zieladressen, Status und der Kernel-Funktion gedruckt, die die Retransmission ausgelöst hat. Cluster von Retransmissions zu einem bestimmten Ziel weisen auf Netzwerkpfad-Probleme hin.
Verworfene Pakete auf TCP-Ebene können mit tcpdrop getrackt werden:
sudo tcpdrop-bpfcc
Jedes verworfene Paket wird mit seinem Kernel-Stack-Trace gedruckt, der Ihnen genau sagt, warum der Kernel das Paket verworfen hat. Häufige Ursachen sind Socket-Buffer-Overflow, Verbindungs-Resets und Speicherdruck.
Für detaillierte TCP-Verbindungszustandsanalyse können Sie ein bpftrace-Skript schreiben, das Zustandsübergänge trackt:
sudo bpftrace -e '
tracepoint:tcp:tcp_set_state {
printf("pid=%d sport=%d dport=%d oldstate=%d newstate=%d\n",
pid, args->sport, args->dport, args->oldstate, args->newstate);
}
'
DNS-Auflösungslatenz ist oft eine übersehene Quelle von Anwendungslatenz. Sie können DNS-Lookups auf Resolver-Ebene tracen:
sudo bpftrace -e '
uprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo { @start[tid] = nsecs; }
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo /@start[tid]/ {
@dns_us = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}
'
I/O-Profilierung
Storage-I/O ist eine der häufigsten Quellen von Produktionslatenz, und eBPF bietet Werkzeuge, die I/O auf mehreren Ebenen des Storage-Stacks tracen.
Das biosnoop-Werkzeug verfolgt einzelne Block-I/O-Operationen mit Zeitstempeln, Latenzen und Prozesszuordnung:
sudo biosnoop-bpfcc -d sda 10
Dies trackt alle Block-I/O zum sda-Device für 10 Sekunden und zeigt die PID jeder Operation, Prozessname, Disk, Operationstyp, Sektor, Bytes und Latenz. Dies ist das bevorzugte Werkzeug, wenn Sie genau verstehen müssen, was I/O auf einer bestimmten Disk erzeugt.
Dateisystem-Level-Tracing bietet höheren Kontext. Das ext4slower-Werkzeug trackt ext4-Operationen, die einen Latenzschwellenwert überschreiten:
sudo ext4slower-bpfcc 10
Dies druckt alle ext4-Operationen, die langsamer als 10 Millisekunden sind, einschließlich Reads, Writes, Opens und Syncs. Dies identifiziert sofort langsame Dateisystem-Operationen, ohne dass Sie Block-Level-Traces mit Dateisystem-Metadaten korrelieren müssen.
Für allgemeines Dateisystem-Tracing über alle Dateisystemtypen hinweg dient fileslower dem gleichen Zweck:
sudo fileslower-bpfcc 10
Schreibmuster sind kritisch für das Verständnis, wie Anwendungen mit dem Storage interagieren. Das bpftrace-Äquivalent von filetop zeigt, welche Dateien am häufigsten gelesen und geschrieben werden:
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_write {
@writes[comm, pid] = count();
}
interval:s:5 { print(@writes); clear(@writes); }
'
Für fsync-lastige Workloads wie Datenbanken kann das Tracen von Sync-Operationen unerwartete Flush-Muster aufdecken:
sudo bpftrace -e '
kprobe:vfs_fsync_range {
@fsync_latency[comm] = count();
}
kretprobe:vfs_fsync_range {
printf("fsync completed: comm=%s\n", comm);
}
'
Erstellen von Benutzerdefinierten bpftrace-One-Linern
Die wahre Stärke von eBPF kommt von der Fähigkeit, benutzerdefinierte Tracing-Programme zu schreiben, die auf Ihren spezifischen Stack zugeschnitten sind. Die Skriptsprache von bpftrace macht dies für jeden zugänglich, der ein Shell-Skript schreiben kann.
Die Grundstruktur eines bpftrace-One-Liners ist eine Probe-Spezifikation gefolgt von einem Aktionsblock. Probes können an kprobes (Kernel-Funktionen), uprobes (Userspace-Funktionen), Tracepoints (stabile Kernel-Ereignisse) und Software-Ereignisse angehängt werden.
Syscalls pro Prozess zählen:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
Histogramm der Lesegrößen pro Prozess:
sudo bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret > 0/ {
@read_bytes[comm] = hist(args->ret);
}'
Neue Prozesserstellung mit vollständigen Kommandozeilen tracen:
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve {
printf("exec: pid=%d ppid=%d %s\n", pid, curtask->real_parent->pid, str(args->filename));
}'
Dateiöffnungen mit vollständigen Pfaden tracen:
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
printf("open: pid=%d comm=%s file=%s\n", pid, comm, str(args->filename));
}'
Die Zeit messen, die Ihre Anwendung in einer bestimmten Funktion verbringt, aggregiert nach Call-Stack:
sudo bpftrace -e '
uprobe:/opt/myapp/bin/server:DatabaseQuery { @start[tid] = nsecs; }
uretprobe:/opt/myapp/bin/server:DatabaseQuery /@start[tid]/ {
@query_ns[ustack(5)] = hist(nsecs - @start[tid]);
delete(@start[tid]);
}
'
Für hochfrequente Ereignisse verwenden Sie Maps, um im Kernel zu aggregieren und den Ausgabepuffer nicht zu überfluten:
sudo bpftrace -e '
tracepoint:syscalls:sys_exit_read /args->ret > 0/ {
@total_bytes[comm] = sum(args->ret);
@total_calls[comm] = count();
}
interval:s:10 {
printf("\n--- Top readers (10s window) ---\n");
print(@total_bytes, 10);
print(@total_calls, 10);
clear(@total_bytes);
clear(@total_calls);
}
'
Integration von Continuous Profiling
Während Ad-hoc-Profilierung mit bpftrace und bcc-tools essentiell für die Incident Response ist, bietet Continuous Profiling eine stets aktive Performance-Sichtbarkeit. Zwei Open-Source-Projekte führen in diesem Bereich: Parca und Pyroscope.
Parca verwendet eBPF, um kontinuierlich Stack-Traces über alle Prozesse auf einem Host mit minimalem Overhead zu sampeln. Der Parca-Agent läuft als DaemonSet in Kubernetes oder als systemd-Service auf Bare Metal:
sudo parca-agent --remote-store-address=parca-server:7070 \
--node=production-host-01 \
--sampling-ratio=1.0 \
--http-address=:7071
Der Agent entdeckt automatisch alle laufenden Prozesse, löst Symbole aus Debug-Informationen und BTF-Daten auf und streamt Profilierungsdaten an den Parca-Server. Der Server speichert Profile in einem spaltenorientierten Format, das für Zeitreihenabfragen optimiert ist, und bietet eine UI zum Erkunden von Flame-Graphs, Vergleichen von Profilen über Zeitfenster und Identifizieren von Regressionen.
Pyroscope verfolgt einen ähnlichen Ansatz, unterstützt aber zusätzliche Profilierungsmodi jenseits von CPU, einschließlich Speicherallokations-Profilierung, Lock-Contention-Profilierung und Goroutine-Profilierung für Go-Anwendungen:
# pyroscope-agent.yaml
server-address: http://pyroscope-server:4040
log-level: info
targets:
- service-name: api-server
spy-name: ebpfspy
application-name: api-server
- service-name: worker
spy-name: ebpfspy
application-name: worker-pool
Beide Werkzeuge integrieren sich mit Grafana für Dashboard-Erstellung und Alerting. Ein typisches Continuous-Profiling-Setup beinhaltet:
# Grafana data source configuration for Parca
curl -X POST http://grafana:3000/api/datasources \
-H "Content-Type: application/json" \
-d '{
"name": "Parca",
"type": "parca",
"url": "http://parca-server:7070",
"access": "proxy"
}'
Der wahre Wert von Continuous Profiling zeigt sich über die Zeit. Wenn eine Performance-Regression deployed wird, können Sie das aktuelle Profil mit einer Baseline von vor dem Deployment vergleichen und sofort sehen, welche Funktionen mehr CPU verbrauchen. Dies transformiert Performance-Debugging von einer reaktiven Untersuchung in ein proaktives Erkennungssystem.
Best Practices und Sicherheit in der Produktion
Die Sicherheitsgarantien von eBPF bedeuten nicht, dass Sie jedes eBPF-Programm auf jedem Produktionssystem ohne Nachdenken ausführen können. Obwohl der Verifier Kernel-Abstürze verhindert, können schlecht geschriebene eBPF-Programme dennoch übermäßig CPU verbrauchen, überwältigende Ausgabe erzeugen oder die Systemperformance beeinträchtigen.
Setzen Sie immer Zeitlimits für bpftrace und bcc-tools. Jede Profilierungssitzung sollte eine explizite Dauer haben:
# Gut: explizite 30-Sekunden-Dauer
sudo biolatency-bpfcc 30 1
# Gefährlich: läuft bis zum manuellen Stopp
sudo biolatency-bpfcc
Seien Sie vorsichtig mit hochfrequenten Probes. Das Anhängen eines kprobe an eine Funktion, die Millionen Mal pro Sekunde feuert, wird messbaren Overhead hinzufügen, selbst wenn das eBPF-Programm trivial ist. Bevor Sie einen Probe in der Produktion anhängen, schätzen Sie die Frequenz:
sudo bpftrace -e 'kprobe:vfs_read { @count = count(); } interval:s:1 { print(@count); clear(@count); }'
Wenn die Funktion mehr als ein paar Hunderttausend Mal pro Sekunde feuert, erwägen Sie, ob Sie einen Tracepoint statt eines kprobe verwenden können, einen Filter hinzufügen können, um die Anzahl der verarbeiteten Ereignisse zu reduzieren, oder sampeln statt jedes Ereignis zu tracen.
Verwenden Sie das --dry-run-Flag von bpftrace, um Skripte vor der Ausführung zu validieren:
sudo bpftrace --dry-run -e 'kprobe:vfs_read { @[comm] = count(); }'
Begrenzen Sie Map-Größen, um unbegrenztes Speicherwachstum zu verhindern:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' --map-max-entries=10000
Für Produktionssysteme etablieren Sie ein Runbook von vorab genehmigten eBPF-Werkzeugen und -Skripten. Die bcc-tools-Sammlung ist gut getestet und sicher für den Produktionseinsatz. Benutzerdefinierte bpftrace-Skripte sollten vom Team überprüft und im Staging getestet werden, bevor sie in der Produktion eingesetzt werden.
Erwägen Sie, eBPF-Werkzeuge in Containern mit den entsprechenden Capabilities auszuführen, anstatt mit vollem Root-Zugang:
docker run --rm -it --privileged \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /sys/kernel/btf:/sys/kernel/btf:ro \
-v /proc:/proc:ro \
quay.io/iovisor/bpftrace:latest \
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
Dokumentieren Sie schließlich Ihre Profilierungs-Workflows. Wenn um 3 Uhr morgens ein Incident auftritt, wollen Sie nicht bpftrace-Skripte von Grund auf schreiben. Pflegen Sie ein Repository getesteter Profilierungs-Skripte, organisiert nach Symptom: hohe CPU, hohe Latenz, Speicherwachstum, Netzwerkfehler und I/O-Sättigung. Jedes Skript sollte Kommentare enthalten, die erklären, was es misst, den erwarteten Overhead und wie die Ausgabe zu interpretieren ist. eBPF gibt Ihnen Superkräfte in der Produktion, aber nur wenn Sie deren Verwendung vor dem Notfall geübt haben.