Modernes System-Monitoring stößt an eine strukturelle Grenze: Entweder instrumentiert man Code – und damit schleichen sich Overhead, Abhängigkeiten und Deployment-Aufwand ein – oder man bleibt auf der Oberfläche und verpasst das, was im Kernel wirklich passiert. eBPF bricht diese Dichotomie auf. Die Technologie erlaubt es, Programme direkt im Linux-Kernel auszuführen, ohne ihn zu modifizieren und ohne eigenen Code in die überwachten Anwendungen einzufügen.
Was vor wenigen Jahren noch ein Nischenthema für Kernel-Entwickler war, ist 2026 eine der relevantesten Infrastrukturtechnologien für Observability-Teams. Dieser Artikel erklärt, was eBPF ist, wie es funktioniert, und welche konkreten Monitoring-Szenarien damit möglich werden.
Was ist eBPF?
eBPF steht für extended Berkeley Packet Filter. Der Name stammt aus der Vergangenheit der Technologie, als es primär um Netzwerkpaketfilterung ging. Heute ist eBPF weit mehr: ein sicheres, sandboxtes Laufzeitsystem für Programme, die im Kernel-Kontext ausgeführt werden – ohne Kernel-Patches zu benötigen und ohne den Betrieb zu gefährden.
Ein eBPF-Programm wird in einem eingeschränkten Bytecode-Format definiert, vom Kernel-internen Verifier auf Sicherheit geprüft und dann zur Laufzeit in native Maschinencode kompiliert (JIT-Kompilierung). Die Ausführung findet bei bestimmten Ereignissen statt: Systemaufrufen, Netzwerkpaketen, Kernel-Tracepoints, Scheduler-Ereignissen oder Benutzeranwendungs-Events über sogenannte Uprobes.
Warum ist eBPF für Observability relevant?
Klassische Observability-Ansätze haben bekannte Schwächen:
- Code-Instrumentation: Erfordert Änderungen am Quellcode, erhöht Overhead und bindet Teams an spezifische SDKs oder Frameworks.
- Sidecar-Container: Funktionieren gut in Kubernetes, bieten aber keine echte Kernel-Sicht.
- Logs und Metriken: Was nicht explizit geloggt wird, bleibt unsichtbar. Blinde Flecken entstehen systematisch.
eBPF hingegen:
- Greift direkt auf Kernel-Events zu – ohne Code-Änderungen in den Zielanwendungen
- Tracet TCP-Verbindungen, Systemaufrufe, Datei-I/O und Scheduling-Ereignisse mit minimalem Overhead
- Funktioniert sprachangnostisch – Java, Go, Python, Rust, C: kein Unterschied
- Ermöglicht Observability für Anwendungen, für die kein Quellcode vorliegt
Konkrete Anwendungsfälle in der Praxis
Netzwerk-Monitoring und automatische Service-Map
eBPF-basierte Tools können alle TCP- und UDP-Verbindungen eines Systems tracen, ohne Proxy oder Code-Injection. Dadurch lässt sich automatisch eine Service-Map erstellen – ein Graph aller Kommunikationsbeziehungen zwischen Diensten, in Echtzeit, ohne manuelle Konfiguration. Cilium und Hubble nutzen genau diese Methode, um Kubernetes-Netzwerke vollständig zu beobachten.
HTTP- und gRPC-Traces ohne Instrumentation
Mit Uprobes kann eBPF in laufende Prozesse eingreifen und HTTP-Anfragen, gRPC-Calls oder Datenbankabfragen tracen – ohne dass die Anwendung selbst Tracing-Code enthält. Tools wie Odigos oder Coroot setzen auf diese Methode, um OpenTelemetry-kompatible Traces automatisch zu erzeugen. Das ist besonders wertvoll für Legacy-Anwendungen, an denen keine Code-Änderungen möglich sind.
Performance-Profiling in Produktion
CPU-Flamegraphen können mit eBPF system-weit und ohne Neustart der Applikation erzeugt werden. Das ist besonders relevant für Performance-Probleme in Produktion, bei denen ein Neustart mit Profiling-Flags nicht in Frage kommt. Tools wie Parca oder Pyroscope nutzen eBPF für kontinuierliches Profiling mit sehr geringem Overhead.
Runtime-Security und Sicherheitsmonitoring
eBPF ermöglicht die Beobachtung von Systemaufrufen in Echtzeit – die Grundlage für Runtime-Security-Tools wie Falco, Tetragon oder Tracee. Ungewöhnliches Verhalten wie exec()-Aufrufe aus Webanwendungen, unerwartete Netzwerkverbindungen oder Schreibvorgänge in sensiblen Verzeichnissen können sofort erkannt und gemeldet werden. Im Gegensatz zu klassischen Host-basierten IDS-Systemen geschieht das mit minimaler Latenz und ohne schweren Agenten-Overhead.
Kubernetes-Netzwerkpolitik und Load Balancing
Cilium ersetzt iptables durch eBPF-basiertes Netzwerk-Routing direkt im Kernel. Das senkt Latenz, verbessert Durchsatz und ermöglicht granularere Netzwerkpolitiken – ohne den User-Space-Umweg von iptables.
Wichtige eBPF-Tools im Überblick
- bcc (BPF Compiler Collection): Bibliothek und Tool-Sammlung für eBPF-Entwicklung; enthält Dutzende fertige Monitoring-Skripte für den sofortigen Einsatz
- bpftrace: Hochsprachen-ähnliche Tracing-Sprache für eBPF; ideal für schnelle Ad-hoc-Analysen ohne eigenes Programm schreiben zu müssen
- Cilium / Hubble: Kubernetes-Netzwerk und Observability auf eBPF-Basis; inzwischen CNCF Graduated Project
- Falco: Runtime-Security mit eBPF-Backend; CNCF-Projekt mit breiter Industrie-Unterstützung
- Tetragon: Sicherheits-Observability mit Policy-Enforcement direkt im Kernel; von Isovalent entwickelt
- Odigos / Coroot: Automatische OpenTelemetry-Instrumentation ohne Code-Änderungen auf eBPF-Basis
- Parca / Pyroscope: Kontinuierliches CPU-Profiling mit eBPF und sehr geringem Overhead
Voraussetzungen und Grenzen
eBPF erfordert einen aktuellen Linux-Kernel. Viele fortgeschrittene Features sind ab Kernel 5.8 verfügbar; für vollständige CO-RE-Unterstützung (Compile Once – Run Everywhere) wird Kernel 5.15 empfohlen. Die meisten modernen Distributionen – Debian 12, Ubuntu 22.04+, RHEL 9 – erfüllen diese Anforderungen.
Grenzen der Technologie:
- eBPF-Programme benötigen erhöhte Privilegien (CAP_BPF oder root) – in sicherheitskritischen Umgebungen ist das ein Diskussionspunkt
- Die Entwicklung eigener eBPF-Programme ist komplex; fertige Tools wie bpftrace erleichtern den Einstieg erheblich
- In stark eingeschränkten Container-Umgebungen wie gVisor ist eBPF nicht verfügbar
- Windows-Unterstützung über das eBPF for Windows-Projekt ist noch experimentell
eBPF und klassisches Monitoring: Kein Entweder-oder
eBPF ersetzt klassische Observability nicht, sondern ergänzt sie. Logs, Metriken und klassische APM-Traces behalten ihre volle Berechtigung. eBPF schließt die Lücken, die andere Methoden offen lassen: unbekannte Dienste, nicht instrumentierter Legacy-Code, netzwerkseitige Blindflecken und Kernel-Level-Events.
Ein pragmatischer Einstieg: Falco für Runtime-Security und bpftrace für Ad-hoc-Analysen installieren. Beides ist schnell aufgesetzt und liefert sofortigen Mehrwert ohne tiefes eBPF-Wissen.
Fazit
eBPF ist eine der wichtigsten Technologien für Observability in 2026. Wer heute Monitoring-Strategien plant, sollte eBPF nicht als Expertenthema abtun, sondern als praktisches Werkzeug in den Werkzeugkasten aufnehmen: für tiefes System-Monitoring, Netzwerk-Observability, Performance-Profiling und Runtime-Security – ohne Code zu ändern, ohne Agents neu zu deployen, mit minimalem Overhead und maximaler Sichtbarkeit.
Bild: luis gomes via Pexels (pexels.com)
Quellen: eBPF.io – The eBPF Foundation; Cilium Project Documentation; Linux Kernel Documentation (kernel.org); CNCF Falco Project; Brendan Gregg – Systems Performance, 2nd Edition; Isovalent eBPF Blog.
