DeepFlow : observabilité zero code à base d'eBPF, et ce qu'elle implique vraiment

Le problème que DeepFlow attaque : instrumenter sans toucher au code

L'observabilité classique suppose que quelqu'un ajoute des bibliothèques dans chaque service, redéploie, puis maintient ces points d'instrumentation au fil des versions. DeepFlow prend le problème par l'autre bout. Le README annonce une collecte « Zero Code » par eBPF pour les métriques, les traces distribuées, les journaux de requêtes et le profilage de fonctions. Le public visé est nommé dans le même paragraphe : les équipes DevOps et SRE qui doivent diagnostiquer des applications cloud-native et d'IA sans imposer aux développeurs un travail d'instrumentation continu. La promesse couvre aussi les protocoles privés, via des plugins Wasm, ce qui sort du cadre des seuls protocoles standards reconnus par les agents classiques. Le projet est publié sous licence Apache-2.0, en Go, et le dépôt n'est pas archivé, avec une dernière poussée en septembre 2026 et une version v7.2.1 datée du 27 août 2026. Ces éléments indiquent un projet actif, pas nécessairement un projet adapté à votre pile : la suite dépend de votre noyau et de votre topologie.

Deux composants, une séparation nette entre collecte et corrélation

L'architecture décrite dans le README tient en deux briques. Un Agent s'exécute sur chaque nœud Kubernetes, chaque hôte legacy et chaque machine cloud, et se charge de la collecte AutoMetrics et AutoTracing pour tous les processus applicatifs de la machine. Un Server tourne dans un cluster Kubernetes et assure la gestion des Agents, l'injection de tags, l'ingestion et les services de requête. Cette séparation a une conséquence pratique : l'Agent est le point de contact avec le noyau, le Server est le point de contact avec vos utilisateurs et vos tableaux de bord. Le mécanisme de stockage repose sur ce que le projet appelle SmartEncoding, qui injecte des métadonnées standardisées et pré-encodées dans toutes les données d'observabilité. Le README affirme une réduction de l'overhead de stockage d'un facteur 10 par rapport aux méthodes String ou LowCard de ClickHouse, et indique que les tags personnalisés sont stockés séparément des données, ce qui autorise un nombre de dimensions élevé sans dégrader les requêtes. Ces chiffres viennent de la documentation du projet, pas d'une mesure indépendante reproduite ici. Le point de conception intéressant est la séparation tags/données : elle évite le piège classique du tag à forte cardinalité qui fait exploser l'index.

Ce que la collecte remonte réellement, du noyau jusqu'aux spans

Le README détaille trois familles de signaux. La première est la carte universelle des services, alimentée par eBPF en production, couvrant services applicatifs, services d'IA et services d'infrastructure quelle que soit la langue. La deuxième est le traçage distribué, qui selon la documentation couvre les applications, mais aussi les passerelles, les service meshes, les bases de données, les files de messages, le DNS et les cartes réseau. Chaque span reçoit des métriques de performance réseau et des événements d'E/S fichier collectés automatiquement. La troisième est le profilage continu, annoncé à un coût inférieur à 1 pour cent, avec des flame graphs OnCPU, OffCPU, GPU, mémoire et réseau, et une corrélation automatique avec les données de traçage. La profondeur revendiquée va des fonctions métier aux fonctions de bibliothèque, de framework, de runtime, de bibliothèque partagée, jusqu'aux fonctions du noyau et aux fonctions CUDA. C'est le point le plus ambitieux du projet : relier une trace lente à une pile d'appels noyau ou CUDA dans le même outil. La documentation ne précise pas, dans les éléments fournis, comment les symboles sont résolus pour chaque runtime, ce qui reste la question technique centrale pour qui veut valider la couverture réelle.

Mise en route : ce que le dépôt donne comme point de départ

Le README ne fournit pas de commande d'installation complète. Il renvoie à la documentation de déploiement pour l'édition Community, sous le chemin ce-install/all-in-one, et précise que l'édition Community se compose des composants cœur de l'édition Enterprise. Trois éditions coexistent : Community pour les développeurs, Enterprise pour les organisations avec des besoins de collaboration d'équipe, Cloud en SaaS en beta. Pour la compilation depuis les sources, le README pointe vers un seul fichier, agent/build.md, dans le répertoire agent. Autrement dit, la construction de l'Agent est documentée, celle du Server ne l'est pas dans ce README. Une démo Community publique est mentionnée, avec un compte et un mot de passe fournis en clair dans le fichier. C'est un choix discutable sur le plan de l'hygiène des identifiants, même pour une démo. Si vous cherchez des clés de configuration, des variables d'environnement ou des valeurs Helm, elles ne figurent pas dans le matériel fourni : il faut passer par le site de documentation. Je ne peux donc pas lister ici de commandes de déploiement vérifiées, seulement les points d'entrée que le dépôt désigne lui-même.

