Les outils bcc en action : guide pratique pour l'ingénierie des performances sous Linux avec eBPF

Je vais vous expliquer étape par étape comment je outils bcc J'utilise eBPF pour identifier et résoudre rapidement les goulots d'étranglement sur les serveurs Linux. Pour ce faire, j'utilise des workflows pratiques, je mesure les latences réelles au niveau du noyau et je relie les événements liés au CPU, aux E/S et au réseau pour obtenir une clair Analyse des causes.

Points centraux

• eBPF offre un traçage approfondi avec une surcharge réduite.
• outils bcc couvrent le processeur, les E/S, le réseau et les processus.
• Proche de la production utilisable sans modification de l'application.
• Liste de contrôle avec dix outils pour démarrer.
• Sécurité grâce à Verifier et à des règles claires.

Pourquoi utiliser eBPF pour l'ingénierie des performances sous Linux ?

Je me tourne vers eBPF, car je souhaite mesurer les événements du noyau de manière fiable, sélective et avec très peu de surcharge. Les outils classiques affichent des totaux, mais ils expliquent rarement pourquoi les threads sont en attente, pourquoi des paquets sont renvoyés ou pourquoi les E/S sont bloquées ; eBPF comble cette lacune grâce à concrètes Événements. Les programmes s'exécutent dans le noyau, le vérificateur les contrôle au préalable, et je peux les lancer sans redémarrer. Je peux ainsi établir une corrélation entre les appels de l'espace utilisateur et les chemins d'accès du noyau, ce qui me donne une vue d'ensemble permettant des optimisations immédiates. Si vous souhaitez approfondir le sujet, vous trouverez un aperçu dans ma brève introduction à la Analyse des performances eBPF, qui décrit l'interaction entre le traçage et l'observabilité.

Que sont les outils BCC et où puis-je les trouver ?

Le bcc Les outils « tools » sont des programmes de diagnostic prêts à l'emploi basés sur eBPF et se trouvent généralement dans le répertoire /usr/share/bcc/tools. Je les lance directement depuis le shell, j'obtiens des sorties standard claires et je n'ai pas besoin de modifier mes applications. Cette collection couvre les processus, les appels système, les systèmes de fichiers, les E/S par blocs, le réseau, les planificateurs et le profilage, et convient donc pour productif Analyses. Comme j'active le traçage de manière ciblée, son impact reste faible et les erreurs de mesure dues à la surveillance sont minimes. Pour les cas plus complexes, je complète les outils avec mon propre eBPF ou j'utilise en plus des profils d'échantillonnage.

Installation et conditions préalables

J'installe le bcc outils disponibles via le gestionnaire de paquets (bcc-tools ou bpfcc-tools) sur les distributions courantes. Il faut disposer d'un noyau prenant en charge eBPF (à partir de la version 4.x, de préférence 4.9+), des fonctions BPF activées et des droits suffisants pour charger les programmes. Sur les serveurs de production, je vérifie au préalable les capacités eBPF du noyau et de la distribution dans un environnement de test, afin que les mesures ultérieures fiable fonctionnent. Je bloque les profils de sécurité qui désactivent complètement l'eBPF grâce à des politiques adaptées. Les notes succinctes sur ce sujet fournissent un aperçu pratique de la configuration et de l'utilisation de outils d'analyse eBPF.

Avant le départ : vérifications du système et de la sécurité

Avant d'effectuer des mesures en production, je vérifie les capacités de base de l'hôte. Cela me permet d'éviter les faux départs et d'obtenir des résultats reproductibles.

• Vérifier les fonctionnalités du noyau : uname -r et les fonctions BPF disponibles (par exemple via Feature-Check). Les éléments importants sont les kprobes/tracepoints, le BTF (pour des informations de type stables) et les événements perf.
• Droits et politiques : je m'assure que seuls les utilisateurs autorisés peuvent charger eBPF (CAP_BPF/CAP_SYS_ADMIN ou politique équivalente) et que les profils LSM ne bloquent pas ce chargement.
• Paramètres système : kernel.unprivileged_bpf_disabled est généralement actif dans les environnements de production. C'est pourquoi je travaille délibérément à partir de sessions sécurisées et avec un suivi rigoureux.
• Chemins d'accès transparents : je conserve les répertoires tels que /sys/kernel/debug/tracing et /sys/fs/bpf à l'œil, afin d'éliminer les artefacts après les mesures.

Cette rigueur me permet d'effectuer des mesures de manière ciblée et reproductible, sans effets secondaires.

Guide pratique : les dix premiers outils

