Beyla et eBPF : instrumenter sans toucher au code

Le scénario est toujours le même. Un client arrive avec une plateforme qui rame, une quinzaine de services, et zéro trace applicative. Le monolithe PHP date de 2016, personne ne sait le recompiler proprement. Le service Java a été écrit par un prestataire parti depuis. Le binaire Go, lui, tourne très bien, mais l'ajouter à un pipeline OpenTelemetry veut dire rouvrir un dépôt, ajouter un SDK, repasser en recette et redéployer. Trois semaines de chantier, minimum, pour obtenir la première courbe de latence.

Beyla propose l'inverse : un démon posé à côté, qui lit le trafic au niveau du kernel et sort des métriques RED et des traces sans qu'une seule ligne applicative ne bouge. C'est séduisant, et c'est réellement utile. Reste à savoir où ça s'arrête, parce que la promesse « observabilité sans code » cache un plafond que personne n'aime découvrir en incident.

Beyla attache des sondes eBPF aux points d'entrée et de sortie réseau des processus qu'on lui désigne. Il intercepte les appels systèmes qui portent le trafic HTTP, HTTP/2, gRPC, SQL, Redis, Kafka, MongoDB, AMQP, MQTT, et en reconstruit des transactions. De là il produit deux choses : des métriques RED (Rate, Errors, Duration) par service et par route, et des spans exportés en OTLP vers n'importe quel backend compatible.

Le point important, c'est que la donnée est captée hors du processus applicatif. Pas d'agent injecté dans la JVM, pas de LD_PRELOAD, pas de sidecar qui partage la mémoire de l'app. Si Beyla plante, l'application ne le remarque pas. Cette propriété seule justifie de le regarder sérieusement : sur du legacy critique, un agent APM qui s'injecte dans le runtime est un risque de production. Un programme eBPF qui observe depuis le kernel n'en est pas un du même ordre.

Le projet a une histoire qui compte pour décider. Beyla 1.0 est sorti en novembre 2023 chez Grafana Labs. En mai 2025, à GrafanaCON, Grafana a donné le code à la fondation OpenTelemetry sous le nom OpenTelemetry eBPF Instrumentation, abrégé OBI. Le SIG dédié réunit des mainteneurs de Grafana Labs, Splunk, Coralogix et Odigos. Depuis, Beyla n'est plus le projet, c'est la distribution Grafana d'OBI, avec les intégrations Cloud et Alloy en plus. Autrement dit : le moteur est devenu un composant de l'écosystème OpenTelemetry, plus un produit d'éditeur. Pour un choix d'infra à cinq ans, c'est la bonne nouvelle du dossier.

OBI demande un noyau Linux 5.8 ou plus, ou une famille RHEL en 4.18 avec les backports eBPF nécessaires, plus le support BTF. Architectures amd64 et arm64 uniquement. Linux seulement : rien sous Windows.

Sur le terrain, ce prérequis élimine plus de machines qu'on ne le pense. Une Debian 10 ou une CentOS 7 qui traîne encore en prod, et le sujet est clos avant d'avoir commencé. Le noyau BTF n'est pas non plus systématique sur les images minimalistes ou les kernels custom d'hyperviseurs anciens.

Côté privilèges, Beyla tourne en root, ou avec un jeu restreint de capabilities Linux selon les fonctionnalités activées. En Kubernetes, ça veut dire un DaemonSet privilégié qui voit le trafic de tous les pods du nœud. Le piège classique : on déploie ça sans réfléchir au périmètre, et on se retrouve avec un composant qui a une visibilité kernel sur des workloads multi-tenants. La règle qu'on applique : Beyla est traité comme un composant de sécurité, pas comme un agent de supervision banal. RBAC serré, image épinglée, mise à jour suivie. Les mêmes réflexes que pour Cilium ou Tetragon.

C'est la question qui tombe systématiquement, et pour une fois la doc officielle donne des mesures reproductibles plutôt qu'un « négligeable » marketing.

Grafana a mesuré Beyla sur un cluster Kind faisant tourner la démo OpenTelemetry, avec une charge moyenne de 75 requêtes par seconde. Les résultats, par scénario cumulatif :

