Décodage de l'observabilité eBPF :

Il y a eu beaucoup de discussions sur eBPF dans les communautés natives du cloud au cours des 2 dernières années. eBPF était un pilier de KubeCon, les journées eBPF et les sommets eBPF gagnent rapidement en popularité, des entreprises comme Google et Netflix utilisent eBPF depuis des années et de nouveaux cas d'utilisation émergent tout le temps. Surtout en matière d'observabilité, eBPF devrait changer la donne.

Alors regardons eBPF - quelle est la technologie, quel est son impact sur l'observabilité, comment se compare-t-elle aux pratiques d'observabilité existantes et que pourrait nous réserver l'avenir ?

Qu'est-ce que l'eBPF ?

eBPF est un cadre de programmation qui nous permet d'exécuter en toute sécurité des programmes en bac à sable dans le noyau Linux sans modifier le code du noyau.

Il a été développé à l'origine pour Linux (et c'est toujours là que la technologie est la plus mature aujourd'hui), mais Microsoft fait rapidement évoluer l' implémentation d'eBPF pour Windows .

Les programmes eBPF sont de par leur conception très efficaces et sécurisés - ils sont vérifiés par le noyau pour s'assurer qu'ils ne mettent pas en péril la stabilité ou la sécurité du système d'exploitation.

Alors pourquoi eBPF est-il si important ?

Pour comprendre cela, nous devons comprendre l'espace utilisateur et l'espace noyau.

L'espace utilisateur est l'endroit où toutes les applications s'exécutent. L'espace noyau se situe entre l'espace utilisateur et le matériel physique. Les applications dans l'espace utilisateur ne peuvent pas accéder directement au matériel. Au lieu de cela, ils effectuent des appels système au noyau, qui accède ensuite au matériel.

Tous les accès à la mémoire, les lectures/écritures de fichiers et le trafic réseau passent par le noyau. Le noyau gère également les processus concurrents.

Fondamentalement, tout passe par le noyau (voir la figure ci-dessous).

Et eBPF fournit un moyen sûr et sécurisé d'étendre les fonctionnalités du noyau.

Historiquement, pour des raisons évidentes, changer quoi que ce soit dans le code source du noyau ou la couche des systèmes d'exploitation a été extrêmement difficile.

Le noyau Linux a 30 millions de lignes de code , et il faut plusieurs années pour qu'un changement passe d'une simple idée à une large diffusion. Tout d'abord, la communauté Linux doit l'accepter. Ensuite, il doit faire partie de la version officielle de Linux. Puis, après quelques mois, il est repris par des distributions comme Red Hat et Ubuntu, qui l'amènent à un public plus large.

Techniquement, on pourrait charger des modules du noyau dans son noyau et apporter des modifications directement, mais cela présente un risque très élevé et implique une programmation complexe au niveau du noyau, ce qui est presque universellement évité.

eBPF arrive et résout ce problème - et fournit un mécanisme sécurisé et efficace pour attacher et exécuter des programmes dans le noyau.

Voyons comment eBPF assure à la fois la sécurité et les performances.

Hautement sécurisé

• Vérification rigoureuse - Avant qu'un programme eBPF puisse être chargé dans un noyau, il est vérifié par le vérificateur eBPF , qui garantit que le code est absolument sûr - par exemple, pas de boucles dures, d'accès mémoire invalides, d'opérations non sécurisées.

  
  

• Sandbox - Les programmes eBPF sont exécutés dans un bac à sable isolé en mémoire au sein du noyau, séparé des autres composants du noyau. Cela empêche tout accès non autorisé à la mémoire du noyau, aux structures de données et au code source du noyau.

  
  

• Opérations limitées - les programmes eBPF doivent généralement être écrits dans un petit sous-ensemble du langage C - un jeu d'instructions restreint. Cela limite les opérations que les programmes eBPF peuvent effectuer, réduisant ainsi le risque de failles de sécurité.

Haute performance / léger

• Exécuter en tant que code machine natif - Les programmes eBPF sont exécutés en tant qu'instructions machine natives sur le processeur. Cela conduit à une exécution plus rapide et à de meilleures performances.

  
  

• Pas de changement de contexte - Une application standard change régulièrement de contexte entre l'espace utilisateur et l'espace noyau, ce qui consomme beaucoup de ressources. Les programmes eBPF, lorsqu'ils s'exécutent dans la couche noyau, peuvent accéder directement aux structures de données et aux ressources du noyau.

  
  

