Dekodierung der eBPF-Beobachtbarkeit:

In den letzten zwei Jahren wurde in Cloud-nativen Communities viel über eBPF geredet. eBPF war eine tragende Säule auf der KubeCon, eBPF-Tage und eBPF-Gipfeltreffen erfreuen sich immer größerer Beliebtheit, Unternehmen wie Google und Netflix nutzen eBPF seit Jahren und es entstehen ständig neue Anwendungsfälle. Insbesondere im Bereich der Beobachtbarkeit wird erwartet, dass eBPF bahnbrechend sein wird.

Schauen wir uns also eBPF an – was ist die Technologie, wie wirkt sie sich auf die Beobachtbarkeit aus, wie schneidet sie im Vergleich zu bestehenden Beobachtbarkeitspraktiken ab und was könnte die Zukunft bringen?

Was ist eBPF wirklich?

eBPF ist ein Programmierframework, das es uns ermöglicht, Sandbox-Programme sicher im Linux-Kernel auszuführen, ohne den Kernel-Code zu ändern.

Es wurde ursprünglich für Linux entwickelt (und dort ist die Technologie auch heute noch am ausgereiftesten), aber Microsoft entwickelt die eBPF-Implementierung für Windows rasant weiter.

eBPF-Programme sind von Natur aus äußerst effizient und sicher – sie werden vom Kernel überprüft, um sicherzustellen, dass sie die Stabilität oder Sicherheit des Betriebssystems nicht gefährden.

Warum ist eBPF also eine große Sache?

Um dies zu verstehen, müssen wir den Benutzerraum und den Kernelraum verstehen.

Im Benutzerbereich werden alle Anwendungen ausgeführt. Der Kernel-Space liegt zwischen dem User-Space und der physischen Hardware. Anwendungen im Benutzerbereich können nicht direkt auf Hardware zugreifen. Stattdessen führen sie Systemaufrufe an den Kernel durch, der dann auf die Hardware zugreift.

Der gesamte Speicherzugriff, das Lesen/Schreiben von Dateien und der Netzwerkverkehr laufen über den Kernel. Der Kernel verwaltet auch gleichzeitige Prozesse.

Grundsätzlich läuft alles über den Kernel (siehe Abbildung unten).

Und eBPF bietet eine sichere Möglichkeit, die Kernel-Funktionalität zu erweitern.

Historisch gesehen war es aus offensichtlichen Gründen sehr schwierig, irgendetwas im Kernel-Quellcode oder auf der Betriebssystemebene zu ändern.

Der Linux-Kernel verfügt über 30 Millionen Codezeilen und es dauert mehrere Jahre, bis eine Änderung von der Idee zur breiten Verfügbarkeit gelangt. Zunächst muss die Linux-Community dem zustimmen. Dann muss es Teil der offiziellen Linux-Version werden. Dann, nach ein paar Monaten, wird es von Distributionen wie Red Hat und Ubuntu aufgegriffen, die es einem breiteren Publikum zugänglich machen.

Technisch gesehen könnte man Kernel-Module in den eigenen Kernel laden und direkt Änderungen vornehmen, aber das birgt ein sehr hohes Risiko und erfordert eine komplexe Programmierung auf Kernel-Ebene und wird daher fast überall vermieden.

eBPF löst dieses Problem und bietet einen sicheren und effizienten Mechanismus zum Anhängen und Ausführen von Programmen im Kernel.

Schauen wir uns an, wie eBPF sowohl Sicherheit als auch Leistung gewährleistet.

Hochsicher

• Strenge Überprüfung – Bevor ein eBPF-Programm in einen Kernel geladen werden kann, wird es durch den eBPF-Verifizierer überprüft, der sicherstellt, dass der Code absolut sicher ist – z. B. keine harten Schleifen, ungültigen Speicherzugriff, unsichere Vorgänge.

  
  

• Sandboxed – eBPF-Programme werden in einer speicherisolierten Sandbox innerhalb des Kernels ausgeführt, getrennt von anderen Kernelkomponenten. Dies verhindert unbefugten Zugriff auf den Kernel-Speicher, die Datenstrukturen und den Kernel-Quellcode.

  
  

