bpftool – Initiation à l'analyse moderne du noyau avec eBPF

Je vais te montrer comment utiliser bpftool tu puisses analyser de manière ciblée des systèmes Linux en cours de fonctionnement, contrôler des programmes eBPF et obtenir ainsi des données de télémétrie pertinentes sans avoir à recompiler le noyau. Cet article te guide pas à pas à travers l'installation, les concepts fondamentaux, les cas d'utilisation typiques et les routines utiles, afin que tu puisses Analyse du noyau qu'il utilise en toute sécurité dans le cadre de l'exploitation et du développement.

Points centraux

Pour commencer, je vais résumer les points essentiels afin que tu puisses mieux situer les chapitres suivants et Priorités peux définir.

• proximité du cœur: Accès direct aux programmes eBPF, aux cartes et aux statistiques
• Transparence: journaux du vérificateur, bytecode et vidages JIT pour le dépannage
• prêt pour la production: Sorties JSON, possibilité de créer des scripts, processus reproductibles
• Largeur: Réseau, appels système, planificateur, cgroups, perf_events
• Écosystème: Complète des outils de haut niveau tels que BCC et bpftrace

Je m'appuie sur les points mentionnés pour présenter des étapes concrètes et Décisions pour faciliter la tâche. Tu pourras ainsi identifier rapidement les cas où bpftool apporte un avantage direct et ceux où d'autres outils sont plus adaptés. Cette liste sert de fil conducteur pour les exemples présentés dans les chapitres suivants et met l'accent sur Mesurabilité. Pendant votre lecture, gardez à l'esprit votre système cible, car la configuration et la version du noyau déterminent les options disponibles. Plus vous définirez clairement votre objectif, plus eBPF et bpftool vous fourniront rapidement des résultats Signal au lieu du bruit.

eBPF en tant qu'environnement d'exécution sécurisé dans le noyau

eBPF offre un environnement d'exécution sécurisé dans le Noyau prêt à associer les petits programmes à des événements définis et à les vérifier rigoureusement avant leur exécution. Le vérificateur empêche les accès mémoire non autorisés et les boucles, ce qui permet de garder le contrôle des systèmes et opérationnel. J'associe des programmes à Kprobes, Tracepoints, XDP ou cgroups et j'obtiens des données de contexte précises. Cette proximité permet d'obtenir des mesures sans passer par des appels système coûteux et sans avoir à créer de modules. Il en résulte une couche de télémétrie flexible que j'utilise avec bpftool rendre visible, vérifiable et contrôlable.

Installation et conditions préalables

Je commence par vérifier la version du noyau et ses fonctionnalités, car de nombreuses fonctionnalités ne sont disponibles qu'à partir de 5.x complètement. Sur les distributions, j'installe bpftool sous forme de paquet ou je le compile à partir des sources du noyau dans le répertoire tools/bpf/bpftool, selon l'état de maintenance du système. Pour la compilation, j'ai besoin de Clang/LLVM, de libelf, de make ainsi que des en-têtes appropriés, afin que la chaîne d'outils soit compatible avec le noyau s'adapte. Une fois l'installation terminée, je vérifie la disponibilité à l'aide de la commande “ bpftool version ” et je la compare à mes besoins. Si les capacités du noyau sont conformes, je lance des tests sur un système distinct avant de passer aux hôtes de production suivre.

bpffs et Pinning : aperçu du cycle de vie des objets

Pour garantir la reproductibilité des opérations, je monte d’abord le système de fichiers BPF sous “ /sys/fs/bpf ”. S’il n’existe pas, je le crée à l’aide de la commande “ mount -t bpf bpf /sys/fs/bpf ” et je vérifie les espaces de noms lorsque des conteneurs sont impliqués. Ensuite, j’épingle les objets chargés à des chemins stables, par exemple “ bpftool prog pin id X /sys/fs/bpf/myapp/xdp_ingress ” ou “ bpftool map pin id M /sys/fs/bpf/myapp/counters ”. Ainsi, les programmes, les liens et les cartes survivent aux redémarrages du processus, restent localisables et sont uniques. adressable.