Pour effectuer un contrôle rapide des performances, je suis une procédure bien définie. Cela me permet d’identifier clairement les causes liées au processeur, aux E/S ou au réseau, et de décider s’il faut examiner plus en détail les piles d’appels ou les temps de réponse. Le tableau présente la fonction principale de chaque outil et la question à laquelle il permet de répondre. Je limite d’abord la durée d’exécution et je répète les mesures dès que j’ai un soupçon confirment Je veux. C'est ainsi que j'évite les angles morts et que je ne perds pas de temps en cas d'urgence Incidents.

Outil	Observé	Question typique
execsnoop	Nouveaux processus	Qui crée des emplois éphémères qui génèrent une charge de travail ?
opensnoop	Ouverture de fichiers	Quels chemins d'accès sont constamment ouverts ou enregistrés ?
ext4 plus lent (xfs*, btrfs*, zfs*)	Opérations FS lentes	Quelles requêtes présentent des latences élevées par volume ?
biolatency	Répartition des E/S par blocs	Y a-t-il des pics de latence sporadiques ou persistants ?
biosnoop	Demandes d'E/S individuelles	Quel processus met certains appareils à genoux ?
cachestat	Comportement du cache de page	Est-il intéressant d'augmenter la mémoire vive ou l'application présente-t-elle des dysfonctionnements ?
tcpconnect	Nouvelles connexions TCP	Qui utilise quel service et à quelle fréquence ?
tcpaccept	Liens acceptés	Quels sockets serveur sont soumis à une charge importante ?
tcpretrans	Rediffusions	La perte de paquets est-elle le signe de chemins instables ?
runqlat	Latences du planificateur	Les threads attendent-ils trop longtemps pour obtenir du temps CPU ?

En outre, je mets en place profils pour détecter les points chauds dans l'espace utilisateur ou dans l'espace noyau, et pour agréger les piles d'appels. Cela me permet de repérer les expressions régulières coûteuses, les pilotes inefficaces ou les spinlocks, que je corrige ensuite dans le code ou dans la configuration. J’utilise des intervalles d’échantillonnage courts et je compare plusieurs exécutions afin d’éliminer les valeurs aberrantes visible . Ce mélange entre vue d'ensemble et analyse approfondie me fait gagner beaucoup de temps. Je teste ensuite à nouveau l'optimisation sous la même charge.

Extension : afficher les opérations hors CPU, les verrous et les temps d'attente

Toutes les latences élevées ne sont pas liées au processeur. Souvent, les threads „ hors processeur “ attendent des opérations d'E/S, des verrous ou des réveils. C'est là que les outils et profils bcc complémentaires s'avèrent utiles :