• Piloté par les événements - Les programmes eBPF ne s'exécutent généralement qu'en réponse à des événements spécifiques du noyau, au lieu d'être toujours actifs. Cela minimise les frais généraux.

  
  

• Optimisé pour le matériel - Les programmes eBPF sont compilés en code machine par le compilateur JIT (Just-In-Time) du noyau juste avant l'exécution, de sorte que le code est optimisé pour le matériel spécifique sur lequel il s'exécute.

  
  

Ainsi, eBPF fournit un crochet sûr et efficace dans le noyau pour la programmation. Et étant donné que tout passe par le noyau, cela ouvre plusieurs nouvelles possibilités qui n'étaient pas possibles jusqu'à présent.

Pourquoi est-ce un gros problème seulement maintenant ?

La technologie autour de l'eBPF a évolué sur une longue période et a mis environ 30 ans à se développer.

Au cours des 7 à 8 dernières années, eBPF a été utilisé à grande échelle par plusieurs grandes entreprises et nous entrons maintenant dans une ère où l'utilisation d'eBPF devient courante. Voir cette vidéo d'Alexei Starovoitov , co-créateur de Linux et co-mainteneur d'eBPF, sur l'évolution d'eBPF.

eBPF - un bref historique

• 1993 - Un article du Lawrence Berkeley National Lab explore l'utilisation d'un agent noyau pour le filtrage de paquets. C'est de là que vient le nom BPF ("Berkeley Packet Filter").

• 1997 - BPF est officiellement introduit dans le cadre du noyau Linux (version 2.1.75).

• 1997-2014 - Plusieurs fonctionnalités sont ajoutées pour améliorer, stabiliser et étendre les capacités du BPF.

• 2014 - Une mise à jour importante est introduite, appelée "filtre de paquets Berkeley étendu" (eBPF). Cette version apporte de grands changements à la technologie BPF et la rend plus largement utilisable - d'où le mot "étendu"

  
  

La raison pour laquelle cette version était importante, c'est qu'elle facilitait l'extension des fonctionnalités du noyau.

Un programmeur peut coder plus ou moins comme s'il s'agissait d'une application normale - et l'infrastructure eBPF environnante prend en charge la vérification, la sécurité et l'efficacité de bas niveau.

Tout un écosystème de soutien et un échafaudage autour d'eBPF rendent cela possible (voir la figure ci-dessous).

Source : https://ebpf.io/what-is-ebpf/

Mieux encore, les programmes eBPF pourraient être chargés et déchargés du noyau sans aucun redémarrage.

Tout cela a soudainement permis une adoption et une application généralisées.

Adoption généralisée dans les systèmes de production

La popularité d'eBPF a explosé au cours des 7 à 8 dernières années, plusieurs grandes entreprises l'utilisant dans des systèmes de production à grande échelle.

• En 2016, Netflix utilisait largement eBPF pour le traçage. Brendan Gregg , qui l'a mis en œuvre, est devenu largement connu dans les cercles d'infrastructure et d'exploitation en tant qu'autorité sur eBPF.

• 2017 - Facebook a ouvert Katran , leur équilibreur de charge basé sur eBPF. Chaque paquet vers Facebook.com depuis 2017 est passé par eBPF.

• 2020- Google a intégré eBPF à son offre Kubernetes. eBPF alimente désormais la couche de mise en réseau, de sécurité et d'observabilité de GKE. À l'heure actuelle, les entreprises comme Capital One et Adobe sont également largement adoptées.

• 2021 - Facebook, Google, Netflix, Microsoft et Isovalent se sont réunis pour annoncer la fondation eBPF pour gérer la croissance de la technologie eBPF.

  
  

Aujourd'hui, des milliers d'entreprises utilisent eBPF et des centaines de projets eBPF sont lancés chaque année pour explorer différents cas d'utilisation.

eBPF est maintenant un sous-système distinct au sein du noyau Linux avec une large communauté pour le prendre en charge. La technologie elle-même s'est considérablement développée avec plusieurs nouveaux ajouts.

Alors, que pouvons-nous faire avec eBPF ?

Les cas d'utilisation les plus courants pour eBPF se situent dans 3 domaines -

1. La mise en réseau
2. Sécurité
3. Observabilité

La sécurité et la mise en réseau ont connu une adoption et une application plus larges, alimentées par des projets comme Cilum . En comparaison, les offres d'observabilité basées sur eBPF sont plus précoces dans leur évolution et ne font que commencer.