Je structure la hiérarchie des épinglages par service, hook et version, par exemple “ /sys/fs/bpf/ »service/hook/version”. Cela facilite les retours en arrière et les tests en parallèle. Pour les pièces jointes, je préfère l'approche par lien : “bpftool link list ” m’affiche des descripteurs stables, “ bpftool link pin id L /sys/fs/bpf/myapp/link_xdp ” enregistre le lien. Lors du nettoyage, je supprime d’abord les broches (rm), ce qui libère ensuite les objets. J’évite ainsi orphelins- des programmes qui continuent de s'exécuter à l'insu de l'utilisateur.

Sous-commandements centraux et concepts

bpftool classe les commandes par type d'objet, par exemple prog, map, cgroup ou feature, ce qui permet d’organiser les workflows de manière logique. J’utilise “ prog list ” et “ prog show ” pour avoir une vue d’ensemble, “ dump xlated/jited ” pour obtenir des informations détaillées et “ map dump/lookup ” pour analyser les flux de données. La sous-commande “ feature ” affiche les types d’assistants et de cartes activés, ce qui permet d’éviter des erreurs ultérieures. Les sorties au format JSON facilitent l’automatisation dans le cadre du CI/CD et de la gestion de la configuration. Le tableau suivant résume les tâches typiques et fournit des exemples compact ensemble.

Objet	Tâche	Exemple
prog	Répertorier et décrire les programmes	bpftool prog list | bpftool prog show id X
prog	Afficher le bytecode/JIT	bpftool prog dump xlated id X | dump jited id X
prog	Charger et joindre	bpftool prog load file.o /sys/fs/bpf/p && … attach
map	Vérifier le contenu et les clés	bpftool map dump id M | map lookup id M key HEX
fonctionnalité	Afficher les capacités du noyau	bpftool : analyse des fonctionnalités

BTF, CO-RE et Skeletons au quotidien

Je veille à ce que BTF soit disponible dans le noyau, car cela permet le CO-RE (Compile Once – Run Everywhere) et offre des sorties de débogage pratiques. Avec “ bpftool feature probe ”, je vérifie si BTF est actif et, si nécessaire, j’inspecte les informations de type à l’aide de “ bpftool btf dump file /sys/kernel/btf/vmlinux ”. Pour le développement, je génère un fichier d’en-tête adapté à partir des types du noyau à l’aide de “ bpftool gen vmlinux ”, ce qui me permet de référencer les structures en toute sécurité. Cela réduit considérablement les points de rupture lors des mises à jour du noyau.

Pour le packaging, je mise sur les “ skeletons ” : « bpftool gen skeleton obj.o » génère un wrapper en C qui encapsule le chargement, l'ajout, les accès à la table de hachage et les opérations de nettoyage. Cela me permet de réduire mon code de liaison et de maintenir l'interaction entre l'espace utilisateur et le programme eBPF robuste. CO-RE me permet d'utiliser les mêmes artefacts sur différents noyaux, à condition que les helpers et les hooks soient disponibles – je vérifie cela dès le début à l'aide de “ feature probe ”.

Analyse des performances avec bpftool

Pour les questions de performances, j'utilise bpftool pour compter le appels Je mesure les durées d'exécution de chaque programme et je les compare aux pics de charge. Cela me permet d'identifier les traces qui s'exécutent très rapidement ou de déterminer si un filtre XDP monopolise trop de ressources CPU sur des chemins très sollicités. J’évalue ensuite s’il est plus judicieux d’opter pour un échantillonnage ou pour des filtres plus restrictifs. En cas d’anomalies, j’examine les vidages JIT afin de comprendre les chemins d’exécution et d’éviter les instructions superflues. Au final, ces chiffres sont intégrés dans des tableaux de bord afin que les opérateurs puissent bénéficier d’une Transparence conserver.

Valeurs de comptage, cartes par processeur et statistiques

J'analyse la commande “ bpftool prog show id X ” pour vérifier les valeurs “ run_time_ns ” et “ run_cnt ”. Leur rapport m'indique les durées d'exécution moyennes ; j'interprète les valeurs aberrantes à l'aide des métriques de charge de travail. En ce qui concerne les compteurs de map, je prête attention aux variantes par CPU : certains dumps affichent des valeurs par CPU, d’autres les agrègent. Pour des analyses précises, j’utilise des sorties lisibles par machine et je calcule délibérément les agrégations afin que les pics sur certains CPU ne s'enfoncer.

