Eine eBPF-basierte Open-Source-Observability-Plattform

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Was ist eBPF?

eBPF wurde ursprünglich als Technologie zur Paketfilterung für den Linux-Kernel entwickelt. Im Lauf der Zeit hat es sich jedoch zu einer Allzwecktechnologie entwickelt, mit der sich Programme in einer Sandbox innerhalb des Betriebssystem-Kernels ausführen lassen. Für Observability bedeutet das: eBPF kann von Observability-Werkzeugen genutzt werden, um sich an unterschiedliche Ereignisse zu hängen – etwa Systemaufrufe, Ein- und Austrittspunkte von Funktionen sowie Netzwerkereignisse.

Wie eBPF Observability verbessert

eBPF-Programme laufen im Kernel selbst, wodurch sich Daten mit minimalem Performance-Overhead erheben lassen. Das ist besonders in hochverfügbaren Cloud-Umgebungen mit niedriger Latenz wichtig.

Bei klassischer Observability mussten Entwickler zudem den Code anpassen, um die Anwendung zu instrumentieren und beobachtbar zu machen. eBPF hingegen ermöglicht die dynamische Instrumentierung mehrerer Programmiersprachen, ohne den Quellcode der Anwendung anzupassen oder die Anwendung auch nur neu zu starten.
Da eBPF-Programme auf Kernel-Ebene laufen, können sie auf Kontextdaten wie CPU-Auslastung, Speicherbelegung, Ein-/Ausgabeoperationen und anwendungsspezifische Netzwerkaktivität zugreifen.

Sicherheit von eBPF

Da Programme auf Kernel-Ebene das gesamte System zum Absturz bringen könnten, führt der Linux-Kernel den eBPF-Verifier ein, der verhindert, dass eBPF-Programme in den Kernel-Space geladen werden, wenn sie die Prüfungen nicht bestehen. Dazu führt der Verifier statische Analysen, Plausibilitäts-, Sicherheits- und Schutzprüfungen durch, um sicherzustellen, dass das eBPF-Programm speichersicher ist und die Kernel-Sicherheit weder durch Privilege Escalation noch durch Zugriff auf nicht autorisierten Kernel-Speicher gefährdet. Schlägt eine dieser Prüfungen fehl, wird das Programm nicht geladen.

Zusätzlich zu diesen Maßnahmen laufen eBPF-Programme in einer Sandbox und können nur auf kontrollierte, vorab definierte Weise interagieren.

eBPF-Observability-Werkzeuge

Das Grafana-Ökosystem, bekannt für seine leistungsfähigen Visualisierungs- und Monitoring-Lösungen, hat eBPF-basierte Werkzeuge integriert, um umfassende Observability in cloud-nativen Umgebungen zu bieten. Hier ein Blick auf einige der wichtigsten Werkzeuge dieses Ökosystems:

1. Grafana Alloy
   Beschreibung: Grafana Alloy ist der neueste Open-Source-Observability-Agent und hat den Grafana Agent abgelöst. Alloy ist darauf ausgelegt, Metriken, Logs, Profiling-Daten und Traces effizient aus verschiedenen Quellen zu erfassen – mit nativer Unterstützung für eBPF-basierte Datenerhebung. Über eBPF kann Alloy detaillierte Systemmetriken direkt aus dem Kernel gewinnen und so hochaufgelöste Einblicke in Performance und Verhalten liefern.

2. Grafana Pyroscope
   Beschreibung: Grafana Pyroscope ist ein Werkzeug für Continuous Profiling und hat Grafana Phlare abgelöst. Es erfasst und analysiert Performance-Profile von Anwendungen und nutzt eBPF, um detaillierte Daten zur CPU-Auslastung zu sammeln. Mit Pyroscope lassen sich Profiling-Daten in Grafana neben anderen Observability-Metriken visualisieren – für eine einheitliche Sicht auf System- und Anwendungsleistung. Die Erfassung von Speicherdaten über eBPF wird derzeit nicht unterstützt.

