Observabilité eBPF : éclairer le noyau sans fragiliser la production
eBPF rend visibles des événements réseau et système difficiles à observer depuis les applications. Dans un environnement régulé, son intérêt dépend toutefois autant de la gouvernance des sondes que de leur profondeur technique.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Les architectures distribuées créent des angles morts. Une requête traverse plusieurs services, conteneurs, interfaces réseau et couches de sécurité avant d’atteindre une donnée. Les journaux applicatifs décrivent ce que le code a prévu de consigner, pas nécessairement ce qui s’est produit dans le système d’exploitation. Une connexion refusée, une résolution DNS lente, une attente d’entrée-sortie ou un processus bloqué peuvent rester invisibles jusqu’à ce que l’incident affecte les utilisateurs. eBPF réduit cet écart en exécutant, dans le noyau Linux, de petits programmes contrôlés et attachés à des événements précis. Il peut observer des appels système, des flux réseau, l’activité des processus ou certains comportements de l’ordonnanceur, sans modifier chaque application.
Ce que cela change
Pour l’exploitation, le premier changement est la proximité avec la source de l’événement. Une équipe peut relier un flux réseau à un processus ou à un conteneur, distinguer un délai applicatif d’une attente système et repérer des communications qui ne figurent dans aucune documentation d’architecture. Cette visibilité est particulièrement utile lorsque les charges sont éphémères ou que plusieurs équipes partagent la même infrastructure. Elle ne remplace pourtant ni les métriques, ni les journaux, ni les traces applicatives. eBPF décrit bien le comportement technique observé par le noyau, mais connaît rarement le contexte métier d’une opération. Le diagnostic devient plus solide lorsque ces données sont corrélées avec des identifiants de transaction, des changements déployés et une chronologie fiable.
Les arbitrages à instruire
- Compatibilité : le comportement disponible dépend du noyau Linux, de sa configuration, de l’architecture matérielle et des fonctions autorisées sur l’hôte. Une sonde validée sur une plateforme ne doit pas être présumée équivalente partout. La matrice de compatibilité fait partie du dossier d’exploitation.
- Performance : l’exécution dans le noyau évite certaines lourdeurs des agents traditionnels, mais elle n’est pas gratuite. Une collecte trop large, des événements très fréquents ou une agrégation mal conçue peuvent augmenter la consommation de processeur, de mémoire et de stockage. Le coût doit être mesuré sur une charge représentative.
- Sécurité : une capacité d’observation profonde devient elle-même un actif sensible. Les droits de chargement, de configuration et de lecture des sondes doivent être séparés. L’accès général aux événements du noyau sous prétexte de diagnostic est une mauvaise pratique.
- Données : les événements collectés peuvent révéler des adresses, des noms de services, des chemins de fichiers, des commandes ou des éléments associés à une personne. La minimisation, le filtrage à la source, la durée de conservation et la localisation des données doivent être définis avant le déploiement.
- Maintenabilité : chaque sonde est du code en production. Elle exige une version identifiable, une revue, des tests, une procédure de déploiement progressif et un retour arrière. Une règle opaque activée directement sur tous les hôtes n’est pas une capacité d’observabilité maîtrisée.
Adopter par cas d’usage
L’adoption est pertinente lorsqu’un problème précis résiste aux outils existants : cartographier les communications réelles entre conteneurs, attribuer des retransmissions réseau à une charge, comprendre une saturation d’entrée-sortie ou détecter l’exécution inattendue d’un processus. Il vaut mieux commencer sur un périmètre Linux homogène, avec une hypothèse mesurable et des critères d’arrêt. Le pilote doit comparer le diagnostic obtenu, le coût de collecte, le volume produit et les effets sur la production. Pour une organisation régulée, il faut aussi conserver la configuration active, l’identité de l’opérateur, les changements de sondes et les règles de filtrage. Ces éléments rendent l’observation explicable et reproductible. Une adoption généralisée se justifie seulement si la plateforme peut gérer les versions, les droits, la rétention, la synchronisation temporelle et le retrait des sondes sans intervention improvisée sur chaque hôte.
eBPF n’est ni une preuve exhaustive ni un dispositif de conformité automatique. Une absence d’événement peut provenir d’un filtre, d’une incompatibilité, d’une perte de données ou d’une sonde inactive. Les tableaux de bord doivent donc exposer l’état de la collecte elle-même. La bonne question n’est pas seulement « que voyons-nous ? », mais aussi « comment savons-nous que nous observons encore correctement ? »
Distributed architectures create blind spots. A request crosses multiple services, containers, network interfaces and security layers before reaching data. Application logs describe what the code was designed to record, not necessarily what happened in the operating system. A rejected connection, slow DNS resolution, an input-output wait or a blocked process may remain invisible until the incident affects users. eBPF narrows this gap by running small, controlled programs inside the Linux kernel and attaching them to specific events. It can observe system calls, network flows, process activity and certain scheduler behaviours without modifying every application.
What changes
For operations teams, the first change is proximity to the source of an event. A team can associate a network flow with a process or container, distinguish application latency from system wait time, and identify communications that appear in no architecture document. This visibility is particularly useful when workloads are ephemeral or several teams share the same infrastructure. It does not, however, replace metrics, logs or application traces. eBPF provides a strong view of technical behaviour observed by the kernel, but it rarely understands the business context of an operation. Diagnosis becomes more reliable when these data are correlated with transaction identifiers, deployed changes and a trustworthy timeline.
Trade-offs to assess
- Compatibility: available behaviour depends on the Linux kernel, its configuration, the hardware architecture and the features permitted on the host. A probe validated on one platform should not be assumed to behave identically everywhere. The compatibility matrix belongs in the operational record.
- Performance: running inside the kernel avoids some overhead associated with traditional agents, but it is not free. Overly broad collection, high-frequency events or poorly designed aggregation can increase processor, memory and storage consumption. The cost must be measured under a representative workload.
- Security: deep observability is itself a sensitive capability. Permissions to load, configure and read probes should be separated. Granting broad access to kernel events under the pretext of troubleshooting is poor practice.
- Data: collected events may expose addresses, service names, file paths, commands or information associated with an individual. Data minimisation, source filtering, retention periods and data location must be defined before deployment.
- Maintainability: every probe is production code. It needs an identifiable version, review, testing, a progressive deployment procedure and rollback. An opaque rule enabled directly across all hosts is not a controlled observability capability.
Adopt by use case
Adoption is relevant when a specific problem remains unresolved by existing tools: mapping actual communications between containers, attributing network retransmissions to a workload, understanding input-output saturation or detecting unexpected process execution. A better starting point is a consistent Linux scope, a measurable hypothesis and explicit stop criteria. The pilot should compare the diagnostic value obtained, collection cost, data volume and production impact. A regulated organisation should also retain the active configuration, operator identity, probe changes and filtering rules. These records make observations explainable and reproducible. Broader adoption is justified only if the platform can manage versions, permissions, retention, time synchronisation and probe removal without improvised work on each host.
eBPF is neither exhaustive evidence nor an automatic compliance mechanism. A missing event may result from filtering, incompatibility, data loss or an inactive probe. Dashboards should therefore expose the health of the collection system itself. The right question is not only “what can we see?” but also “how do we know that we are still observing correctly?”