Tu as déjà vécu ça : un service qui plante en prod, zéro trace, zéro métrique, parce que personne n’a eu le temps d’ajouter le SDK OpenTelemetry avant la mise en prod. L’instrumentation manuelle, c’est la première victime des deadlines. En 2026, un projet change la donne : OpenTelemetry eBPF Instrumentation (OBI) capture traces et métriques directement dans le noyau Linux, sans toucher une ligne de code applicatif.
Dans cet article, tu vas voir comment OBI fonctionne, comment le déployer en quelques minutes sur une stack existante, et comment Azure propose son propre équivalent côté réseau avec Advanced Container Networking Services. De quoi décider si ça vaut le coup de l’ajouter à ta stack d’observabilité dès maintenant.
Le problème que l’instrumentation manuelle ne résout jamais complètement
Même avec les meilleurs SDK OpenTelemetry, l’instrumentation manuelle a trois angles morts récurrents : les services legacy que personne n’ose toucher, les dépendances tierces dont tu ne contrôles pas le code, et le délai entre le déploiement d’un nouveau service et le moment où quelqu’un pense à l’instrumenter. Résultat, ta couverture d’observabilité ressemble à un gruyère — complète là où ça compte le moins, trouée là où un incident finit par arriver.
C’est exactement le vide que l’approche eBPF comble : une visibilité automatique, appliquée au niveau du noyau, qui ne dépend d’aucune modification de code.
eBPF et OBI : comment ça marche concrètement
eBPF (extended Berkeley Packet Filter) permet d’exécuter du code sandboxé directement dans le noyau Linux, sans module noyau custom ni redémarrage. Appliqué à l’observabilité, ça veut dire intercepter les appels système et le trafic réseau d’un processus pour en déduire son comportement applicatif — sans jamais charger le moindre agent dans le processus lui-même.
De Grafana Beyla à OpenTelemetry eBPF Instrumentation
Le projet a démarré comme Grafana Beyla, avant d’être donné à la fondation OpenTelemetry et rebaptisé OBI. Cette bascule sous gouvernance CNCF/OpenTelemetry est ce qui a permis l’adoption large qu’on observe depuis le début d’année : les données produites respectent nativement le format OpenTelemetry (OTLP), donc elles s’intègrent directement à n’importe quel backend déjà en place — Grafana, Datadog, Azure Monitor, peu importe.
Ce qu’OBI capture réellement
Concrètement, OBI donne accès sans instrumentation à :
- Des traces distribuées, avec propagation de contexte à travers les appels HTTP et gRPC entre services
- Les métriques RED (Rate, Errors, Duration) par service et par endpoint
- Le support d’un nombre croissant de protocoles applicatifs — HTTP, gRPC, et l’expansion 2026 prévoit MQTT, AMQP, NATS, Redis pub/sub et MongoDB
Déployer OBI en pratique
Le déploiement le plus simple reste un conteneur sidecar ou un DaemonSet Kubernetes qui s’attache aux processus ciblés via leur cgroup ou leur port d’écoute. Exemple minimal en environnement Kubernetes :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: obi-instrumentation
namespace: observability
spec:
selector:
matchLabels:
app: obi
template:
metadata:
labels:
app: obi
spec:
hostPID: true
containers:
- name: obi
image: otel/ebpf-instrument:latest
securityContext:
privileged: true
env:
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: "http://otel-collector.observability:4317"
- name: OTEL_EBPF_OPEN_PORT
value: "8080"Pas de redéploiement applicatif, pas de sidecar dans chaque pod métier : un seul DaemonSet observe tout le nœud. C’est cette simplicité opérationnelle qui explique l’engouement — tu factures le coût d’adoption une seule fois, pour tout le cluster.
Le pendant réseau côté Azure : Advanced Container Networking Services
Si OBI couvre la couche applicative, Microsoft a poussé une approche eBPF équivalente côté réseau pour AKS avec Advanced Container Networking Services (ACNS). Basé sur le data plane Cilium et l’intégration Hubble, ACNS capture la latence DNS, les flux pod-à-pod, les drops de policy réseau et les métriques HTTP au niveau 7 — le tout remonté nativement vers Azure Monitor managed Prometheus et Azure Managed Grafana.
Si ton budget ne justifie pas l’offre payante ACNS, l’alternative open source de Microsoft, Retina, couvre l’essentiel avec les mêmes fondations eBPF, en self-managed et gratuite — un bon point de départ avant d’envisager la version gérée.
| Offre | Coût | Gestion | Cas d’usage |
|---|---|---|---|
| ACNS | Service Azure payant | Entièrement managé | Observabilité réseau entreprise, dashboards Grafana avancés |
| Network Observability (Azure Monitor) | Inclus avec Prometheus managé | Managé | Monitoring basique niveau nœud/cluster |
| Retina OSS | Gratuit, open source | Self-managed | Debug avancé, captures de paquets, multicloud |
Où en est OBI en septembre 2026
Le projet vise une release stable 1.0 avec quatre priorités affichées pour l’année : la stabilisation du format de configuration avec schémas JSON documentés, l’expansion vers de nouveaux protocoles (dont les SDK cloud AWS, Google Cloud et Azure), une couverture .NET élargie (.NET 8+ ainsi que les frameworks legacy .NET 4.x), et surtout une intégration hybride fluide avec l’instrumentation manuelle existante — pour que tu puisses garder tes SDK OpenTelemetry là où tu en as déjà, et ajouter OBI en complément plutôt qu’en remplacement. Retrouve le détail complet sur la page officielle des objectifs 2026 d’OBI et la documentation OpenTelemetry zero-code.
Faut-il l’adopter maintenant ?
Si tu gères déjà une stack Grafana/Prometheus/OpenTelemetry — voir notre tour d’horizon de la stack d’observabilité 2026 — ajouter OBI en complément ne coûte quasiment rien : tu gagnes une couverture de base sur tous les services, y compris ceux que personne n’a instrumentés. En revanche, si ta stack est encore jeune, mieux vaut d’abord poser les fondations OTLP/collector avant d’ajouter une couche eBPF par-dessus, pour éviter d’empiler la complexité.
La documentation officielle de Grafana Beyla, le moteur historique derrière OBI, reste une excellente ressource pour comprendre les options de configuration fines : Grafana Beyla documentation.
FAQ
OBI remplace-t-il complètement l’instrumentation manuelle ?
Non, et ce n’est pas l’objectif du projet. OBI donne une visibilité de base immédiate ; l’instrumentation manuelle reste utile pour capturer des données métier spécifiques (un identifiant de commande, un montant de panier) que le noyau ne peut pas déduire du trafic réseau.
Est-ce que ça fonctionne sur Windows ?
Non, eBPF est une technologie noyau Linux. Pour des workloads Windows, il faut rester sur l’instrumentation SDK classique ou les agents Azure Monitor Application Insights.
Quel est l’impact en performance ?
Le surcoût est généralement de l’ordre de quelques pourcents de CPU par nœud, comparable aux sidecars de service mesh classiques — largement compensé par le gain de couverture obtenu sans effort d’instrumentation.
Est-ce compatible avec Kubernetes 1.37 ?
Oui, aucune contrainte de version particulière côté Kubernetes lui-même. Si tu viens de migrer, jette un œil à notre article sur les nouveautés de Kubernetes 1.37 pour vérifier qu’aucun changement ne touche tes DaemonSets privilégiés.
En résumé
OBI marque un vrai changement de philosophie pour l’observabilité : au lieu de courir après la couverture d’instrumentation service par service, tu pars d’une visibilité complète par défaut, et tu affines ensuite là où c’est utile. Teste-le sur un cluster non critique cette semaine, avec le DaemonSet ci-dessus — tu seras fixé en une heure sur ce qu’il t’apporte réellement.
Laisser un commentaire