• Analyse hors CPU : je mesure la durée pendant laquelle les threads ne sont pas sur le CPU et les piles qui y mènent. Cela permet de distinguer le temps de calcul du temps d'attente et de mettre en évidence les éléments qui provoquent des blocages.
• Conflits d'accès aux verrous : j'examine de manière ciblée les verrous critiques du noyau et de l'espace utilisateur. Des temps d'attente prolongés ou des conflits d'accès élevés indiquent la présence de points de sérialisation que je m'efforce de supprimer (par exemple, par le partitionnement, une granularité plus fine ou d'autres structures de données).
• Chemins de réveil : les latences entre „ a été réveillé “ et „ fonctionne à nouveau “ révèlent des problèmes d'ordonnancement et de priorité, ou des pools de workers trop importants.

Je mets ces signaux en corrélation avec runqlat et biolatency, afin de distinguer les causes liées à la mémoire, aux E/S et au planificateur.

Hygiène des mesures : filtres, durée, seuils

Pour que les mesures eBPF restent reproductibles, je m'en tiens à trois règles de base :

• En bref et de manière ciblée : au début, je ne laisse les outils tourner que brièvement (par exemple, 10 à 30 secondes) et je me concentre sur les PID, les conteneurs ou les sockets suspects.
• Définir des seuils : avec les outils „ *slower “, je filtre les petites latences afin de réduire le bruit et de ne voir que les appels problématiques.
• Limiter le débit : j'utilise des filtres sélectifs (par exemple, nom du processus, TID, ports) pour maintenir un faible débit d'événements. Cela permet de réduire au minimum la surcharge et d'éviter les événements perdus.

Ce n'est que lorsque je repère une tendance que je prolonge la durée ou que j'élargis le champ d'application. Cela me permet d'obtenir propre et des échantillons fiables.

Scénario pratique n° 1 : charge CPU anormalement élevée

Si l'indicateur de charge du processeur affiche en permanence des valeurs élevées, je commence par execsnoop, afin d'identifier les processus de courte durée. Ensuite, j’utilise runqlat pour mesurer le temps d’attente des threads en temps CPU et je vérifie si les files d’attente sont surchargées ou si les priorités sont mal définies. Si les temps d’attente deviennent trop importants, je réduis le nombre de travailleurs, je modifie les pools de threads ou j’étale les tâches Cron afin que le planificateur saisissent . Grâce à profile, je collecte des piles d'appels et identifie les véritables points sensibles dans les bibliothèques et dans mon propre code. Ce n'est qu'après avoir croisé ces informations que je prends des décisions concernant les limites, le ramasse-miettes, les affinités ou les options du compilateur.

Scénario pratique n° 2 : latences d'E/S et applications lentes

Si des utilisateurs se plaignent de ralentissements alors que l'utilisation du processeur est faible, je vérifie avec ext4 plus lent Appels lents au système de fichiers par processus. Ensuite, j'utilise biolatency pour examiner la répartition des temps d'E/S par bloc pour chaque périphérique, afin de détecter des pics sporadiques ou des goulots d'étranglement persistants. biosnoop me permet de voir si un service particulier génère un nombre anormalement élevé de petites écritures, provoquant ainsi une mise en file d’attente qui ralentit les autres processus. Avec cachestat, je peux vérifier si le cache de page est efficace ou s’il y a des échecs (misses). dominer et qu'une mémoire vive plus importante serait utile. Au final, c'est moi qui déciderai si les écritures par lots, des tampons plus grands ou le passage à un support de stockage plus rapide s'avèrent rentables.

Scénario pratique n° 3 : chemins réseau et microservices

Dans les environnements distribués, je commence par tcpconnect, afin de mesurer l'établissement des connexions entre les services. Ensuite, j'utilise tcpaccept pour vérifier quels sockets serveur reçoivent un nombre particulièrement élevé de requêtes entrantes et si les limites côté écouteur sont respectées. tcpretrans détecte les retransmissions et permet de distinguer les problèmes de transport des erreurs d’application avant que je n’ajuste les délais d’attente et les tentatives de reconnexion. Grâce à ces trois indicateurs, je peux déterminer si c’est le réseau, l’application ou un service en amont qui est à l’origine de la Latence . Ensuite, j'ajuste les stratégies de backoff, les valeurs de keepalive, les paramètres de l'équilibreur de charge et la taille des tampons.

Sécurité de fonctionnement et fiabilité de l'eBPF

Je télécharge uniquement digne de confiance Je teste d'abord mes propres programmes eBPF sur l'environnement de staging. Le vérificateur du noyau bloque les programmes défectueux, mais je fixe en plus des limites pour les maps et les buffers afin que l'utilisation de la mémoire reste bien maîtrisée. Je conserve les journaux de connexion afin de surveiller le comportement et les effets secondaires, et d’intervenir rapidement si nécessaire. Des politiques définissent qui est autorisé à charger de l’eBPF, afin que le contrôle reste entre les mains de l’équipe de la plateforme et que les exigences de sécurité soient respectées. Ces règles garantissent que le traçage dans les environnements de production fiable reste tel quel et ne réserve aucune surprise.

Environnements conteneurs et Kubernetes

Dans les conteneurs, je distingue systématiquement les problèmes généraux des effets spécifiques aux pods. Pour cela, je filtre les mesures par cgroup, espace de noms ou plage de PID. De nombreux outils bcc permettent de filtrer par nom ou ID de processus ; sinon, j'effectue les mesures sur l'hôte et j'attribue les événements aux charges de travail via les cgroups. Important :

• Espace de noms PID : les PID diffèrent entre l'hôte et le conteneur. Je mappe les identifiants ou j'effectue un filtrage en fonction des noms de processus ou des ports.
• Quotas de ressources : la limitation de la puissance du processeur due aux quotas CFS se traduit par de longs temps d'attente sans que le système ne soit pleinement sollicité. Je le constate via runqlat en combinaison avec des indicateurs de quotas.
• Espaces de noms réseau : pour les analyses de sockets, je veille à utiliser le bon espace de noms. J'effectue mes mesures au niveau de l'interface hôte et j'établis une corrélation avec les adresses IP et les ports des pods.

Ainsi, les résultats des mesures restent fiables, même lorsque de nombreuses charges de travail s'exécutent simultanément.

Intégration dans les piles d'observabilité

Je ne remplace pas mon système de surveillance, je le complète avec eBPF. Les outils bcc m'apportent la profondeur, tandis que les systèmes de métriques, les journaux et l'APM montrent l'étendue ; ensemble, ils donnent une image cohérente. Si nécessaire, je redirige les traces issues de bcc vers des pipelines de journaux, je déclenche des instantanés en cas d'incidents et je documente les résultats au sein de l'équipe. Pour des profils ponctuels, j’utilise l’échantillonnage en complément des chronologies issues des métriques, afin de détecter les anomalies tangible . Ceux qui préfèrent utiliser des scripts en complément trouveront dans bpftrace dans l'hébergement un moyen simple de répondre à des questions ponctuelles à l'aide de mini-scripts.

Les obstacles courants – et comment je les surmonte

• « Noisy Neighbor » : certaines tâches génèrent une charge de courte durée mais intense. execsnoop plus profils Ces modèles permettent de les détecter de manière fiable ; je les limite dans le temps ou je les isole à l'aide de quotas.
• NUMA et affinités : des latences élevées malgré des cœurs disponibles indiquent des accès inter-NUMA. Je vérifie les affinités des processeurs, l'affectation de la mémoire et la répartition des IRQ.
• Points sensibles IRQ/SoftIRQ : la charge réseau peut saturer les noyaux ksoftirqd. Je surveille les retransmissions, je répartis les IRQ via RSS/files d'attente et j'ajuste les RPS/XPS.
• Effets du cache de page : les démarrages à froid semblent plus lents. Je tiens compte des phases de préchauffage et je compare cachestat-Valeurs avant et après la charge.
• Mises à jour du noyau : les Kprobes peuvent changer lors des changements de version. Je préfère utiliser des tracepoints stables, je les teste au préalable et je garde un ensemble minimal à disposition.

Des processus de travail qui ont fait leurs preuves

• Aperçu de l'incident : exécution combinée de 60 à 120 secondes (execsnoop, runqlat, biolatency, tcpretrans, profile). Je me concentre ensuite sur le sous-système qui présente des anomalies.
• Routine de référence : mesures rapides hebdomadaires sur les chemins clés (par exemple, profil de stockage et de réseau). Cela me permet de détecter les écarts à un stade précoce.
• Validation des modifications : avant et après les modifications de configuration, je compare les mêmes points de mesure afin de quantifier l'effet.

Optimisation continue des performances sous Linux

Je considère la performance comme un processus continu, et non comme Action unique. Dans le cadre du CI/CD, j'intègre de brèves vérifications basées sur eBPF afin de détecter rapidement les régressions et de les bloquer avant le déploiement. Pendant les fenêtres de maintenance, je mesure les chemins typiques sous charge, j’établis des références et je documente les plages de latence acceptables. Cela me permet de détecter rapidement les écarts et d’éviter les conjectures lors d’un incident, car je dispose de données de comparaison sont présents. Cette procédure contribue directement à la disponibilité, à la maîtrise des coûts et à l'expérience utilisateur.

Mini-étude de cas : du symptôme à la cause en 12 minutes

Un cluster API signale une augmentation des latences à 99e centile alors que le RPS reste inchangé. Je lance un instantané d'incident : tcpconnect ne présente aucune anomalie lors de l'établissement de la connexion, tcpretrans reste faible – ce n'est sans doute pas le cas du réseau. runqlat fait état de temps d'attente courts mais fréquents ; profils affiche les points d'intérêt sous forme de série JSON. En parallèle, j'observe avec cachestat une chute des taux de réussite du cache pendant les pics. La corrélation suggère la présence de nombreuses petites charges utiles, sérialisées de manière synchrone et écrites immédiatement.

Je vérifie à l'aide de ext4 plus lent, qui montre des fsyncs de plusieurs millisecondes sur le même volume pour le processus API ; biolatency confirme l'existence de pics sporadiques dans la file d'attente sur le périphérique concerné. Mesure corrective : regroupement des écritures, augmentation de la taille du tampon et vidage asynchrone à des points moins sensibles. Après le déploiement, les latences à 99e centile diminuent de 35 %, le taux de réussite du cache se rétablit, et runqlat montre à nouveau des distributions étroites.

Résumé pour la pratique

Avec bcc Grâce à ces outils et à eBPF, je peux rapidement obtenir des informations claires sur l'utilisation du processeur, des E/S et du réseau, sans modifier les applications. La liste comprenant execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans et runqlat constitue un point de départ cohérent. En complément, j’utilise profile pour mettre en évidence les points sensibles et optimiser les chemins d’exécution. Grâce à des politiques, une journalisation et des limites bien définies, l’intervention au niveau du noyau reste en toute sécurité et transparente. Ceux qui appliquent cette méthode de manière cohérente résolvent plus rapidement les problèmes de performance, planifient mieux leurs capacités et réduisent les coûts par demande.