DeepFlow: eBPF-Observability ohne Instrumentierung, und wo sie an Grenzen stößt
eBPF Observability - Distributed Tracing and Profiling
Auf einen Blick
- Was ist das?
- DeepFlow sammelt Metriken, Traces, Request-Logs und Profiling-Daten per eBPF auf jedem Knoten und korreliert sie über einen eigenen Agent-Server-Aufbau. Der Ansatz spart Instrumentierung, verlangt aber Zugriff auf den Kernel und eine Serverkomponente im Cluster.
- Für wen ist es gedacht?
- DeepFlow passt zu DevOps- und SRE-Teams, die Prozesse in beliebigen Sprachen auf Kubernetes-Knoten oder klassischen Hosts beobachten wollen und dafür keinen Code anfassen möchten. Wer keine Kernel-Zugriffsrechte erhält, keinen Server im Cluster betreiben will oder ausschließlich anwendungsspezifische Geschäftsmetriken braucht, sollte die Entscheidung vertagen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem DeepFlow adressiert und für wen
Die übliche Antwort auf fehlende Sichtbarkeit in Microservices heißt Instrumentierung: SDKs einbinden, Spans erzeugen, Export-Endpunkte konfigurieren. Das kostet Arbeit pro Sprache, pro Dienst und pro Release. DeepFlow setzt an einer anderen Stelle an. Laut README sammelt das Projekt Metriken, Distributed Tracing, Request-Logs und Funktions-Profiling per eBPF, ohne dass Anwendungscode verändert wird. Der Anspruch ist Zero Code, und die Zielgruppe sind DevOps- und SRE-Teams, die Diagnose von der Code-Ebene bis zur Infrastruktur betreiben.
Interessant ist das vor allem dort, wo Instrumentierung praktisch nicht durchsetzbar ist: fremde Dienste, ältere Hosts, Sprachen ohne brauchbares SDK, oder Dienste, deren Betreiber schlicht keine Zeit für Tracing-Ausbau haben. DeepFlow beobachtet Prozesse auf dem Knoten, nicht die Anwendung selbst. Das ist der Kern des Versprechens und gleichzeitig die Grenze des Verfahrens.
Agent und Server: der Datenfluss der Community Edition
Die Softwarearchitektur der Community Edition besteht laut README aus zwei Komponenten. Ein Agent läuft auf jedem Kubernetes-Knoten, auf klassischen Hosts und auf Cloud-Hosts. Er ist für die Erfassung von AutoMetrics- und AutoTracing-Daten aller Anwendungsprozesse auf diesem Host zuständig. Ein Server läuft im Kubernetes-Cluster und übernimmt Agent-Verwaltung, Tag-Injection, Datenaufnahme und Abfragedienste.
Der Agent ist also die Stelle mit Kernel-Nähe, der Server die Stelle mit Zustand. Diese Trennung hat Konsequenzen für den Betrieb: Der Agent ist ein DaemonSet beziehungsweise ein Host-Prozess, der Server ein zentraler Dienst mit Datenhaltung. Wer nur einen Agent auf einem einzelnen Host startet, bekommt keine vollständige Auswertung, weil die Tag-Injection und die Abfrageebene auf der Serverseite liegen.
Für die Speicherschicht beschreibt das README SmartEncoding: standardisierte, vorab kodierte Metadaten-Tags werden in alle Observability-Daten injiziert. Eigene Tags und Beobachtungsdaten werden getrennt abgelegt. Die dokumentierte Folge ist, dass Tags in vielen Dimensionen und Kardinalitäten verfügbar bleiben, ohne die Abfrageleistung zu zerstören. Die im README genannte Zahl von 10x weniger Speicheraufwand gegenüber der String- oder LowCard-Methode von ClickHouse stammt aus der Projektbeschreibung und ist nicht unabhängig nachvollzogen.
Erfassung: Protokolle, Wasm und die Grenze des Auto-Modus
AutoMetrics und AutoTracing funktionieren nur so weit, wie der Agent den Datenverkehr interpretieren kann. Das README nennt gängige Protokolle sowie Wasm-Plugins für private Protokolle. Das ist der ehrliche Teil des Designs: Wo ein Standardprotokoll vorliegt, greift die automatische Auswertung. Wo ein eigenes Binärformat über die Leitung geht, muss ein Plugin geschrieben werden. Der Zero-Code-Anspruch gilt für die Anwendung, nicht für die Protokollunterstützung.
Das Tracing umfasst laut README Gateways, Service Meshes, Datenbanken, Message Queues, DNS und Netzwerkkarten. Für jeden Span werden Netzwerk-Performance-Metriken und Datei-I/O-Ereignisse mitgesammelt. Das ist ein netzwerkzentrischer Ansatz, der in der Projektbeschreibung bis zu einer SIGCOMM-2023-Publikation führt. Der Vorteil: Lücken zwischen zwei Diensten werden sichtbar, auch wenn keiner der beiden Dienste selbst instrumentiert ist. Der Nachteil: Die Aussagekraft endet dort, wo die Semantik der Anwendung beginnt. Ein Span zeigt, dass ein Aufruf stattgefunden hat und wie lange er dauerte. Er zeigt nicht, welcher Geschäftsvorgang dahintersteckt, wenn dieser nicht aus dem Protokoll ablesbar ist.
Beim Continuous Profiling nennt das README Kosten unterhalb von einem Prozent und Flammengraphen für OnCPU, OffCPU, GPU, Memory und Network über Business-Funktionen, Bibliotheken, Runtime, Shared Libraries, Kernelfunktionen und CUDA-Funktionen. Die Zahl ist eine Projektangabe, kein Messwert aus einem neutralen Test.
Installation: was das Material tatsächlich hergibt
Das README verweist für die Community Edition auf die Deployment-Dokumentation unter deepflow.io/docs/ce-install/all-in-one/ und für den Quellbau auf agent/build.md im Repository. Konkrete Manifeste, Helm-Values oder Konfigurationsschlüssel enthält der vorliegende Auszug nicht. Wer den Artikel liest, um eine Installationsanleitung zu bekommen, wird hier nicht fündig; die Angaben reichen nur bis zur Verweisstruktur.
Klar belegt ist dagegen der Aufbau: Agent pro Knoten, Server im Cluster. Ebenso belegt sind die drei Editionen. DeepFlow Community richtet sich laut README an Entwickler, DeepFlow Enterprise an Organisationen mit Team-Kollaborationsbedarf, DeepFlow Cloud ist ein SaaS-Angebot im Beta-Stadium. Die Community Edition besteht aus den Kernkomponenten der Enterprise Edition. Wer die Enterprise-Funktionen braucht, findet dafür im Auszug keine Beschreibung des Funktionsumfangs.
Für den Quellbau ist die Sprachangabe Go und die Lizenz Apache-2.0. Der Agent lässt sich laut README aus dem Quellbaum übersetzen; das Build-Dokument liegt unter agent/build.md. Alles Weitere, etwa Abhängigkeiten oder Versionsanforderungen an den Kernel, steht in diesem Dokument und nicht im README-Auszug.
Wo der Ansatz scheitert oder schlicht nicht passt
eBPF ist eine Kernel-Technologie. Ohne ausreichende Rechte auf den Zielknoten, ohne passende Kernel-Version und ohne die Möglichkeit, Kernel-Programme zu laden, funktioniert die Erfassung nicht. In verwalteten Kubernetes-Umgebungen mit eingeschränkten Knotenrechten oder mit Kernel-Varianten, die bestimmte Programmtypen nicht zulassen, ist DeepFlow das falsche Werkzeug. Das ist keine Nebenbemerkung, sondern die erste Frage vor jeder Evaluierung.
Der zweite Punkt betrifft die Datenmenge. Netzwerk-, Datei-I/O- und Profiling-Daten fallen pro Prozess und pro Verbindung an. Wer den Agent ohne Begrenzung auf allen Knoten eines großen Clusters laufen lässt, verschiebt das Problem von der Instrumentierung zur Speicher- und Netzwerklast zwischen Agent und Server. Das README nennt SmartEncoding als Antwort darauf, aber die Kompression ersetzt keine Auswahl: Welche Namespaces, welche Protokolle, welche Abtastrate, das muss konfiguriert werden.
Der dritte Punkt ist konzeptionell. DeepFlow beobachtet, was über die Leitung geht und was der Kernel sieht. Fehler, die sich ausschließlich im Anwendungszustand abspielen (eine falsche Berechnung, ein fehlerhaftes Cache-Invalidierung, ein Logikfehler ohne Netzwerkauswirkung), erscheinen in diesen Daten nicht. Wer Fehlerklassen jenseits von Latenz, Fehlerrate und Netzwerkverhalten sucht, braucht zusätzlich Logs oder Traces aus der Anwendung selbst.
Abgrenzung zu OpenTelemetry und SkyWalking
Der Unterschied liegt im Erfassungsort. OpenTelemetry sammelt Telemetrie dort, wo sie entsteht: in der Anwendung, über SDKs und den Collector, mit einem vendor-neutralen Datenmodell. Das erfordert Instrumentierung, liefert aber Semantik, die kein Kernel sehen kann, etwa Span-Attribute aus der Geschäftslogik. SkyWalking verfolgt einen ähnlichen Ansatz mit Agent-basierter Instrumentierung und eigenem Datenmodell.
DeepFlow erfasst stattdessen auf der Host- und Netzwerkebene und leitet die Semantik aus Protokollen und Metadaten ab. Das README beschreibt DeepFlow zugleich als Speicher-Backend für Prometheus, OpenTelemetry, SkyWalking und Pyroscope sowie als Datenquelle über SQL-, PromQL- und OLTP-APIs. Der praktische Unterschied: Instrumentierte Dienste können ihre Daten weiterhin über OpenTelemetry liefern, während nicht instrumentierte Dienste über eBPF abgedeckt werden. Die Entscheidung ist also nicht DeepFlow oder OpenTelemetry, sondern welche Dienste welchen Weg nehmen. Wer ausschließlich eigene Anwendungen mit vollständiger SDK-Kontrolle betreibt, bekommt mit einem reinen OpenTelemetry-Aufbau eine reichere Semantik bei geringerer Infrastrukturkomplexität.
Wartung, Release-Takt und Lizenz
Die Release-Historie im Material zeigt v7.2.1 vom 27. August 2026, v7.2.0 vom 13. August 2026 und v7.1 vom 25. März 2026. Zwischen v7.1 und v7.2.0 liegen rund viereinhalb Monate, danach zwei Releases im Abstand von zwei Wochen. Das deutet auf größere Versionssprünge mit anschließenden Korrekturreleases hin. Wer den Agent aus dem Quellbaum baut, muss die Agent-Version zum Server-Release passend wählen; das README trennt beide Komponenten ausdrücklich, ohne im Auszug eine Kompatibilitätsmatrix zu nennen. Diese Matrix ist vor einem Upgrade zu klären, nicht danach.
Lizenzrechtlich steht das Projekt unter Apache-2.0. Diese Lizenz erlaubt Nutzung, Änderung und Weitergabe, verlangt aber die Beibehaltung von Copyright- und Lizenzhinweisen und enthält eine Klausel zu Patenten. Für die Community Edition ist damit der kommerzielle Einsatz grundsätzlich möglich. Das ist keine Rechtsberatung; wer den Agent modifiziert und weiterverteilt, sollte die Bedingungen im LICENSE-File selbst prüfen. Für Enterprise- und Cloud-Editionen enthält der Auszug keine Lizenz- oder Preisangaben, sodass dazu keine Aussage möglich ist.
Redaktionelles Fazit
DeepFlow passt zu DevOps- und SRE-Teams, die Prozesse in beliebigen Sprachen auf Kubernetes-Knoten oder klassischen Hosts beobachten wollen und dafür keinen Code anfassen möchten. Wer keine Kernel-Zugriffsrechte erhält, keinen Server im Cluster betreiben will oder ausschließlich anwendungsspezifische Geschäftsmetriken braucht, sollte die Entscheidung vertagen. Vor dem Rollout ist zu prüfen, welche Kernel-Version die Zielknoten haben, ob der eigene Agent-Build mit dem Server-Release zusammenpasst und welche Datenhoheit für die Server-Instanz gilt.
Community-Notizen