Examinons d'abord les cas d'utilisation en matière de sécurité et de mise en réseau.

Sécurité

La sécurité est un cas d'utilisation très populaire pour eBPF. En utilisant eBPF, les programmes peuvent observer tout ce qui se passe au niveau du noyau, traiter les événements à grande vitesse pour vérifier les comportements inattendus et déclencher des alertes beaucoup plus rapidement qu'autrement.

Par exemple -

• Google utilise eBPF pour la détection d'intrusion à grande échelle

• Shopify utilise eBPF pour mettre en œuvre la sécurité des conteneurs

  
  

Plusieurs offres de sécurité tierces utilisent désormais eBPF pour la collecte et la surveillance des données.

La mise en réseau

La mise en réseau est un autre cas d'utilisation largement appliqué. Être au niveau de la couche eBPF permet une observabilité complète du réseau, comme la visibilité sur le chemin réseau complet, y compris tous les sauts, ainsi que l'IP source et de destination. Avec les programmes eBPF, on peut traiter des événements réseau à volume élevé et manipuler des paquets réseau directement dans le noyau avec une surcharge très faible.

Cela permet divers cas d'utilisation de la mise en réseau, tels que l'équilibrage de charge, la prévention DDoS, la mise en forme du trafic et la qualité de service (QoS).

• Cloudflare utilise eBPF pour détecter et empêcher les attaques DDoS, en traitant 10 millions de paquets par seconde sans affecter les performances du réseau.
• Katran basé sur eBPF de Meta effectue l'équilibrage de charge pour l'ensemble de Facebook

Observabilité

À présent, il doit être clair comment eBPF peut être utile dans l'observabilité.

Tout passe par le noyau. Et eBPF fournit un moyen hautement performant et sécurisé de tout observer depuis le noyau.

Plongeons plus profondément dans l'observabilité et examinons les implications de cette technologie.

Comment exactement eBPF impacte-t-il l'observabilité ?

Pour explorer cela, sortons de l'univers eBPF et passons à l'univers de l'observabilité et examinons ce qui constitue notre solution d'observabilité standard.

Toute solution d'observabilité a 4 composants principaux -

1. Collecte de données - Obtention de données de télémétrie à partir d'applications et d'infrastructures

2. Traitement des données - Filtrage, indexation et calculs sur les données collectées

3. Stockage des données - Stockage à court et à long terme des données

4. Couche d'expérience utilisateur - Déterminer comment les données sont consommées par l'utilisateur

   
   

Parmi ceux-ci, l'impact d'eBPF (à ce jour) n'est en réalité que la couche de collecte de données - la collecte facile de données de télémétrie directement à partir du noyau à l'aide d'eBPF.

Donc, ce que nous voulons dire quand nous parlons d'« observabilité eBPF » aujourd'hui, c'est d'utiliser eBPF comme mécanisme d'instrumentation pour recueillir des données de télémétrie, au lieu d'utiliser d'autres méthodes d'instrumentation. Les autres composants d'une solution d'observabilité restent inchangés.

Comment fonctionne l'observabilité eBPF

Pour bien comprendre les mécanismes sous-jacents à l'observabilité eBPF, nous devons comprendre le concept de crochets.

Comme nous l'avons vu précédemment, les programmes eBPF sont principalement axés sur les événements - c'est-à-dire qu'ils sont déclenchés à chaque fois qu'un événement spécifique se produit. Par exemple, chaque fois qu'un appel de fonction est effectué, un programme eBPF peut être appelé pour capturer certaines données à des fins d'observabilité.

Premièrement, ces hooks peuvent se trouver dans l'espace noyau ou dans l'espace utilisateur. Ainsi, eBPF peut être utilisé pour surveiller à la fois les applications de l'espace utilisateur et les événements au niveau du noyau.

Deuxièmement, ces crochets peuvent être soit prédéterminés/statiques, soit insérés dynamiquement dans un système en cours d'exécution (sans redémarrage !)

Quatre mécanismes eBPF distincts permettent chacun d'entre eux (voir figure ci-dessous)

Crochets eBPF statiques et dynamiques dans l'espace utilisateur et l'espace noyau

1. Points de trace du noyau - utilisés pour se connecter à des événements prédéfinis par les développeurs du noyau (avec les macros TRACE_EVENT)

2. USDT - utilisé pour se connecter à des points de trace prédéfinis définis par les développeurs dans le code d'application