3. Grafana Beyla
   Beschreibung: Grafana Beyla ist ein kürzlich eingeführtes Werkzeug, das eBPF nutzt, um Observability für Anwendungsanfragen und deren Auswirkung auf die Systemleistung zu bieten. Beyla erfasst detaillierte Metriken zu Anwendungsanfragen – darunter Latenz, Fehler und Ressourcenverbrauch – direkt aus dem Kernel über eBPF.

Diese Daten werden anschließend innerhalb der Grafana-Plattform mit anderen Observability-Signalen korreliert und ergeben ein umfassendes Bild von Anwendungsverhalten und -leistung.
Beyla eignet sich vor allem als Ausgangspunkt für die Auto-Instrumentierung von Anwendungen, da es RED-Metriken (Rate, Errors, Duration) sowie Tracing-Telemetrie liefert.

Observability-Pipeline mit OpenTelemetry

Eine Observability-Pipeline ist unerlässlich, um den Fluss von Telemetriedaten in komplexen verteilten Systemen zu steuern. OpenTelemetry (OTel) ist ein Open-Source-Framework, das einen standardisierten Ansatz zum Erfassen und Exportieren von Telemetriedaten – Metriken, Traces und Logs – aus Anwendungen und Infrastruktur bietet. In einem eBPF-gestützten Observability-Setup kann OpenTelemetry als Rückgrat der Pipeline dienen und einen durchgängigen Datenfluss über Werkzeuge und Plattformen hinweg sicherstellen.

Kernkomponenten einer OpenTelemetry-basierten Observability-Pipeline

1. Datenerhebung: Die Pipeline beginnt mit der Datenerhebung über eBPF und OpenTelemetry. eBPF liefert Systemmetriken und Anwendungseinblicke, ohne dass der Anwendungscode geändert werden muss. OpenTelemetry sammelt Telemetriedaten sowohl aus eBPF-Quellen als auch aus der Instrumentierung auf Anwendungsebene und sorgt so für eine einheitliche Sicht auf die Systemleistung.

2. Datenverarbeitung: Nach der Erhebung werden die Daten verarbeitet, um Formate zu vereinheitlichen, sie mit Kontext anzureichern und Rauschen herauszufiltern. In dieser Phase kommen Verarbeitungswerkzeuge aus OpenTelemetry zum Einsatz, etwa der OpenTelemetry Collector als zentraler Agent für das Aufnehmen und Verarbeiten von Telemetriedaten aus unterschiedlichen Quellen.

3. Datenexport: Die verarbeiteten Daten werden anschließend an eine oder mehrere Observability-Plattformen exportiert, etwa Grafana, Prometheus oder Dynatrace. OpenTelemetry unterstützt eine große Bandbreite an Exportern, sodass Daten für Analyse und Visualisierung an mehrere Backends geleitet werden können. Der Export in Echtzeit ermöglicht nahezu unmittelbare Einblicke und erlaubt zugleich die Speicherung für historische Auswertungen.

Vorteile von OpenTelemetry in einer eBPF-Observability-Pipeline

• Interoperabilität: Da OpenTelemetry unterschiedliche Datenformate und Observability-Backends unterstützt, gelingt die nahtlose Integration sowohl mit Open-Source- als auch mit kommerziellen Werkzeugen – für ein flexibles Observability-Ökosystem.

• Skalierbarkeit: Durch die Bündelung der Telemetriedaten in einer standardisierten Pipeline kann das Observability-System mit der Infrastruktur mitwachsen und auch in durchsatzstarken Umgebungen leistungsfähig bleiben.

• Tiefere Einblicke: Die Kombination der Anwendungssicht von OpenTelemetry mit den Kernel-Einblicken von eBPF ergibt eine Full-Stack-Sicht auf das Systemverhalten – für schnellere Fehlersuche und Performance-Optimierung.

Alles zusammenführen