• Begrenzte Operationen – eBPF-Programme müssen normalerweise in einer kleinen Teilmenge der C-Sprache geschrieben werden – einem eingeschränkten Befehlssatz. Dies schränkt die Vorgänge ein, die eBPF-Programme ausführen können, und verringert so das Risiko von Sicherheitslücken.

Leistungsstark / leicht

• Als nativen Maschinencode ausführen – eBPF-Programme werden als native Maschinenanweisungen auf der CPU ausgeführt. Dies führt zu einer schnelleren Ausführung und einer besseren Leistung.

  
  

• Keine Kontextwechsel – Eine reguläre Anwendung wechselt regelmäßig zwischen User-Space und Kernel-Space, was ressourcenintensiv ist. eBPF-Programme können, da sie in der Kernel-Schicht ausgeführt werden, direkt auf Kernel-Datenstrukturen und -Ressourcen zugreifen.

  
  

• Ereignisgesteuert – eBPF-Programme werden normalerweise nur als Reaktion auf bestimmte Kernel-Ereignisse ausgeführt und sind nicht ständig aktiv. Dadurch wird der Overhead minimiert.

  
  

• Optimiert für Hardware – eBPF-Programme werden vom JIT-Compiler (Just-In-Time) des Kernels unmittelbar vor der Ausführung in Maschinencode kompiliert, sodass der Code für die spezifische Hardware optimiert ist, auf der er ausgeführt wird.

  
  

Daher bietet eBPF einen sicheren und effizienten Einstieg in den Kernel für die Programmierung. Und da alles über den Kernel läuft, eröffnet dies mehrere neue Möglichkeiten, die bisher nicht möglich waren.

Warum ist das erst jetzt eine große Sache?

Die Technologie rund um eBPF hat sich über einen langen Zeitraum hinweg weiterentwickelt und ist seit etwa 30 Jahren in der Entwicklung.

In den letzten 7 bis 8 Jahren wurde eBPF in großem Umfang von mehreren großen Unternehmen eingesetzt, und jetzt treten wir in eine Ära ein, in der der Einsatz von eBPF zum Mainstream wird. Sehen Sie sich dieses Video von Alexei Starovoitov , dem Mitschöpfer von Linux und Mitbetreuer von eBPF, über die Entwicklung von eBPF an.

eBPF – eine kurze Geschichte

• 1993 – In einem Artikel des Lawrence Berkeley National Lab wird die Verwendung eines Kernel-Agenten zur Paketfilterung untersucht. Daher kommt auch der Name BPF („Berkeley Packet Filter“).

• 1997 – BPF wird offiziell als Teil des Linux-Kernels eingeführt (Version 2.1.75).

• 1997–2014 – Mehrere Funktionen werden hinzugefügt, um die BPF-Funktionen zu verbessern, zu stabilisieren und zu erweitern.

• 2014 – Ein bedeutendes Update namens „Extended Berkeley Packet Filter“ (eBPF) wird eingeführt. Diese Version nimmt große Änderungen an der BPF-Technologie vor und macht sie breiter einsetzbar – daher das Wort „erweitert“.

  
  

Der Grund für die große Größe dieser Version war, dass sie die Erweiterung der Kernel-Funktionalität vereinfachte .

Ein Programmierer könnte mehr oder weniger wie eine normale Anwendung programmieren – und die umgebende eBPF-Infrastruktur kümmert sich um die Überprüfung, Sicherheit und Effizienz auf niedriger Ebene.

Ein komplettes unterstützendes Ökosystem und ein Gerüst rund um eBPF machen dies möglich (siehe Abbildung unten).

Quelle: https://ebpf.io/what-is-ebpf/

Noch besser: eBPF-Programme konnten ohne Neustarts aus dem Kernel geladen und entladen werden.

All dies ermöglichte plötzlich eine weitverbreitete Übernahme und Anwendung.

Weit verbreitete Übernahme in Produktionssystemen

Die Beliebtheit von eBPF ist in den letzten 7 bis 8 Jahren explosionsartig gestiegen, da mehrere große Unternehmen es in Massenproduktionssystemen einsetzen.

• Bis 2016 nutzte Netflix eBPF in großem Umfang zur Nachverfolgung. Brendan Gregg , der es implementiert hat, wurde in Infrastruktur- und Betriebskreisen weithin als Experte für eBPF bekannt.