3. Kprobes (Kernel Probes) - utilisé pour se connecter dynamiquement à n'importe quelle partie du code du noyau lors de l'exécution

4. Uprobes (User Probes) - utilisées pour se connecter dynamiquement à n'importe quelle partie d'une application de l'espace utilisateur au moment de l'exécution

   
   

Il existe plusieurs hooks prédéfinis dans l'espace noyau auxquels on peut facilement attacher un programme eBPF (par exemple, appels système, entrée/sortie de fonction, événements réseau, points de trace du noyau). De même, dans l'espace utilisateur, de nombreux runtimes de langage, systèmes de bases de données et piles de logiciels exposent des hooks prédéfinis pour les outils Linux BCC auxquels les programmes eBPF peuvent se connecter.

Mais ce qui est plus intéressant, ce sont les kprobes et les uprobes. Que se passe-t-il si quelque chose ne fonctionne pas dans la production et que je n'ai pas suffisamment d'informations et que je souhaite ajouter dynamiquement une instrumentation au moment de l'exécution ? C'est là que les kprobes et les uprobes permettent une observabilité puissante.

Par exemple, en utilisant des uprobes, on peut se connecter à une fonction spécifique dans une application sans modifier le code de l'application, au moment de l'exécution . Chaque fois que la fonction est exécutée, un programme eBPF peut être déclenché pour capturer les données requises. Cela permet des possibilités intéressantes comme le débogage en direct .

Maintenant que nous savons comment fonctionne l'observabilité avec eBPF, examinons les cas d'utilisation.

Cas d'utilisation de l'observabilité eBPF

eBPF peut être utilisé pour presque tous les cas d'utilisation d'observabilité existants courants, et ouvre en outre de nouvelles possibilités.

1. Surveillance du système et de l'infrastructure : eBPF permet une surveillance approfondie des événements au niveau du système, tels que l'utilisation du processeur, l'allocation de mémoire, les E/S de disque et le trafic réseau. Par exemple, LinkedIn utilise eBPF pour toute sa surveillance d'infra .

   
   

2. Surveillance des conteneurs et de Kubernetes : visibilité sur les métriques spécifiques à Kubernetes, l'utilisation des ressources et la santé des conteneurs et des pods individuels.

   
   

3. Surveillance des performances des applications (APM) : observabilité fine des applications de l'espace utilisateur et visibilité sur le débit des applications, les taux d'erreur, la latence et les traces.

   
   

4. Observabilité personnalisée : visibilité sur les métriques personnalisées spécifiques aux applications ou à l'infra qui peuvent ne pas être facilement disponibles sans l'écriture de code personnalisé.

   
   

5. Observabilité avancée : eBPF peut être utilisé pour des cas d'utilisation d'observabilité avancée tels que le débogage en direct , le profilage d'application à faible surcharge et le traçage des appels système .

   
   

De nouvelles applications d'eBPF dans l'observabilité émergent chaque jour.

Qu'est-ce que cela signifie pour la façon dont l'observabilité est réalisée aujourd'hui ? L'eBPF est-il susceptible de remplacer les formes d'instrumentation existantes ? Comparons avec les options existantes.

eBPF vs méthodes d'instrumentation existantes

Aujourd'hui, il existe deux façons principales d'instrumenter les applications et l'infrastructure pour l'observabilité, en dehors de l'eBPF.

1. Instrumentation basée sur des agents : SDK/bibliothèques logicielles indépendantes intégrées dans le code d'application ou les nœuds d'infrastructure pour collecter les données de télémétrie.

1. Instrumentation basée sur un proxy side-car : les side-cars sont des processus légers et indépendants qui s'exécutent parallèlement à une application ou à un service. Ils sont populaires dans les microservices et les architectures basées sur des conteneurs telles que Kubernetes.

   
   

Pour une comparaison détaillée de la façon dont l'instrumentation basée sur eBPF se compare aux agents et aux side-cars, voir ici . Ci-dessous une vue récapitulative -

Comme nous pouvons le voir, eBPF surpasse les méthodes d'instrumentation existantes sur presque tous les paramètres. Il y a plusieurs avantages -

1. Peut tout couvrir en une seule fois (infrastructure, applications)

2. Moins intrusif - eBPF n'est pas en ligne avec les charges de travail en cours d'exécution comme les agents de code, qui s'exécutent à chaque exécution de la charge de travail. La collecte de données est hors bande et en bac à sable, il n'y a donc aucun impact sur un système en cours d'exécution.