Pour obtenir un aperçu rapide des sorties de trace, j'utilise la commande “ bpftool prog tracelog ”. Cela me permet de lire les sorties d'impression à partir du tampon de trace sans avoir à recourir à des outils distincts. Dans les environnements de production, je limite fortement ce type de sorties et je les remplace par des compteurs dans des maps ou des événements de tampon circulaire, afin d’éviter toute surcharge et tout bruit.

Observabilité du réseau : paquets, flux, erreurs

Dans l'environnement réseau, je vérifie les programmes XDP et TC, je lis les fichiers Maps contenant les relevés de compteurs et j'identifie Points chauds le long des chemins de données. J'utilise bpftool pour mettre en évidence les règles ignorées et caractériser les flux. En cas d'erreurs de filtrage, les « map-dumps » révèlent les clés et les valeurs réelles. Cela me permet de repérer rapidement les écarts entre le traitement attendu et le traitement réel. Cet aperçu m'aide à affiner le choix des outils pour Outils d'analyse eBPF, qui est utilisé dans le domaine de l'hébergement concrètement classe.

Variantes XDP/TC et visibilité avec bpftool net

Pour le chemin réseau, j'utilise la commande “ bpftool net ” afin de vérifier les programmes associés aux interfaces. Cela me permet de déterminer si XDP fonctionne en mode générique, natif ou offload, et de savoir quels hooks TC (ingress/egress) sont occupés. Si les modes ne correspondent pas, je corrige les options d’attachement ou les paramètres du pilote. Je documente régulièrement les résultats sous forme d’artefact afin que les modifications apportées aux chemins réseau compréhensible rester.

Pour les hotpaths, je privilégie les chemins courts : les programmes XDP doivent prendre des décisions rapidement (pass/drop/redirect), tandis que les programmes TC consolident les règles et évitent les recherches redondantes. J'évalue la qualité des résultats à l'aide des statistiques de carte, et les vidages JIT me permettent de déterminer si les schémas de saut sont défavorables. Si des coûts liés à la mise en file d'attente ou aux sommes de contrôle apparaissent, j'ajuste les filtres et je réexamine leur emplacement entre XDP et TC.

Contrôle de sécurité et conformité

J'utilise des programmes eBPF pour Processus- Les démarrages, les accès aux fichiers et les événements réseau, afin d'identifier des schémas pertinents en matière de sécurité. À l'aide de bpftool, je vérifie quels programmes sont actifs, où ils s'ancrent et si les règles s'appliquent. Si les points d'ancrage sont corrects, je contrôle le contenu des cartes afin de documenter de manière détaillée les politiques mises en œuvre. En cas de soupçons, je me réfère aux journaux de Verifier et au bytecode pour vérifier la logique. Cette visibilité accélère les audits et rend le comportement des agents plus compréhensible pour les équipes compréhensible.

Autorisations, isolation et modèles de sécurité

En production, je veille à ce que les autorisations soient clairement définies. Sur de nombreux systèmes, les fonctions eBPF non privilégiées sont désactivées ; je prévois donc d'utiliser des comptes de service dédiés et des capacités spécifiques. Selon la version du noyau, j’utilise CAP_BPF, CAP_PERFMON et CAP_NET_ADMIN, tandis que CAP_SYS_ADMIN n’est utilisé que lorsque cela est inévitable. J'isole les bpffs par espaces de noms lorsque les conteneurs ont besoin de leurs propres traces, et je délimite les cgroups de manière à ce que les attaches ciblé agissent.

Pour des raisons de conformité, je “ gèle ” les cartes sensibles après les avoir remplies à l’aide de la commande « bpftool map freeze ». Cela rend les règles en lecture seule, tout en permettant aux programmes de continuer à les lire. Lors des audits, je documente la date du programme et les points d’attache, afin que les décisions restent reproductibles, même si les artefacts sont reconstruits.

Programmes eBPF personnalisés : chargement, ajout, débogage

