Kommentar zu Observability-Trends 2022 Das Linux-Kernel-Feature eBPF als Telemetrie-Treiber

Zwei Faktoren treiben diverse Innovationen in der Open-Source-Observability-Landschaft voran: Verteiltes Tracing sowie eBPF, der „extended Berkley Package Filter“ als Teil des Linux-Kernel. Was können wir davon noch erwarten?

Während das verteilte Rückverfolgen (Tracing) mit OpenTelemetry „erwachsen“ wird, steht eBPF als nächste Grenze von Observability und Monitoring unter Linux im Zentrum der Innovationen. Der „extended Berkley Packet Filter“ ist eine faszinierende Technologie, die direkt in den Linux-Kernel integriert ist.

eBPF wurde als programmierbare Methode für den Umgang mit Netzwerken geschaffen und hat sich zu einer ziemlich generischen und leistungsfähigen Einrichtung für den sicheren, dynamischen Zugriff auf den Linux-Kernel entwickelt. Sie ermöglicht es unter anderem, Telemetrie für Beobachtungs- und Sicherheitszwecke zu extrahieren. Das Feature ist so leistungsfähig und so beliebt, dass Microsoft an einer eBPF-Portierung auf Windows arbeitet.

Was die Beobachtbarkeit angeht, so hat sich eBPF im Jahr 2021 als bemerkenswert vielseitig erwiesen. So gibt es beispielsweise Tools, die eBPF zur Durchführung von verteiltem Tracing verwenden, wie das Pixie-Projekt, das Mitte 2021 von New Relic als Open-Source-Projekt veröffentlicht wurde. Aber der vielversprechendste Aspekt von eBPF für 2022 ist in meinen Augen die Tatsache, dass es mit eBPF möglich ist, ein kontinuierliches Profiling von Anwendungen in der Produktion zu implementieren.

Beispiele hierfür sind das bereits erwähnte Pixie-Projekt und Parca. Wie Googles Cloud Profiler und verschiedene kommerzielle Observability-Tools beweisen, ist ein ständig aktiver Profiler mit geringem Aufwand in der Produktion unglaublich leistungsfähig, um Latenz- und Speicherprobleme in Produktionsumgebungen zu beheben, die in Testlabors bekanntermaßen schwer und zeitaufwändig zu reproduzieren sind.

Die Profilerstellung mit eBPF findet zwar schon in die Produktionsumgebungen statt, hat sich aber noch nicht so weit etabliert, dass sie mit den meisten Anwendungen genutzt werden kann. Die Art und Weise, wie die Profilerstellung funktioniert, ist in den verschiedenen Runtime-Umgebungen und Programmiersprachen erstaunlich unterschiedlich.

Während sich fast alle auf dem Markt befindlichen Sprachen in Bezug auf CPU-Nutzung und Speicherzuweisung ähnlich verhalten (aber selbst in solchen grundlegenden Fragen der Datenverarbeitung gibt es Unterschiede), ist die Art und Weise, wie sie mit Gleichzeitigkeit umgehen, sehr unterschiedlich, und zwar in allen Bereichen.

Ein Beispiel: Java verwendet Threads innerhalb der Java Virtual Machine, die auf Threads im Betriebssystem abgebildet werden (fairerweise muss man sagen, dass es auch andere Optionen gibt, wie NIO und Bibliotheken wie RxJava, Reactor, Vert.x; außerdem wird Project Loom irgendwann ausgeliefert); in Node.js hingegen wird Gleichzeitigkeit hauptsächlich mit der Ereignisschleife behandelt, und „echte“ Threads im Betriebssystem sind vom Entwickler abstrahiert.

Unterschiede wie diese sind für einen Profiler von großer Bedeutung, da die Daten, die der Person, die ein Problem behebt, angezeigt werden, in das von der Programmiersprache verwendete Modell für Gleichzeitigkeit „übersetzt“ werden müssen. Das erfordert explizite Unterstützung im Profiler für bestimmte Laufzeiten.

2022 wird meiner Meinung nach das Jahr sein, in dem wir voll funktionsfähige, quelloffene, eBPF-basierte Produktions-Profiling-Tools erhalten, die die Besonderheiten der vielen Runtime-Umgebungen verstehen, die in den heutigen Cloud-nativen Anwendungen vorherrschen, wie Java, Node.js, Python und .NET; sowie kompilierte Sprachen wie Go und Rust. Und das wird für alle DevOps, SRE und Betreiber ein absoluter Game-Changer sein, um Software besser zu machen und Probleme schneller zu lösen!"

* Michele Mancioppi, Doktor der Computerwissenschaften, ist Produktmanager bei Canonical für Observability.

(ID:47917799)