eBPF (Extended Berkeley Packet Filter) ist eine Technologie im Linux-Kernel, die kleine, isolierte Programme als Reaktion auf Ereignisse wie Systemaufrufe, Funktionsaufrufe, Netzwerkpakete oder Timer ausführt. Der Kernel prüft jedes Programm vor der Ausführung auf Sicherheit. So entstehen tiefe Einblicke in Netzwerk, Security und Observability ohne Kernel-Module oder Änderungen am Anwendungscode.
Was eBPF ist
Mit eBPF lässt sich der Linux-Kernel zur Laufzeit erweitern, ohne Kernel-Module zu schreiben oder den Kernel neu zu bauen. Die Wurzeln liegen im ursprünglichen Berkeley Packet Filter, der Anfang der 1990er-Jahre entstand, um Netzwerkpakete für Tools wie tcpdump effizient zu filtern. Ab etwa 2014 erhielt der Linux-Kernel eine erweiterte Version mit leistungsfähigerem Befehlssatz, Datenstrukturen und vielen neuen Einhängepunkten. Heute steht der Name eBPF für die gesamte Technologie, weit über Paketfilterung hinaus.
Für Observability ist eBPF attraktiv, weil es sieht, was der Kernel sieht: jeden Systemaufruf, jede TCP-Verbindung, jeden geplanten Prozess und mit User-Space-Probes sogar Funktionsaufrufe innerhalb von Anwendungen. Das geschieht von außerhalb der Anwendung, Daten lassen sich also erfassen, ohne Code zu ändern oder neu zu starten.
Wie eBPF funktioniert
- Schreiben und kompilieren. eBPF-Programme werden meist in eingeschränktem C geschrieben oder von höheren Tools erzeugt und mit LLVM/Clang zu eBPF-Bytecode kompiliert.
- Verifizieren. Beim Laden prüft der Verifier im Kernel, dass das Programm terminiert, nur auf erlaubten Speicher zugreift und den Kernel nicht zum Absturz bringen kann. Programme, die die Prüfung nicht bestehen, werden abgewiesen.
- JIT-kompilieren und einhängen. Der Bytecode wird just in time in nativen Maschinencode übersetzt und an einen Hook gebunden.
- Daten über Maps teilen. eBPF-Maps (Hash-Tabellen, Arrays, Ring Buffer und mehr) speichern Zustand und übergeben Daten an den User Space, wo ein Agent sie aggregiert und exportiert.
Typische Hooks sind kprobes und fentry für Kernel-Funktionen, uprobes für User-Space-Funktionen, Tracepoints, Perf Events für Sampling sowie Netzwerk-Hooks wie XDP und Traffic Control (tc). BTF-Typinformationen und CO-RE („Compile Once, Run Everywhere“) erlauben es, ein kompiliertes Programm auf unterschiedlichen Kernel-Versionen auszuführen.
Warum eBPF für Observability wichtig ist
Bisherige Ansätze für tiefe Einblicke hatten unbequeme Zielkonflikte. Kernel-Module sind mächtig, aber riskant, denn ein Fehler kann den Host zum Absturz bringen. Sprach-Agents und SDKs liefern reichen Kontext, müssen aber in jeden Service und jede Sprache eingebaut und aktuell gehalten werden. eBPF eröffnet einen dritten Weg: sicherer, programmierbarer Zugriff auf Kernel-Ereignisse mit einem Agent pro Host. Besonders wertvoll ist das in Kubernetes-Clustern mit vielen Teams und Sprachen. Dort liefert eBPF eine einheitliche Grundlage aus Netzwerk-, Prozess- und Performance-Daten für jeden Workload, auch für Software von Drittanbietern, die Sie selbst nicht instrumentieren können.
Anwendungsfälle in der Observability
| Anwendungsfall | Was eBPF liefert |
|---|---|
| Netzwerk-Monitoring | TCP-Verbindungen, Retransmits, DNS-Latenz und Traffic-Flüsse zwischen Pods und Hosts |
| Continuous Profiling | Gesampelte Stacktraces aus Perf Events über alle Prozesse mit geringem Overhead |
| Automatische Instrumentierung | Request-Metriken und Spans für HTTP und gRPC aus Kernel- und Bibliotheks-Probes |
| Security | Prozessstarts, Dateizugriffe und Netzwerkaktivität zur Erkennung von Laufzeitbedrohungen |
| Performance-Analyse | Scheduler-Latenz, Disk-I/O-Latenz und Histogramme von Systemaufrufen |
Bekannte Open-Source-Projekte sind bpftrace und BCC für Ad-hoc-Tracing, Cilium für Networking, Falco für Runtime Security und Parca für Profiling. Auch das OpenTelemetry-Projekt pflegt eBPF-basierte Komponenten für Netzwerk-Telemetrie und Zero-Code-Instrumentierung.
Beispiel: ein Einzeiler
Mit bpftrace zählen Sie zehn Sekunden lang die Systemaufrufe pro Prozess auf einem Host, ohne eine Anwendung anzufassen:
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); } interval:s:10 { exit(); }'Produktive Agents nutzen dieselben Mechanismen, allerdings mit vorkompilierten Programmen, sorgfältigem Sampling und Aggregation in Kernel-Maps, sodass nur Zusammenfassungen in den User Space gelangen.
Grenzen und Zielkonflikte
- Linux-zentriert. eBPF ist ein Feature des Linux-Kernels. Es gibt ein Projekt eBPF for Windows, dessen Ökosystem aber deutlich weniger ausgereift ist, und verwaltete Serverless-Plattformen erlauben meist kein Laden von eBPF-Programmen.
- Kernel-Version zählt. Viele Funktionen setzen aktuelle Kernel voraus, BTF und CO-RE funktionieren am besten ab der 5.x-Reihe.
- Berechtigungen. Zum Laden sind erweiterte Capabilities wie
CAP_BPFundCAP_PERFMONnötig, auf älteren KernelnCAP_SYS_ADMIN. Agents laufen daher privilegiert. - Weniger Anwendungskontext. eBPF sieht Bytes und Funktionsaufrufe, keine fachliche Bedeutung. Verschlüsselter Traffic erfordert Probes an TLS-Bibliotheken, und vollständige Context Propagation über Services hinweg ist schwieriger als mit SDK-basierter Instrumentierung.
Best Practices
Betrachten Sie eBPF als Ergänzung zu OpenTelemetry-SDKs, nicht als Ersatz. Nutzen Sie es für breite Abdeckung ohne Codeänderung bei Infrastruktur-, Netzwerk- und Profiling-Daten, und ergänzen Sie SDK-Instrumentierung dort, wo Sie fachliche Attribute und präzise Spans brauchen. Legen Sie die unterstützten Kernel-Versionen fest und testen Sie sie, prüfen Sie die Berechtigungen der Agents und messen Sie den Overhead an repräsentativen Workloads, bevor Sie flächendeckend ausrollen.
Wie Obseria unterstützt
Obseria verarbeitet OpenTelemetry-Daten nativ. Telemetrie aus eBPF-basierten OpenTelemetry-Komponenten landet daher direkt neben SDK-Traces, Logs und Metriken. Netzwerk-Monitoring, Continuous Profiling mit unter 1 % Overhead und Kubernetes Monitoring in Obseria setzen diese Low-Level-Daten in den Kontext der betroffenen Services.