Sur la latence, la mesure est la plus parlante : l'ensemble des sondes cumulées sur 24 heures représente environ 40 ms de temps passé, soit de l'ordre de 500 nanosecondes par requête. À ce niveau, l'instrumentation disparaît dans le bruit de mesure d'à peu près n'importe quelle application web.

Deux nuances honnêtes. D'abord, l'overhead est proportionnel au taux de requêtes, pas au volume de trafic réseau : un service à 5 000 req/s ne se compare pas à la démo à 75 req/s, et il faut mesurer chez soi. Ensuite, la phase d'instrumentation initiale provoque un pic mémoire temporaire autour de 600 Mo avant stabilisation. Sur un nœud Kubernetes avec des limites serrées, un DaemonSet dimensionné à 128 Mo se fera OOM-kill au démarrage. C'est le genre de détail qui coûte une demi-journée de diagnostic quand on ne l'a pas lu.

Beyla 2.5 a ajouté un mode survey : une découverte légère qui recense les services, les protocoles et les schémas de communication sans payer le coût de l'instrumentation complète. Sur un parc inconnu, c'est le bon premier geste. On cartographie, puis on décide quoi instrumenter.

Voilà le point que les billets d'annonce survolent. eBPF observe des frontières de processus et des appels réseau. Il ne voit pas l'intérieur de votre application, et il ne le verra jamais.

Concrètement, ce que Beyla ne produit pas :

• Les spans internes. Un appel à un handler Spring Boot, une frontière de transaction Hibernate, une section critique métier : invisible. Vous obtenez « la requête a pris 840 ms », pas « dont 700 ms dans la sérialisation JSON du catalogue ».
• Les exceptions avec pile d'appels. Un SDK attache l'exception et sa stack trace au span. eBPF voit un code HTTP 500 et s'arrête là.
• Les attributs métier. Identifiant de tenant, type de commande, plan tarifaire : rien de tout ça n'existe au niveau kernel.
• Les métriques runtime. Occupation du tas, activité du garbage collector côté JVM : hors périmètre. Pour ça, il faut un SDK ou du profiling continu.
• La corrélation logs-traces. L'injection automatique du trace ID dans les logs applicatifs reste une fonctionnalité de SDK.

Et sur le tracing distribué, la limite est structurelle. La propagation de contexte fonctionne bien pour Go, Node.js, Python et Ruby sur des services HTTP et gRPC. Elle décroche sur les frameworks réactifs, les threads virtuels Java et les pools de threads complexes. La raison est simple : eBPF doit rattacher un contexte de trace à un fil d'exécution, et les runtimes qui découplent agressivement la requête du thread cassent cette hypothèse. Sur une stack Spring WebFlux, ne comptez pas sur des traces distribuées cohérentes de bout en bout.

Le graphe de services, lui, ne donne des noms de services que sur Kubernetes. Sur des VM classiques, vous obtenez des adresses IP, et c'est à vous de recoller les étiquettes.

Rien d'exotique, et c'est ce qui le rend adoptable. Beyla est un producteur OTLP standard. Trois branchements possibles.

Le plus simple : Beyla expose ses métriques au format Prometheus, votre Prometheus existant le scrape, et rien d'autre ne change. Les métriques RED arrivent avec les conventions sémantiques OpenTelemetry, on branche les dashboards et les alertes Alertmanager dessus. C'est la configuration qu'on met en place en premier chez un client, parce qu'elle n'ajoute aucun composant nouveau à opérer.

Ensuite, l'export OTLP vers un collector, puis vers Tempo pour les traces. C'est là que le graphe de services prend son intérêt, et c'est aussi là que le volume explose si on ne réfléchit pas à l'échantillonnage. Beyla trace tout par défaut. Sur un service à fort trafic, la facture de stockage arrive vite.

Enfin, l'intégration via Grafana Alloy, qui embarque un composant Beyla. Ça évite un binaire de plus à déployer si Alloy est déjà en place sur le parc.