• 2017 – Facebook stellt Katran , seinen eBPF-basierten Load Balancer, als Open-Source-Lösung zur Verfügung. Jedes einzelne Paket an Facebook.com seit 2017 hat eBPF durchlaufen.

• 2020 – Google hat eBPF zu einem Teil seines Kubernetes-Angebots gemacht. eBPF unterstützt jetzt die Netzwerk-, Sicherheits- und Observability-Ebene von GKE. Mittlerweile gibt es auch eine breite Unternehmensakzeptanz bei Unternehmen wie Capital One und Adobe .

• 2021 – Facebook, Google, Netflix, Microsoft und Isovalent haben sich zusammengeschlossen, um die eBPF-Stiftung anzukündigen, um das Wachstum der eBPF-Technologie zu verwalten.

  
  

Mittlerweile nutzen Tausende von Unternehmen eBPF und jedes Jahr entstehen Hunderte von eBPF-Projekten, die verschiedene Anwendungsfälle untersuchen.

eBPF ist jetzt ein separates Subsystem innerhalb des Linux-Kernels und wird von einer breiten Community unterstützt. Die Technologie selbst wurde durch mehrere Neuzugänge erheblich erweitert.

Was können wir also mit eBPF machen?

Die häufigsten Anwendungsfälle für eBPF liegen in drei Bereichen:

1. Vernetzung
2. Sicherheit
3. Beobachtbarkeit

Sicherheit und Netzwerke haben eine breitere Akzeptanz und Anwendung erfahren, vorangetrieben durch Projekte wie Cilum . Im Vergleich dazu befinden sich eBPF-basierte Observability-Angebote in einem frühen Entwicklungsstadium und stehen gerade erst am Anfang.

Schauen wir uns zunächst die Anwendungsfälle in den Bereichen Sicherheit und Netzwerk an.

Sicherheit

Sicherheit ist ein sehr beliebter Anwendungsfall für eBPF. Mit eBPF können Programme alles beobachten, was auf Kernel-Ebene passiert, Ereignisse mit hoher Geschwindigkeit verarbeiten, um auf unerwartetes Verhalten zu prüfen, und Warnungen viel schneller auslösen als sonst.

Zum Beispiel -

• Google verwendet eBPF zur Erkennung von Eindringlingen in großem Maßstab

• Shopify verwendet eBPF, um Containersicherheit zu implementieren

  
  

Mehrere Sicherheitsangebote von Drittanbietern verwenden mittlerweile eBPF zur Datenerfassung und -überwachung.

Vernetzung

Vernetzung ist ein weiterer weit verbreiteter Anwendungsfall. Die Lage auf der eBPF-Ebene ermöglicht eine umfassende Beobachtbarkeit des Netzwerks, z. B. Einblick in den gesamten Netzwerkpfad einschließlich aller Hops sowie der Quell- und Ziel-IP. Mit eBPF-Programmen kann man umfangreiche Netzwerkereignisse verarbeiten und Netzwerkpakete direkt im Kernel mit sehr geringem Overhead manipulieren.

Dies ermöglicht verschiedene Netzwerkanwendungsfälle wie Lastausgleich, DDoS-Prävention, Traffic Shaping und Quality of Service (QoS).

• Cloudflare nutzt eBPF, um DDoS-Angriffe zu erkennen und zu verhindern, und verarbeitet 10 Millionen Pakete pro Sekunde , ohne die Netzwerkleistung zu beeinträchtigen.
• Metas eBPF-basierter Katran übernimmt den Lastausgleich für ganz Facebook

Beobachtbarkeit

Jetzt muss klar sein, wie eBPF für die Observability nützlich sein kann.

Alles läuft durch den Kernel. Und eBPF bietet eine hochleistungsfähige und sichere Möglichkeit, alles vom Kernel aus zu beobachten.

Lassen Sie uns tiefer in die Beobachtbarkeit eintauchen und die Auswirkungen dieser Technologie betrachten.

Wie genau wirkt sich eBPF auf die Beobachtbarkeit aus?