Les angles morts que le README ne comble pas

eBPF est une technologie du noyau Linux. Le README remercie le projet eBPF et positionne DeepFlow dans le paysage eBPF, sans jamais énoncer de version minimale de noyau ni de prérequis de distribution. C'est la première chose à vérifier avant de s'engager, car un parc hétérogène avec des noyaux anciens ou des distributions durcies produira une couverture partielle, silencieuse par nature. Deuxième limite : le profilage est annoncé à moins de 1 pour cent de coût, mais la méthode de mesure n'est pas donnée, et ce chiffre dépend entièrement de la charge et du type de pile collectée. Troisième limite : la dépendance à un Server déployé dans Kubernetes pour la gestion des Agents, l'injection de tags et les requêtes. Sur un parc de machines virtuelles sans Kubernetes, l'Agent se déploie, mais le Server reste à héberger ailleurs, ce qui ajoute une brique d'exploitation. Enfin, la fonctionnalité de protocoles privés passe par des plugins Wasm : écrire et maintenir un plugin Wasm est un travail de développement, donc la promesse zero code s'arrête à la frontière de vos protocoles maison. DeepFlow n'est pas le bon outil si votre besoin principal est l'instrumentation manuelle fine d'un code métier avec des attributs sémantiques riches définis par les développeurs.

Face à OpenTelemetry : deux philosophies, pas deux versions du même outil

Le README indique que DeepFlow peut servir de backend de stockage pour Prometheus, OpenTelemetry, SkyWalking et Pyroscope, et exposer des API SQL, PromQL et OLTP. La différence d'approche avec OpenTelemetry est nette. OpenTelemetry est un ensemble d'API et de SDK neutres vis-à-vis des fournisseurs : la collecte se fait dans le processus applicatif, ce qui suppose d'ajouter des dépendances, de redéployer, et de choisir un exportateur. DeepFlow déplace la collecte hors du processus, dans le noyau, et accepte en entrée les données OpenTelemetry plutôt que de les produire par instrumentation. Le compromis est symétrique. OpenTelemetry donne un contrôle total sur ce qui est émis et fonctionne sur n'importe quel système d'exploitation, y compris Windows, mais exige du travail par service et par langage. DeepFlow ne demande aucune modification du code sur Linux, mais dépend du noyau, remonte ce que le noyau voit, et laisse moins de prise sur la sémantique métier des spans. Les deux peuvent cohabiter : DeepFlow ingère les signaux OpenTelemetry et injecte des métadonnées de ressources cloud, de conteneurs, de labels et d'annotations Kubernetes, ainsi que des attributs CMDB.

Maintenance, versions et portée de la licence

Le rythme de publication visible dans le matériel est irrégulier : v7.1 en mars 2026, puis v7.2.0 en août 2026 et v7.2.1 quelques semaines plus tard. Cela suggère des cycles de fonctionnalités espacés, suivis de correctifs rapprochés, ce qui est un schéma courant mais implique de prévoir une fenêtre de mise à jour lors des montées de version mineure. Le README mentionne un fichier de plan de fonctionnalités futures, donc la feuille de route est publique. Sur la licence, Apache-2.0 autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions et de l'état des modifications. Le README distingue explicitement l'édition Community, qui reprend les composants cœur, des éditions Enterprise et Cloud. Cette séparation signifie qu'une partie du produit n'est pas dans ce dépôt : si une fonctionnalité dont vous dépendez n'apparaît que dans l'édition Enterprise, le code Apache-2.0 ne vous la donnera pas. Ce n'est pas un avis juridique, et les conditions exactes des éditions non communautaires ne sont pas décrites dans le matériel fourni.

Conclusion éditoriale

DeepFlow convient aux équipes DevOps/SRE qui exploitent Kubernetes ou des hôtes Linux et veulent des traces et des métriques réseau sans modifier le code. Il ne convient pas si vous devez instrumenter des applications hors Linux, car la collecte repose sur eBPF, une technologie du noyau Linux. Avant de déployer, vérifiez la version du noyau sur vos nœuds et lisez la documentation d'installation all-in-one, car le README ne détaille ni les prérequis noyau ni les valeurs de configuration de l'Agent.

Sources officielles

1. deepflowio/deepflow on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases