Dekodierung der eBPF-Beobachtbarkeit: In den letzten zwei Jahren wurde in Cloud-nativen Communities viel über eBPF geredet. eBPF war eine auf der KubeCon, und erfreuen sich immer größerer Beliebtheit, Unternehmen wie Google und Netflix seit Jahren und es entstehen ständig neue Anwendungsfälle. Insbesondere im Bereich der Beobachtbarkeit wird erwartet, dass eBPF bahnbrechend sein wird. tragende Säule eBPF-Tage eBPF-Gipfeltreffen nutzen eBPF 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? https://www.youtube.com/watch?v=KhPrMW5Rbbc&embedable=true 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 rasant weiter. eBPF-Implementierung für Windows 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 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. 30 Millionen Codezeilen könnte man Kernel-Module in den eigenen Kernel laden und direkt Änderungen vornehmen, aber das birgt hohes Risiko und erfordert eine komplexe Programmierung auf Kernel-Ebene und wird daher fast überall vermieden. Technisch gesehen ein sehr eBPF löst dieses Problem und bietet einen Mechanismus zum Anhängen und Ausführen von Programmen im Kernel. sicheren und effizienten Schauen wir uns an, wie eBPF sowohl Sicherheit als auch Leistung gewährleistet. Hochsicher – Bevor ein eBPF-Programm in einen Kernel geladen werden kann, wird es durch den überprüft, der sicherstellt, dass der Code absolut sicher ist – z. B. keine harten Schleifen, ungültigen Speicherzugriff, unsichere Vorgänge. Strenge Überprüfung eBPF-Verifizierer – 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. Sandboxed – 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. Begrenzte Operationen Leistungsstark / leicht – eBPF-Programme werden als native Maschinenanweisungen auf der CPU ausgeführt. Dies führt zu einer schnelleren Ausführung und einer besseren Leistung. Als nativen Maschinencode ausführen – 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. Keine Kontextwechsel – eBPF-Programme werden normalerweise nur als Reaktion auf bestimmte Kernel-Ereignisse ausgeführt und sind nicht ständig aktiv. Dadurch wird der Overhead minimiert. Ereignisgesteuert – 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. Optimiert für Hardware 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 eine große Sache? jetzt 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 , dem Mitschöpfer von Linux und Mitbetreuer von eBPF, über die Entwicklung von eBPF an. dieses Video von Alexei Starovoitov eBPF – eine kurze Geschichte 1993 – In einem des Lawrence Berkeley National Lab wird die Verwendung eines Kernel-Agenten zur Paketfilterung untersucht. Daher kommt auch der Name BPF („Berkeley Packet Filter“). Artikel 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. , der es implementiert hat, wurde in Infrastruktur- und Betriebskreisen weithin als Experte für eBPF bekannt. Brendan Gregg 2017 – Facebook stellt , seinen eBPF-basierten Load Balancer, als Open-Source-Lösung zur Verfügung. Jedes einzelne Paket an seit 2017 hat eBPF durchlaufen. Katran Facebook.com 2020 – Google hat eBPF zu einem Teil seines Kubernetes-Angebots gemacht. eBPF unterstützt jetzt die von GKE. Mittlerweile gibt es auch eine breite Unternehmensakzeptanz bei Unternehmen wie und . Netzwerk-, Sicherheits- und Observability-Ebene Capital One Adobe 2021 – Facebook, Google, Netflix, Microsoft und Isovalent haben sich zusammengeschlossen, um die anzukündigen, um das Wachstum der eBPF-Technologie zu verwalten. eBPF-Stiftung 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: Vernetzung Sicherheit Beobachtbarkeit Sicherheit und Netzwerke haben eine breitere Akzeptanz und Anwendung erfahren, vorangetrieben durch Projekte wie . Im Vergleich dazu befinden sich eBPF-basierte Observability-Angebote in einem frühen Entwicklungsstadium und stehen gerade erst am Anfang. Cilum 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 - verwendet eBPF zur Erkennung von Eindringlingen in großem Maßstab Google verwendet eBPF, um Containersicherheit zu implementieren Shopify Mehrere verwenden mittlerweile eBPF zur Datenerfassung und -überwachung. Sicherheitsangebote von Drittanbietern 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). nutzt eBPF, um DDoS-Angriffe zu erkennen und zu verhindern, und verarbeitet , ohne die Netzwerkleistung zu beeinträchtigen. Cloudflare 10 Millionen Pakete pro Sekunde Metas eBPF-basierter übernimmt den Lastausgleich für ganz Facebook Katran 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: – Abrufen von Telemetriedaten aus Anwendungen und Infrastruktur Datenerfassung – Filtern, Indizieren und Durchführen von Berechnungen für die gesammelten Daten Datenverarbeitung – Kurz- und Langzeitspeicherung von Daten Datenspeicherung – Bestimmen, wie Daten vom Benutzer verbraucht werden Benutzererfahrungsschicht 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). Vorgegeben/manuell Dynamisch Kernel Kernel-Tracepoints kprobes Benutzerbereich USDT Uroben Statisches und dynamisches eBPF bindet sich in den User-Space und den Kernel-Space ein – werden zum Einbinden in von Kernel-Entwicklern vordefinierte Ereignisse verwendet (mit TRACE_EVENT-Makros) Kernel-Tracepoints – wird zum Einbinden in vordefinierte Tracepoints verwendet, die von Entwicklern im Anwendungscode festgelegt wurden USDT (Kernel Probes) – werden zur dynamischen Einbindung in beliebige Teile des Kernel-Codes zur Laufzeit verwendet Kprobes (User Probes) – werden zur dynamischen Einbindung in jeden Teil einer User-Space-Anwendung zur Laufzeit verwendet Uprobes 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 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 Debugging. zur Laufzeit Live- 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. eBPF ermöglicht eine umfassende Überwachung von Ereignissen auf Systemebene wie CPU-Auslastung, Speicherzuweisung, Festplatten-E/A und Netzwerkverkehr. . System- und Infrastrukturüberwachung: LinkedIn verwendet beispielsweise eBPF für die gesamte Infrastrukturüberwachung Einblick in Kubernetes-spezifische Metriken, Ressourcennutzung und Zustand einzelner Container und Pods. Container- und Kubernetes-Überwachung: Detaillierte Beobachtbarkeit von User-Space-Anwendungen und Einblick in Anwendungsdurchsatz, Fehlerraten, Latenz und Traces. Application Performance Monitoring (APM): 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. Benutzerdefinierte Beobachtbarkeit: eBPF kann für erweiterte Observability-Anwendungsfälle wie , und verwendet werden. Erweiterte Observability: Live-Debugging Anwendungsprofilierung mit geringem Overhead Systemaufrufverfolgung 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. Unabhängige Software-SDKs/-Bibliotheken, die in Anwendungscode oder Infrastrukturknoten integriert sind, um Telemetriedaten zu sammeln. Agentenbasierte 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. Sidecar-Proxy-basierte Instrumentierung Einen detaillierten Vergleich der eBPF-basierten Instrumentierung im Vergleich zu Agenten und Sidecars . Nachfolgend finden Sie eine zusammenfassende Ansicht: finden Sie hier eBPF Agenten Beiwagen 1. Datensichtbarkeit/Granualität (aber einige Lücken) Hoch Hoch Niedrig 2. Aufdringlichkeit (außerhalb des Bandes) Niedrig (inline) Hoch (inline) Hoch 3. Leistungsaufwand Niedrig Mittel Hoch 4. Sicherheit und Schutz Hoch Mittel Mittel 5. Einfache Implementierung Hoch Niedrig Mittel 6. Einfache Wartung und Updates Hoch Niedrig Mittel 7. Skalierbarkeit Hoch Mittel Niedrig Wie wir sehen können, übertrifft eBPF bestehende Instrumentierungsmethoden in nahezu allen Parametern. Es gibt mehrere Vorteile – (Infrastruktur, Anwendungen) Kann alles auf einmal abdecken – 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. Weniger aufdringlich – eBPF wird als nativer Maschinencode ausgeführt und es findet kein Kontextwechsel statt. Geringer Leistungsaufwand – aufgrund integrierter Sicherheitsmaßnahmen wie der Verifizierung. Sicherer – kann ohne Code-Änderung oder Neustart eingesetzt werden. Einfach zu installieren – auch hier keine Codeänderung und Neustarts. Einfache Wartung und Aktualisierung – dank einfacher Implementierung und Wartung sowie geringem Leistungsaufwand Besser skalierbar Was die Nachteile betrifft, besteht die größte Lücke bei der heutigen eBPF-Beobachtbarkeit in der verteilten Ablaufverfolgung ( , aber der Anwendungsfall befindet sich noch in einem frühen Stadium). durchführbar 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 als auch lösen. Nischenanwendungsfälle komplexe Observability-Lösungen 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 . 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. KI 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 https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html https://ebpf.io/ https://ebpf.io/summit-2022.html https://github.com/microsoft/ebpf-for-windows https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf Auch hier veröffentlicht.