Um dies zu untersuchen, verlassen wir das eBPF-Universum und betreten das Observability-Universum und schauen uns an, was unsere Standard-Observability-Lösung ausmacht.

Jede Observability-Lösung besteht aus vier Hauptkomponenten:

1. Datenerfassung – Abrufen von Telemetriedaten aus Anwendungen und Infrastruktur

2. Datenverarbeitung – Filtern, Indizieren und Durchführen von Berechnungen für die gesammelten Daten

3. Datenspeicherung – Kurz- und Langzeitspeicherung von Daten

4. Benutzererfahrungsschicht – Bestimmen, wie Daten vom Benutzer verbraucht werden

   
   

Davon hat eBPF (Stand heute) eigentlich nur die Datenerfassungsschicht betroffen – das einfache Sammeln von Telemetriedaten direkt vom Kernel mithilfe von eBPF.

Wenn wir heute von „eBPF-Beobachtbarkeit“ sprechen, meinen wir also die Verwendung von eBPF als Instrumentierungsmechanismus zum Sammeln von Telemetriedaten, anstatt andere Instrumentierungsmethoden zu verwenden. Andere Komponenten einer Observability-Lösung bleiben davon unberührt.

Wie eBPF Observability funktioniert

Um die zugrunde liegenden Mechanismen der eBPF-Beobachtbarkeit vollständig zu verstehen, müssen wir das Konzept der Hooks verstehen.

Wie wir bereits gesehen haben, sind eBPF-Programme in erster Linie ereignisgesteuert – das heißt, sie werden immer dann ausgelöst, wenn ein bestimmtes Ereignis eintritt. Beispielsweise kann jedes Mal, wenn ein Funktionsaufruf erfolgt, ein eBPF-Programm aufgerufen werden, um einige Daten für Beobachtbarkeitszwecke zu erfassen.

Erstens können sich diese Hooks im Kernel-Space oder im User-Space befinden. Daher kann eBPF zur Überwachung sowohl von User-Space-Anwendungen als auch von Ereignissen auf Kernel-Ebene verwendet werden.

Zweitens können diese Hooks entweder vorab festgelegt/statisch sein oder dynamisch in ein laufendes System eingefügt werden (ohne Neustarts!)

Vier unterschiedliche eBPF-Mechanismen ermöglichen dies jeweils (siehe Abbildung unten).

Statisches und dynamisches eBPF bindet sich in den User-Space und den Kernel-Space ein

1. Kernel-Tracepoints – werden zum Einbinden in von Kernel-Entwicklern vordefinierte Ereignisse verwendet (mit TRACE_EVENT-Makros)

2. USDT – wird zum Einbinden in vordefinierte Tracepoints verwendet, die von Entwicklern im Anwendungscode festgelegt wurden

3. Kprobes (Kernel Probes) – werden zur dynamischen Einbindung in beliebige Teile des Kernel-Codes zur Laufzeit verwendet

4. Uprobes (User Probes) – werden zur dynamischen Einbindung in jeden Teil einer User-Space-Anwendung zur Laufzeit verwendet

   
   

Es gibt mehrere vordefinierte Hooks im Kernel-Bereich, an die man problemlos ein eBPF-Programm anhängen kann (z. B. Systemaufrufe, Funktionseintritt/-ausgang, Netzwerkereignisse, Kernel-Tracepoints). Ebenso stellen im Benutzerbereich viele Sprachlaufzeiten, Datenbanksysteme und Software-Stacks vordefinierte Hooks für Linux-BCC-Tools bereit, in die sich eBPF-Programme einklinken können.

Aber was noch interessanter ist, sind kprobes und uprobes. Was passiert, wenn in der Produktion etwas kaputt geht und ich nicht über ausreichende Informationen verfüge und Instrumentierung zur Laufzeit dynamisch hinzufügen möchte? Hier ermöglichen kprobes und uprobes eine leistungsstarke Beobachtbarkeit.

Mithilfe von Uprobes kann man sich beispielsweise zur Laufzeit in eine bestimmte Funktion innerhalb einer Anwendung einklinken, ohne den Code der Anwendung zu ändern. Immer wenn die Funktion ausgeführt wird, kann ein eBPF-Programm ausgelöst werden, um die erforderlichen Daten zu erfassen. Dies ermöglicht spannende Möglichkeiten wie Live- Debugging.