Lors du développement, je compile les fichiers source C avec Clang pour obtenir des objets eBPF, je les charge avec bpftool et je les connecte à Crochets. Si le vérificateur signale une anomalie, j'enregistre le journal et j'élimine progressivement les chemins à risque. Je vérifie le bytecode compilé et la sortie JIT afin d’évaluer les séquences d’instructions. Si les résultats sont corrects, j’écris et je lis des données de test via des tables de correspondance et je vérifie les cas limites. Cela raccourcit les boucles de rétroaction et maintient ma chaîne d’outils à jour, tant pour les expérimentations que pour la production. uniforme.

Stratégie CO-RE et artefacts stables

Pour que les builds durent plus longtemps, je mise sur CO-RE. J’intègre les informations BTF, j’utilise “ gen vmlinux ” et je vérifie les relocalisations pendant le chargement. Si des écarts apparaissent dans les structures du noyau, le journal du vérificateur permet d’identifier les emplacements concernés. Je conçois les programmes de manière aussi générique que possible et j’externe les politiques dans des tables de correspondance. L’avantage : en cas de modifications du schéma, je ne mets à jour que les données, et non le Code. Grâce aux Skeletons, j'automatise la configuration, le pinning et le nettoyage, ce qui réduit considérablement le taux d'erreurs, notamment dans les pipelines CI/CD.

Intégration avec des outils de haut niveau

Pour obtenir des résultats rapides, je mise d'abord sur BCC-Je crée des scripts et je m'en sers comme point de départ pour des analyses plus approfondies. Dès qu'un script fournit des signaux utiles, j'utilise bpftool pour inspecter les programmes et les cartes sous-jacents. Cette approche me permet de voir ce qui est réellement chargé dans le noyau et quelles structures de données sont en cours d'exécution. Cela me permet de distinguer clairement la couche de confort des objets réels. Pour avoir une vue d’ensemble, il est utile de jeter un œil à ces Outils BCC, qui répond aux questions fréquentes en quelques commandes couvrir.

Meilleures pratiques pour l'exploitation

Je sépare rigoureusement les environnements de test et de production, je collecte les journaux de Verifier dès que possible et je veille à ce que Rollbacks Prêt. Avant chaque déploiement, je vérifie “ bpftool feature ” afin de m’assurer que le type de programme, l’assistant et les variantes de mappage correspondent à l’objectif. J’intègre les statistiques des programmes dans le système de surveillance existant afin de garder une vue d’ensemble de la surcharge. Je documente en continu tous les points d’accrochage, car c’est le seul moyen pour les équipes de garder une vue d’ensemble. Si vous souhaitez approfondir le sujet, vous trouverez dans les Outils d'analyse eBPF de nouvelles impulsions pour Flux de travail.

Gestion des ressources, nettoyage et restauration

J'utilise des “ pins ” pour créer des états définis, et je les supprime activement. Pour les retours en arrière, je conserve la version précédente dans le même espace de noms (par exemple “ /sys/fs/bpf/myapp/v1 ” et « /sys/fs/bpf/myapp/v2 »). Le basculement s'effectue par un nouvel attach ou un changement de lien, avec un temps d'indisponibilité minimal. Je supprime ensuite les anciens liens et mappages afin qu'aucune ressource lécher. Avant de supprimer, je vérifie s'il existe encore des références (“ prog show ”, “ link list ”, “ map show ”).

Pour éviter toute dérive de configuration, je “ gèle ” les cartes contenant des politiques et n’apporte des modifications qu’au moyen de déploiements définis. Je planifie les mises à jour par lots en dehors des pics de charge, je surveille la durée d’exécution et le compteur d’erreurs, et je vérifie que les mises à jour ont bien abouti à l’aide d’un deuxième « map dump ».

Automatisation et sorties JSON

Le drapeau JSON et les formats lisibles par machine font la force de bpftool programmable pour le CI/CD, les CMDB et les audits. Je scelle les builds de manière reproductible, je documente les hachages des fichiers objets et j'enregistre les chemins d'accès aux fichiers bpffs. Je relie ainsi les déploiements à des programmes et des cartes spécifiques. De simples scripts wrapper enregistrent des rapports d'état après chaque modification sur la console et dans les artefacts. Cela permet de maintenir l'environnement eBPF à jour en permanence vérifiable.