Le point d'attention : la cardinalité. Beyla génère des étiquettes par route HTTP. Un service REST avec des identifiants dans les chemins d'URL produit une explosion de séries temporelles si la normalisation des routes n'est pas configurée. Ce n'est pas une critique de Beyla, c'est le piège de toute instrumentation automatique. Regardez le nombre de séries dans les 48 heures qui suivent la mise en production, pas trois semaines après.

La réponse tranchée, celle qu'on donne en réunion d'architecture.

Beyla est le bon outil quand vous héritez d'un parc non instrumenté et que vous voulez une baseline en quelques heures ; quand les stacks sont hétérogènes et qu'aligner cinq SDK différents coûterait des mois ; quand le code est fermé, propriétaire ou impossible à recompiler ; quand il faut prouver l'intérêt de l'observabilité avant d'obtenir un budget de chantier applicatif.

Beyla n'est pas le bon outil quand le besoin est de comprendre le comportement interne d'un service. Une latence anormale sur un endpoint précis, une contention de pool de connexions, un algorithme métier qui dégénère : eBPF vous dit que c'est lent, il ne vous dit pas pourquoi. À ce moment-là, il faut de la vraie instrumentation applicative, et aucun raccourci kernel ne la remplacera.

La règle qu'on applique : Beyla en couverture large sur tout le parc, SDK OpenTelemetry en profondeur sur les trois ou quatre services qui portent le chiffre d'affaires. Les deux se complètent au lieu de se concurrencer, et c'est exactement la position de la fondation OpenTelemetry depuis la donation. Le discours « eBPF remplace les SDK » est un discours de vendeur, pas d'opérateur.

Un dernier avertissement sur la maturité. OBI n'a franchi son premier jalon de release qu'en 2025, et le projet reste en alpha côté fondation. Les protocoles s'ajoutent vite, la qualité progresse, mais on ne bâtit pas un dispositif d'astreinte sur un composant en alpha sans plan B. Gardez vos sondes de disponibilité et vos métriques infrastructure classiques comme socle. Beyla ajoute de la visibilité applicative, il ne remplace pas une supervision Kubernetes solide.

Si vous avez un parc mal instrumenté, ne lancez pas un chantier. Déployez Beyla en mode survey sur un nœud de préproduction, laissez-le tourner 48 heures, et regardez la cartographie qu'il sort. Vous saurez alors quels services parlent à quoi, sur quels protocoles, et à quel volume. C'est l'information qui manque à 90% des équipes qui héritent d'une plateforme, et elle coûte 0,05% de CPU à obtenir.

Ensuite seulement, décidez quoi instrumenter en profondeur. Une cartographie factuelle vaut mieux qu'un atelier de trois heures autour d'un schéma dessiné de mémoire.

Une chaîne d'observabilité qui tient en incident, ça se construit du bas vers le haut : métriques infrastructure fiables, supervision réseau, puis instrumentation applicative, et une astreinte qui sait quoi regarder à 3 heures du matin. C'est le travail qu'on mène sur les infrastructures qu'on opère, avec une GTI contractualisée en option et des runbooks tenus à jour plutôt que des dashboards jolis. Si votre plateforme produit beaucoup de graphiques et peu de réponses, on peut reprendre la supervision et l'exploitation de bout en bout.

• Beyla performance overhead, documentation Grafana : mesures officielles de CPU, mémoire et latence par scénario, avec les conditions de test.
• OpenTelemetry eBPF Instrumentation, documentation OpenTelemetry : protocoles supportés, prérequis noyau et BTF, privilèges requis, limites annoncées.
• Introducing OpenTelemetry eBPF Instrumentation: Why we donated Grafana Beyla to OpenTelemetry : contexte de la donation de mai 2025 et évolution du positionnement de Beyla.
• Why OpenTelemetry instrumentation needs both eBPF and SDKs, Grafana Labs : liste détaillée de ce que l'eBPF ne capture pas par rapport à un SDK.
• OpenTelemetry eBPF Instrumentation Marks the First Release : première release alpha d'OBI, protocoles ajoutés et limites du tracing distribué.
• Building on the foundation of OpenTelemetry eBPF Instrumentation: what's new in Grafana Beyla 2.5 : mode survey et vendoring du code amont.