Nachdem wir nun wissen, wie Beobachtbarkeit mit eBPF funktioniert, schauen wir uns Anwendungsfälle an.

Anwendungsfälle für eBPF-Beobachtbarkeit

eBPF kann für nahezu alle gängigen Observability-Anwendungsfälle eingesetzt werden und eröffnet darüber hinaus neue Möglichkeiten.

1. System- und Infrastrukturüberwachung: eBPF ermöglicht eine umfassende Überwachung von Ereignissen auf Systemebene wie CPU-Auslastung, Speicherzuweisung, Festplatten-E/A und Netzwerkverkehr. LinkedIn verwendet beispielsweise eBPF für die gesamte Infrastrukturüberwachung .

   
   

2. Container- und Kubernetes-Überwachung: Einblick in Kubernetes-spezifische Metriken, Ressourcennutzung und Zustand einzelner Container und Pods.

   
   

3. Application Performance Monitoring (APM): Detaillierte Beobachtbarkeit von User-Space-Anwendungen und Einblick in Anwendungsdurchsatz, Fehlerraten, Latenz und Traces.

   
   

4. Benutzerdefinierte Beobachtbarkeit: Einblick in benutzerdefinierte Metriken, die für Anwendungen oder Infrastruktur spezifisch sind und ohne das Schreiben von benutzerdefiniertem Code möglicherweise nicht einfach verfügbar sind.

   
   

5. Erweiterte Observability: eBPF kann für erweiterte Observability-Anwendungsfälle wie Live-Debugging , Anwendungsprofilierung mit geringem Overhead und Systemaufrufverfolgung verwendet werden.

   
   

Täglich entstehen neue Anwendungen von eBPF im Bereich Observability.

Was bedeutet das für die heutige Beobachtbarkeit? Wird eBPF wahrscheinlich bestehende Formen der Instrumentierung ersetzen? Vergleichen wir mit bestehenden Optionen.

eBPF im Vergleich zu bestehenden Instrumentierungsmethoden

Heutzutage gibt es neben eBPF vor allem zwei Möglichkeiten, Anwendungen und Infrastruktur für Observability zu instrumentieren.

1. Agentenbasierte Instrumentierung: Unabhängige Software-SDKs/-Bibliotheken, die in Anwendungscode oder Infrastrukturknoten integriert sind, um Telemetriedaten zu sammeln.

1. Sidecar-Proxy-basierte Instrumentierung : Sidecars sind leichte, unabhängige Prozesse, die neben einer Anwendung oder einem Dienst ausgeführt werden. Sie sind in Microservices und Container-basierten Architekturen wie Kubernetes beliebt.

   
   

Einen detaillierten Vergleich der eBPF-basierten Instrumentierung im Vergleich zu Agenten und Sidecars finden Sie hier . Nachfolgend finden Sie eine zusammenfassende Ansicht:

Wie wir sehen können, übertrifft eBPF bestehende Instrumentierungsmethoden in nahezu allen Parametern. Es gibt mehrere Vorteile –

1. Kann alles auf einmal abdecken (Infrastruktur, Anwendungen)

2. Weniger aufdringlich – eBPF ist nicht in laufende Arbeitslasten integriert, wie Code-Agenten, die jedes Mal ausgeführt werden, wenn die Arbeitslast ausgeführt wird. Die Datenerfassung erfolgt Out-of-Band und Sandboxing, sodass es keine Auswirkungen auf ein laufendes System gibt.

3. Geringer Leistungsaufwand – eBPF wird als nativer Maschinencode ausgeführt und es findet kein Kontextwechsel statt.

4. Sicherer – aufgrund integrierter Sicherheitsmaßnahmen wie der Verifizierung.

5. Einfach zu installieren – kann ohne Code-Änderung oder Neustart eingesetzt werden.

6. Einfache Wartung und Aktualisierung – auch hier keine Codeänderung und Neustarts.

7. Besser skalierbar – dank einfacher Implementierung und Wartung sowie geringem Leistungsaufwand

   
   

Was die Nachteile betrifft, besteht die größte Lücke bei der heutigen eBPF-Beobachtbarkeit in der verteilten Ablaufverfolgung ( durchführbar , aber der Anwendungsfall befindet sich noch in einem frühen Stadium).