Mit diesem Wissen ist nun klar, was eBPF ist, was es leistet und warum es großen Nutzen bringt. Um die Technologie in einem Beispiel-Setup zu nutzen, rollen wir eine Observability-Plattform für einen Kubernetes-Cluster aus. Sie besteht aus:

• Grafana Alloy (OpenTelemetry-Distribution mit eBPF-Fähigkeiten)

  • Grafana Beyla (eBPF)

  • Grafana Pyroscope (eBPF)

• Grafana Loki (Logs)

• Grafana Mimir (Metriken)

• Grafana Tempo (Traces)

• Grafana Pyroscope (Profiling)

• Grafana (Visualisierung)

In diesem Setup nutzen wir Grafana Alloy als OpenTelemetry-basierten Agenten, der unsere Observability-Pipeline verantwortet. Grafana Alloy kann Beyla eBPF einbinden, um automatisch Traces von laufenden Prozessen auf den Kubernetes-Nodes zu gewinnen. Pyroscope bietet ebenfalls ein eBPF-Modul, das CPU-Profile aus laufenden C/C++-, Go- oder Rust-Anwendungen extrahiert. Grundsätzlich unterstützt Pyroscope eBPF nativ kompilierte Anwendungen.

Datenfluss in Alloy

Discovery:

• Kubernetes-Pods werden erkannt und mit Metadaten angereichert

Erhebung:

• Traces werden über OTLP oder per Auto-Instrumentierung mit Beyla erfasst

• Metriken werden von den Pods gescraped

• Logs werden aus stdout/stderr der Pods gesammelt

• Profile werden über eBPF erfasst

Verarbeitung:

• Traces werden aus Effizienzgründen gebündelt

• Traces werden über Span-Metriken in Metriken überführt

• Traces dienen der Erzeugung einer Service-Topologie

• Metriken werden transformiert und angereichert

Export:

• Traces werden nach Tempo exportiert

• Metriken werden nach Mimir exportiert

• Logs werden an Loki gesendet

• Profile werden an Pyroscope gesendet

Visualisierung:

• Grafana fragt alle Backends ab und erstellt daraus einheitliche Dashboards

Konfigurationskomponenten von Alloy

Discovery-Komponenten

• discovery.kubernetes.k8s_pods: erkennt Kubernetes-Pods

• discovery.relabel.local_pods: versieht erkannte Pods mit Metadaten-Labels

Erfassung von Traces

• otelcol.receiver.otlp.default: empfängt Traces über das OTLP-Protokoll

• beyla.ebpf.beyla: instrumentiert Anwendungen automatisch über eBPF

• tracing: konfiguriert das Sampling der Traces

Prozessoren

• otelcol.processor.batch.beyla: bündelt Traces für eine effiziente Verarbeitung

• otelcol.processor.transform.default: transformiert Metrikdaten

Connectors

• otelcol.connector.spanmetrics.default: wandelt Traces in Metriken um

• otelcol.connector.servicegraph.default: erzeugt aus Traces eine Service-Topologie

Exporter

• otelcol.exporter.otlphttp.beyla: exportiert Traces nach Tempo

• otelcol.exporter.prometheus.default: exportiert Metriken im Prometheus-Format

Erfassung von Metriken

• prometheus.scrape.demo: scraped Metriken von Kubernetes-Pods

• prometheus.remote_write.default: sendet Metriken an Mimir

Erfassung von Logs

• loki.source.kubernetes.pods: sammelt Logs von Kubernetes-Pods

• loki.write.local: sendet Logs an Loki

Erfassung von Profilen

• pyroscope.ebpf.local_pods: erfasst Profile über eBPF

• pyroscope.write.endpoint: sendet Profile an Pyroscope

Kubernetes-Deployment

Die Konzepte und die jeweiligen Aufgaben der Komponenten, die für eine ganzheitliche eBPF-basierte Observability-Plattform nötig sind, sind nun bekannt. Der nächste Schritt besteht darin, die benötigten Werkzeuge auf einem Kubernetes-Cluster einzurichten. Dafür steht ein beispielhaftes Helm-Chart in einem GitHub-Repository bereit.