Instaurer la confiance : balises, hachages et artefacts

Une fois le chargement terminé, je lis la balise du programme (“ bpftool prog show id X ”), qui est dérivée du bytecode. Je relie cette balise au numéro de build et au hachage de commit dans ma CMDB. Lors de vérifications ultérieures, je compare la balise attendue et la balise actuelle ; cela me permet de détecter les écarts sans avoir à accéder aux binaires d'origine. Pour les tables, j'enregistre le type, les tailles des clés et des valeurs ainsi que les indicateurs, afin de pouvoir repérer les modifications de structure lors des mises à jour en temps utile montrer.

bpftrace en pratique

Pour les traces ad hoc, j'utilise bpftrace, lorsque quelques lignes de syntaxe doivent fournir rapidement des réponses. Je vérifie ensuite le résultat obtenu à l'aide de bpftool afin de visualiser précisément les programmes, les points d'attache et les mappages. Je combine ainsi la puissance d'expression et la proximité du cœur du système, tout en synchronisant ces deux perspectives. Pour commencer, voici un bref aperçu de bpftrace, qui gère bien les requêtes courantes encadre. Dès qu'un modèle est au point, je le transpose, si nécessaire, en programmes C compacts.

Analyse des erreurs à l'aide des journaux de Verifier

En cas de refus de la part du vérificateur, je commence par rechercher des Zéro- les déréférencements, les vérifications de limites manquantes ou les chemins trop longs. Je simplifie la logique, j'isole les appels de fonctions auxiliaires suspects et je valide les décalages. Il est utile de réduire la taille des grandes cartes et de diviser les chemins fréquents en blocs clairement délimités. Les vidages JIT me permettent de voir si des boucles s’étendent de manière indésirable ou si des sauts s’avèrent inefficaces. À chaque étape, les messages d’erreur diminuent, jusqu’à ce que le programme fonctionne de manière fiable invite.

Identifier rapidement les défauts typiques

Lorsque je vois des messages tels que “ invalid mem access ” ou “ R.. unbounded loop ”, je vérifie les limites des tableaux, la validité des pointeurs et les limites des boucles. En cas de problèmes CO-RE, les messages indiquent souvent des données BTF manquantes ou inadaptées ; je vérifie alors “ /sys/kernel/btf/vmlinux ” et j'ajuste les structures cibles. Si le chargement échoue en raison de l’absence d’assistants, la commande “ feature probe ” affiche les assistants et les types de mappage disponibles. Si des problèmes JIT surviennent lors de la création d’un dump, je vérifie si le JIT est activé et si les options de renforcement de la sécurité affectent la sortie empêcher.

Lorsque des pièces jointes se bloquent, cela est souvent dû à un lien encore épinglé. Je répertorie les liens, je les débloque de manière ciblée, puis je supprime les épingles. En cas d“” EBUSY », je vérifie si une autre instance du service maintient des objets ouverts et je planifie une bascule rapide et coordonnée.

Perspectives : bpftool et l'analyse moderne du noyau

À chaque nouvelle version du noyau, le nombre de types de programmes, d'assistants et Statistiques, et bpftool reflète rapidement ces avancées. Je prévois donc du temps pour des mises à jour régulières, afin que les outils et la documentation restent à jour. Les améliorations apportées au format JSON et les nouvelles sous-commandes ouvrent de nouvelles voies d'automatisation. Parallèlement, l’interaction avec les piles de haut niveau gagne en maturité, ce qui simplifie la mise en route. Ceux qui suivent activement cette évolution y gagnent en termes de diagnostic, d’optimisation et Sécurité Vitesse.

En bref

bpftool me donne directement Accès sur les programmes eBPF et leurs structures de données, et rend visibles les processus au sein du noyau. Je détecte les goulots d'étranglement, je vérifie les règles de sécurité et je développe mes propres traces sans avoir à modifier le noyau. Grâce à une installation soignée, des tests clairs et des scripts, l'utilisation reste reproductible. Les outils de haut niveau accélèrent la prise en main, tandis que bpftool documente de manière fiable les objets réels. Je porte ainsi l'observabilité et le diagnostic à un niveau robuste, indispensable dans l'exploitation quotidienne porte.