Insgesamt können wir angesichts der erheblichen Vorteile, die eBPF gegenüber bestehenden Instrumentierungsmethoden bietet, vernünftigerweise davon ausgehen, dass eBPF zur Standard-Instrumentierungsplattform der nächsten Generation werden wird.

Implikationen für die Beobachtbarkeit

Was bedeutet das für die Observability-Branche? Was ändert sich?

Stellen Sie sich eine Observability-Lösung vor:

• dass Sie in 5 Minuten in den Kernel einsteigen können

• Keine Codeänderung oder Neustarts

• deckt alles auf einmal ab – Infrastruktur, Anwendungen, alles

• hat einen Overhead von nahezu Null

• ist sehr sicher

  
  

Genau das macht eBPF möglich. Und das ist der Grund, warum die Technologie so viel Aufregung hervorruft.

Wir können davon ausgehen, dass die nächste Generation von Observability-Lösungen alle mit eBPF statt mit Code-Agenten ausgestattet sein wird.

Traditionelle Akteure wie Datadog und NewRelic investieren bereits in den Aufbau einer eBPF-basierten Instrumentierung, um ihr codebasiertes Agentenportfolio zu erweitern. Mittlerweile gibt es mehrere Anbieter der nächsten Generation, die auf eBPF basieren und sowohl Nischenanwendungsfälle als auch komplexe Observability-Lösungen lösen.

Während herkömmliche Anbieter über mehrere Jahre hinweg einzelne Code-Agenten Sprache für Sprache und für jede Infrastrukturkomponente erstellen mussten, können neue Anbieter mit eBPF in wenigen Monaten den gleichen Abdeckungsgrad erreichen. Dadurch können sie sich auch auf Innovationen weiter oben in der Wertschöpfungskette konzentrieren, wie z. B. Datenverarbeitung, Benutzererfahrung und sogar KI . Darüber hinaus sind ihre Datenverarbeitungs- und Benutzererfahrungsebenen ebenfalls von Grund auf aufgebaut, um die neuen Anwendungsfälle, Volumina und Häufigkeiten zu unterstützen.

All dies dürfte eine große Menge an Innovationen in diesem Bereich vorantreiben und Observability in den kommenden Jahren nahtloser, sicherer und einfacher umsetzbar machen.

Wer sollte eBPF-Observability nutzen?

Erstens: Wenn Sie sich in einer modernen Cloud-nativen Umgebung (Kubernetes, Microservices) befinden, sind die Unterschiede zwischen eBPF-basierten und agentenbasierten Ansätzen am deutlichsten sichtbar (Leistungsaufwand, Sicherheit, einfache Installation usw.).

Zweitens: Wenn Sie in großem Maßstab tätig sind, werden eBPF-basierte, leichtgewichtige Agenten zu dramatischen Verbesserungen gegenüber dem Status Quo führen. Dies ist wahrscheinlich einer der Gründe, warum die eBPF-Akzeptanz bei Technologieunternehmen mit großer Präsenz wie LinkedIn, Netflix und Meta am höchsten ist.

Drittens, wenn Ihnen die Technik fehlt. Kapazität haben und nach einer Observability-Lösung suchen, deren Installation und Wartung nahezu keinen Aufwand erfordert, dann entscheiden Sie sich direkt für eine eBPF-basierte Lösung.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass eBPF durch die Bereitstellung eines deutlich besseren Instrumentierungsmechanismus das Potenzial hat, unseren Ansatz zur Beobachtbarkeit in den kommenden Jahren grundlegend zu verändern.

Während wir in diesem Artikel hauptsächlich die Anwendung von eBPF in der Datenerfassung/-instrumentierung untersucht haben, könnte eBPF in zukünftigen Anwendungen in Datenverarbeitungs- oder sogar Datenspeicherungsebenen zum Einsatz kommen. Die Möglichkeiten sind vielfältig und noch unerforscht.

Verweise

1. https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html
2. https://ebpf.io/
3. https://ebpf.io/summit-2022.html
4. https://github.com/microsoft/ebpf-for-windows
5. https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf

Auch hier veröffentlicht.