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 de KubeCon, et gagnent rapidement en popularité, des entreprises comme Google et Netflix 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. pilier les journées eBPF les sommets eBPF utilisent eBPF 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 ? https://www.youtube.com/watch?v=KhPrMW5Rbbc&embedable=true 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 , 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. 30 millions de lignes de code on pourrait charger des modules du noyau dans son noyau et apporter des modifications directement, mais cela présente un risque élevé et implique une programmation complexe au niveau du noyau, ce qui est presque universellement évité. Techniquement, très eBPF arrive et résout ce problème - et fournit un mécanisme pour attacher et exécuter des programmes dans le noyau. sécurisé et efficace Voyons comment eBPF assure à la fois la sécurité et les performances. Hautement sécurisé - Avant qu'un programme eBPF puisse être chargé dans un noyau, il est vérifié par le , 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. Vérification rigoureuse vérificateur eBPF - 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. Sandbox - 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é. Opérations limitées Haute performance / léger - 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. Exécuter en tant que code machine natif - 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. Pas de changement de contexte - 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. Piloté par les événements - 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. Optimisé pour le matériel 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 , co-créateur de Linux et co-mainteneur d'eBPF, sur l'évolution d'eBPF. cette vidéo d'Alexei Starovoitov eBPF - un bref historique 1993 - Un 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"). article 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 l'extension des fonctionnalités du noyau. facilitait 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. , qui l'a mis en œuvre, est devenu largement connu dans les cercles d'infrastructure et d'exploitation en tant qu'autorité sur eBPF. Brendan Gregg 2017 - Facebook a ouvert , leur équilibreur de charge basé sur eBPF. Chaque paquet vers depuis 2017 est passé par eBPF. Katran Facebook.com 2020- Google a intégré eBPF à son offre Kubernetes. eBPF alimente désormais la de GKE. À l'heure actuelle, les entreprises comme et sont également largement adoptées. couche de mise en réseau, de sécurité et d'observabilité Capital One Adobe 2021 - Facebook, Google, Netflix, Microsoft et Isovalent se sont réunis pour annoncer la pour gérer la croissance de la technologie eBPF. fondation 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 - La mise en réseau Sécurité 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 . En comparaison, les offres d'observabilité basées sur eBPF sont plus précoces dans leur évolution et ne font que commencer. Cilum 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 - utilise eBPF pour la détection d'intrusion à grande échelle Google utilise eBPF pour mettre en œuvre la sécurité des conteneurs Shopify Plusieurs utilisent désormais eBPF pour la collecte et la surveillance des données. offres de sécurité tierces 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). utilise eBPF pour détecter et empêcher les attaques DDoS, en traitant sans affecter les performances du réseau. Cloudflare 10 millions de paquets par seconde basé sur eBPF de Meta effectue l'équilibrage de charge pour l'ensemble de Facebook Katran 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 - - Obtention de données de télémétrie à partir d'applications et d'infrastructures Collecte de données - Filtrage, indexation et calculs sur les données collectées Traitement des données - Stockage à court et à long terme des données Stockage des données - Déterminer comment les données sont consommées par l'utilisateur Couche d'expérience 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) Prédéterminé/Manuel Dynamique Noyau Points de trace du noyau kprobes Espace utilisateur USDT robes Crochets eBPF statiques et dynamiques dans l'espace utilisateur et l'espace noyau - utilisés pour se connecter à des événements prédéfinis par les développeurs du noyau (avec les macros TRACE_EVENT) Points de trace du noyau - utilisé pour se connecter à des points de trace prédéfinis définis par les développeurs dans le code d'application USDT (Kernel Probes) - utilisé pour se connecter dynamiquement à n'importe quelle partie du code du noyau lors de l'exécution Kprobes (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 Uprobes 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, . 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 . au moment de l'exécution 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. 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, . Surveillance du système et de l'infrastructure : LinkedIn utilise eBPF pour toute sa surveillance d'infra visibilité sur les métriques spécifiques à Kubernetes, l'utilisation des ressources et la santé des conteneurs et des pods individuels. Surveillance des conteneurs et de Kubernetes : 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. Surveillance des performances des applications (APM) : 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é. Observabilité personnalisée : eBPF peut être utilisé pour des cas d'utilisation d'observabilité avancée tels que , et . Observabilité avancée : le débogage en direct le profilage d'application à faible surcharge 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. 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. Instrumentation basée sur des agents : : 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. Instrumentation basée sur un proxy side-car 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, . Ci-dessous une vue récapitulative - voir ici eBPF Agents Sidecars 1. Visibilité/Granualité des données (mais quelques lacunes) Élevé Haut Faible 2. Intrusivité (hors bande) Faible (en ligne) Haut (en ligne) Haut 3. Surcoût de performance Faible Moyen Haut 4. Sûreté et sécurité Haut Moyen Moyen 5. Facilité de mise en œuvre Haut Faible Moyen 6. Facilité de maintenance et de mises à jour Haut Faible Moyen 7. Évolutivité Haut Moyen Faible Comme nous pouvons le voir, eBPF surpasse les méthodes d'instrumentation existantes sur presque tous les paramètres. Il y a plusieurs avantages - (infrastructure, applications) Peut tout couvrir en une seule fois - 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. Moins intrusif - eBPF s'exécute en tant que code machine natif et il n'y a pas de changement de contexte. Faible surcharge de performances - grâce à des mesures de sécurité intégrées telles que la vérification. Plus sécurisé - peut être inséré sans aucun changement de code ni redémarrage. Facile à installer - encore une fois, aucun changement de code et redémarrage. Facile à entretenir et à mettre à jour - entraîné par une mise en œuvre et une maintenance faciles et une faible surcharge de performances Plus évolutif En termes d'inconvénients, la principale lacune avec l'observabilité eBPF aujourd'hui réside dans le traçage distribué ( , mais le cas d'utilisation en est encore à ses débuts). réalisable 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 et pour . des cas d'utilisation de niche 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 . 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. l'IA 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 https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html https://ebpf.io/ https://ebpf.io/summit-2022.html https://github.com/microsoft/ebpf-for-windows https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf Également publié ici.