3. Faible surcharge de performances - eBPF s'exécute en tant que code machine natif et il n'y a pas de changement de contexte.

4. Plus sécurisé - grâce à des mesures de sécurité intégrées telles que la vérification.

5. Facile à installer - peut être inséré sans aucun changement de code ni redémarrage.

6. Facile à entretenir et à mettre à jour - encore une fois, aucun changement de code et redémarrage.

7. Plus évolutif - entraîné par une mise en œuvre et une maintenance faciles et une faible surcharge de performances

   
   

En termes d'inconvénients, la principale lacune avec l'observabilité eBPF aujourd'hui réside dans le traçage distribué ( réalisable , mais le cas d'utilisation en est encore à ses débuts).

Dans l'ensemble, compte tenu des avantages significatifs offerts par eBPF par rapport aux méthodes d'instrumentation existantes, nous pouvons raisonnablement nous attendre à ce qu'eBPF devienne la plate-forme d'instrumentation de nouvelle génération par défaut.

Implications pour l'observabilité

Qu'est-ce que cela signifie pour l'industrie de l'observabilité ? Quels changements ?

Imaginez une solution d'observabilité :

• que vous pouvez déposer dans le noyau en 5 minutes

• pas de changement de code ni de redémarrage

• couvre tout en une seule fois - infrastructure, applications, tout

• a des frais généraux presque nuls

• est hautement sécurisé

  
  

C'est ce qu'eBPF rend possible. Et c'est la raison pour laquelle il y a tant d'enthousiasme autour de la technologie.

Nous pouvons nous attendre à ce que la prochaine génération de solutions d'observabilité soit instrumentée avec eBPF au lieu d'agents de code.

Des acteurs traditionnels comme Datadog et NewRelic investissent déjà dans la construction d'une instrumentation basée sur eBPF pour augmenter leur portefeuille d'agents basés sur du code. Pendant ce temps, il existe plusieurs fournisseurs de nouvelle génération basés sur eBPF, résolvant à la fois des cas d'utilisation de niche et pour une observabilité complexe .

Alors que les acteurs traditionnels devaient construire des agents de code individuels langage par langage et pour chaque composant de l'infrastructure sur plusieurs années, les nouveaux acteurs peuvent atteindre le même degré de couverture en quelques mois avec eBPF. Cela leur permet également de se concentrer sur l'innovation plus haut dans la chaîne de valeur, comme le traitement des données, l'expérience utilisateur et même l'IA . De plus, leurs couches de traitement des données et d'expérience utilisateur sont également conçues pour prendre en charge les nouveaux cas d'utilisation, les volumes et la fréquence.

Tout cela devrait entraîner une grande quantité d'innovations dans cet espace et rendre l'observabilité plus transparente, sécurisée et facile à mettre en œuvre au cours des prochaines années.

Qui devrait utiliser l'observabilité eBPF ?

Premièrement, si vous êtes dans un environnement cloud natif moderne (Kubernetes, microservices), les différences entre les approches basées sur eBPF et basées sur des agents sont les plus visibles (surcharge de performances, sécurité, facilité d'installation, etc.).

Deuxièmement, si vous opérez à grande échelle, les agents légers basés sur eBPF entraîneront des améliorations spectaculaires par rapport au statu quo. C'est probablement l'une des raisons pour lesquelles l'adoption d'eBPF a été la plus élevée dans les entreprises technologiques avec des empreintes massives comme LinkedIn, Netflix et Meta.

Troisièmement, si vous manquez de technologie. capacité et recherchez une solution d'observabilité qui ne nécessite presque aucun effort d'installation et de maintenance, alors optez directement pour une solution basée sur eBPF.

Résumé

En résumé, en offrant un mécanisme d'instrumentation nettement meilleur, eBPF a le potentiel de remodeler fondamentalement notre approche de l'observabilité dans les années à venir.

Alors que dans cet article, nous avons principalement exploré l'application d'eBPF dans la collecte / l'instrumentation de données, les applications futures pourraient voir eBPF utilisé dans le traitement des données ou même dans les couches de stockage de données. Les possibilités sont vastes et encore inexplorées.

Les références

1. https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html
2. https://ebpf.io/
3. https://ebpf.io/summit-2022.html
4. https://github.com/microsoft/ebpf-for-windows
5. https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf

Également publié ici.