Passer au contenu 
Je vais vous montrer comment bpftrace, dans les environnements Linux, permet de réduire considérablement le temps nécessaire pour identifier la cause d'une erreur, tout en Noyau- permet d'exploiter ces signaux. Au lieu de me livrer à des conjectures, je mesure en temps réel les appels système, les latences d'E/S et les événements réseau dans le eBPF-Contexte – sans interrompre les services.
Points centraux
Les points clés suivants donnent un aperçu rapide des thèmes principaux de cet article.
- Une analyse approfondie dans les appels système, les E/S et le réseau, directement depuis le noyau
- Faible surcoût grâce à des programmes eBPF sécurisés intégrés au noyau
- Ciblage rapide des goulots d'étranglement au niveau des processus, des E/S et des bases de données
- Traçage flexible avec des filtres, des histogrammes et des traces de pile
- Flux de travail au cabinet pour les incidents urgents, en quelques minutes
Pourquoi bpftrace permet de détecter plus rapidement les problèmes liés à l'hébergement
Dans les piles d'hébergement modernes, de nombreux services se font concurrence pour Ressources, alors que les tableaux de bord classiques ne montrent souvent que des valeurs superficielles. Je vais plus en profondeur : bpftrace s'accroche aux appels système, aux points de trace et aux hooks de fonction, et me montre ce qui ralentit réellement le système. Les délais d’attente accompagnés d’une charge CPU peu élevée indiquent souvent des latences d’E/S ou des appels bloquants. C’est précisément là que bpftrace se distingue, avec des comptages, des histogrammes de latence et des traces de pile provenant directement du Noyau. J'attribue ainsi les sources de charge à des processus, des conteneurs ou des requêtes spécifiques, et j'interviens de manière ciblée.
Comment eBPF et bpftrace fonctionnent ensemble
eBPF exécute de petits programmes vérifiés dans le Noyau et fournit des événements de première main. bpftrace compile les scripts à l'exécution en bytecode eBPF et les associe à des sondes, des filtres et des actions. Je choisis par exemple un point de trace pour les lectures de fichiers, je filtre en fonction d’un nom de processus et j’agrège les latences dans un histogramme. Le modèle „ sonde – filtre – action “ reste clair, même lorsque je mesure plusieurs signaux simultanément. Je peux ainsi mettre en place en quelques minutes une observation qui me fournit les informations décisives Indicateurs fournit.
Des répliques percutantes pour les situations d'urgence
En cas d'incident, la rapidité est essentielle. J'utilise des phrases courtes et percutantes qui permettent de mettre en évidence une tendance en quelques secondes. Voici quelques-unes de mes formules d'entrée en matière qui ont fait leurs preuves :
# Compter les accès „ bruyants “ aux fichiers par nom de processus (vider toutes les 5 s)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
# Histogramme de latence pour les lectures de fichiers (par processus)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
Regrouper les retransmissions TCP # à l'aide des piles du noyau
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# Cumuler les durées des SoftIRQ (fenêtre de 10 s)
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
@soft[args->vec] = sum(nsecs - @t[args->vec]);
delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'
# : afficher la charge de la fonction `accept()` sur le serveur de base de données ou le serveur web
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
Grâce à ces „ sondes “, je peux rapidement déterminer si un service ouvre un nombre anormalement élevé de fichiers, si les E/S sont ralenties ou si le réseau est saturé. Ensuite, j'affine les filtres pour PID, noms de processus ou chemins d'accès.
Diagnostic des processus et des ressources sur des serveurs en production
Si un compte ou un conteneur isolé ralentit un serveur partagé, je compte le nombre d'appels système par Processus et identifie les sources „ bruyantes “. Un nombre particulièrement élevé d’appels execve indique un lancement excessif de processus, ce qui trahit par exemple des tâches cron défectueuses. Si un service ouvre d’innombrables fichiers, je le repère immédiatement et je limite l’analyse à certains chemins d’accès à l’aide de filtres. Pour les serveurs web très fréquentés, c’est une mine d’or, car cela me permet d’isoler rapidement les sources de perturbation. Ceux qui souhaitent approfondir leurs connaissances en matière d’outils peuvent consulter des approches complémentaires sur outils d'analyse eBPF et applique ce principe à ses propres serveurs.
Vue des conteneurs et de Kubernetes avec les cgroups
Sur les hôtes multi-locataires ou Kubernetes, j'ai besoin d'une séparation claire entre les locataires. bpftrace m'offre pour cela la cgroup- La perspective comme élément clé :
# Regrouper les appels système par cgroup (conteneur) et nom de processus
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
Cela me permet d'identifier quel conteneur est bruyant sans avoir à collecter manuellement les PID un par un. Pour des analyses plus ciblées, j'applique des filtres supplémentaires :
# Ne prendre en compte que PHP-FPM (par exemple, dans un conteneur d'application)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
Dans Kubernetes, je mesure souvent le Nœud et je regroupe par cgroup. Je consigne l'association entre les identifiants de cgroup et les noms de pods/conteneurs dans mon runbook (kubectl/CRI), afin de pouvoir référencer clairement les résultats de mesure.
Mesurer de manière fiable les latences d'E/S et du système de fichiers
Des pages qui chargent lentement malgré un processeur „ correct “ indiquent souvent que E/S-goulots d'étranglement. Je mesure les opérations de lecture et d'écriture par processus, je recense les chemins lents et je génère des histogrammes de latence. Dans les environnements WordPress, cela me permet de déterminer si ce sont de nombreux petits fichiers PHP ou de gros fichiers multimédias qui freinent le débit. Je décide ensuite s’il faut privilégier la mise en cache, le cache d’opcode PHP ou l’optimisation du système de fichiers. Ceux qui souhaitent approfondir le sujet trouveront des informations complémentaires sur Latences des disques dans le stockage et permet d'ajuster les points de mesure de manière ciblée.
Afficher les temps d'attente hors CPU et de verrouillage
Tous les temps d'attente ne sont pas liés aux E/S : les threads peuvent hors CPU bloquer – par exemple sur des verrous. J'utilise pour cela des événements Futex et Scheduler.
# Temps d'attente Futex (conflit de verrouillage) sous forme d'histogramme
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
@futex[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
Grâce à ces profils, je peux voir si des workers PHP-FPM ou des threads de base de données attendent des verrous. En combinant cela avec les historiques d'E/S, je déconnecte Stockage- de Concurrence-Problèmes.
Afficher les erreurs réseau, les SoftIRQ et les retransmissions
J'attribue souvent les plaintes concernant des délais d'attente sporadiques à Réseau-signaux. Je surveille les retransmissions TCP, les événements RST et les déconnexions directement au niveau du noyau. En complément, je jette un œil aux SoftIRQ, car les files d'attente réseau surchargées y laissent des traces. La combinaison de retransmissions et d’une augmentation des temps de SoftIRQ indique des pertes de paquets, des goulots d’étranglement au niveau des tampons ou des problèmes de qualité de service (QoS). Les articles de fond sur ce sujet constituent un bon complément pour déterminer les causes : SoftIRQ et débit réseau, que j'associe à des mesures bpftrace.
Cas pratique : hébergeur WordPress présentant des erreurs 504 sporadiques dues à des délais d'attente dépassés
Un serveur mutualisé renvoie des erreurs 504, alors que l'utilisation du processeur n'est que de 35%. Voici la procédure que j'ai suivie :
- Hypothèse „ Réseau ou E/S “. Je lance les retransmissions et la mesure du temps des SoftIRQ. Résultat : peu de retransmissions, les SoftIRQ sont stables.
- Passage à l'E/S : l'historique de latence de vfs_read montre une longue traîne allant jusqu'à 80 ms pour php-fpm. Nombreux appels à openat par requête.
- Filtre sur les chemins d'accès sous wp-content et wp-includes : d'innombrables petites lectures de fichiers prédominent.
- Contrôle croisé des Locks : Futex-Histo sans anomalie – pas de contention de Lock.
- Mesure : adapter la configuration d'OPCache, mettre en cache les ressources statiques de manière plus intensive. Cela permet de réduire le nombre d'ouvertures et les latences.
Avec moins de 15 minutes de traçage actif, une chose est claire : ce n'est pas le réseau, mais E/S de fichiers et absence de mise en cache provoquent les délais d'expiration.
Bases de données et PHP-FPM : identifier rapidement les goulots d'étranglement
Avec MySQL/MariaDB, j'examine les appels système, les verrous et les latences d'E/S de la Processus DB . Je surveille les phases « accept/connect » pour voir si les connexions sont ralenties ou si les handshakes TLS sont bloqués. Pour PHP-FPM, je vérifie si les appels à `execve` et les accès aux fichiers sont anormalement élevés, ce qui indiquerait un manque de mise en cache. Grâce aux traces de pile pour certains appels système, j’identifie à quel endroit du code les requêtes sont bloquées. Je procède ainsi à l’exclusion progressive du réseau, de l’application et de la base de données pour trouver la cause la plus probable. Emploi.
Bonnes pratiques pour des serveurs performants
Je commence chaque traçage par une Problématique et je limite les requêtes à l'aide de filtres. Les limites temporelles ou les intervalles permettent de maintenir le volume de données à un niveau gérable. Pour les analyses récurrentes, j’enregistre des scripts avec des filtres par défaut pertinents, tels que le PID, le cgroup ou le nom du processus. Avant de les déployer sur les serveurs des clients, je teste les scripts complexes sur des systèmes de préproduction. Cela permet de limiter la surcharge et d’éviter toute Effets de bord.
Qualité des mesures, frais généraux et limites dans la pratique
bpftrace reste dans une fourchette de pourcentage à un chiffre en termes de surcharge CPU lorsque j'utilise des sondes ciblées, à condition de respecter les points suivants :
- Filtrage à l'entrée: Je filtre dès le début (par exemple sur comm/PID), plutôt que de trier les résultats dans Maps.
- Échantillonnage: Pour les échantillons très chauds, j'utilise l'échantillonnage, par exemple 1% des événements :
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Utilisation parcimonieuse des traces de pile: kstack/ustack uniquement si nécessaire – compter d'abord, puis approfondir.
- Taille de la mémoire tampon: En cas de pics d'événements, j'augmente la taille du tampon circulaire :
export BPFTRACE_PERF_RB_PAGES=4096 - Ne pas laisser la fenêtre ouverte trop longtemps: Des intervalles (5 à 30 s) et une fin clairement définie permettent d'éviter les données incohérentes.
Si je constate des „ événements perdus “, j'augmente la mémoire tampon, je réduis la profondeur de la pile ou je resserre les filtres. Pour plus de précision, je préfère Points de trace (ABI stable) par rapport à kprobes (les noms des fonctions du noyau peuvent varier).
Sécurité, gouvernance et règles de multi-locataires
En matière d'hébergement mutualisé, je veille rigoureusement à ce que Protection des données et des périmètres bien définis. Je trace les signaux techniques, et non les données clients, et je documente le motif, l'étendue et la durée. Pour les environnements multi-locataires, je définis des directives strictes : qui est autorisé à lancer le traçage, quels filtres sont nécessaires et quand je mets fin au traçage. Je minimise ou pseudonymise les journaux contenant des chemins d'accès sensibles. Cela me permet d'obtenir des données techniques exploitables sans enfreindre les limites des locataires, et de respecter la Conformité un.
Installation et prérequis sur les serveurs Linux modernes
Pour bpftrace, j'utilise Linux 5.x, car les fonctionnalités et Stabilité sont nettement meilleures, même si 4,9 est considéré comme le seuil minimal. J'installe bpftrace via apt ou dnf et j'ajoute les en-têtes du noyau dès que des sondes plus complexes s'avèrent nécessaires. Ensuite, je vérifie les configurations des cgroups, les environnements d’exécution des conteneurs et les modules de sécurité qui régulent l’accès aux sondes. Un bref test avec des points de trace simples permet de s’assurer que les signatures et les symboles correspondent. Ainsi, plus rien ne s’oppose à un démarrage structuré, et je peux commencer à Mesures conduire.
Portabilité : BTF, résolution des symboles et sondes stables
Pour des scripts robustes, je mise sur BTF- des informations de type (vmlinux) qui aident bpftrace lors de la résolution des champs. Si elles font défaut, je privilégie les tracepoints plutôt que les kprobes. Pour uprobes (Userland), j'ai besoin de binaires non dépouillés ou de symboles de débogage séparés – cela vaut particulièrement la peine pour PHP-FPM ou mysqld. Je vérifie les versions avec „ bpftrace –info “ et je prévois un petit bloc de compatibilité dans les scripts au cas où les noms d'événements varieraient en fonction du noyau.
Déroulement des soins : du symptôme à la cause en 15 minutes
Je commence par formuler la Hypothèse: Réseau, E/S, CPU ou base de données ? Je mets alors en place une trace rapide au niveau le plus probable, par exemple au niveau des retransmissions ou des latences de fichiers. Si les premières minutes laissent entrevoir une tendance, j'affine les filtres, j'y ajoute des traces de pile et je limite la durée d'exécution. Si mes soupçons se confirment, j’effectue des mesures plus en profondeur dans le service concerné et je ne capture plus que les chemins pertinents. Grâce à cette approche ciblée, j’évite d’avancer à l’aveuglette et j’arrive rapidement à la cause la plus probable. Cause.
Guide opérationnel : intervention initiale en 15 minutes
- Minute 0–2: Sélectionner une hypothèse (réseau/E/S/CPU/base de données). Lancer la commande « Baseline One-Liner ».
- Minutes 3 à 5: Identifier les premières anomalies (par exemple, nombre élevé d'openat, retransmissions, histogrammes Futex).
- Minutes 6 à 8: Améliorer les filtres (comm/PID/cgroup, chemins d'accès) et ajouter des histogrammes de latence.
- Minutes 9 à 12: Activer les traces de pile uniquement au niveau du point chaud afin de mettre en évidence les parties de code concernées.
- Minutes 13 à 15: Définir une mesure (mise en cache, limites, modification de la configuration) et la tester rapidement.
Tableau comparatif : les « Probes » et leur utilité au quotidien
Le tableau suivant présente des exemples typiques échantillons, leur domaine d'application et leur principal avantage dans le contexte de l'hébergement. Je m'en sers comme aide-mémoire lorsque je souhaite choisir rapidement le point de mesure approprié.
| Type d'échantillon | Utilisation | Exemple | Avantages |
|---|---|---|---|
| tracepoint:syscalls | Compter/filtrer les appels système | sys_enter_openat, execve | „ Les bruyants “ Processus trouver |
| kprobe/kretprobe | Mesurer les fonctions du noyau | vfs_read, tcp_retransmit | E/S et réseauLatence visible |
| uprobes/uretprobes | Tracer les fonctions du Userland | Symboles mysqld, php-fpm | Localiser les points d'accès aux bases de données et aux applications |
| tracepoint:net/* | Identifier les événements de réseautage | Retransmissions TCP, RST | Délai d'attente-Causes délimiter |
| perf events | Point de vue du processeur et du planificateur | Profils « on-cpu » et « off-cpu » | Identifier les goulots d'étranglement dans la planification |
Résumé à l'intention des administrateurs et des DevOps
bpftrace me donne une image nette Lentille sur les signaux du noyau et des applications que la surveillance classique néglige souvent. Je commence modestement, j’applique un filtrage ciblé et je contrôle les durées d’exécution afin que les résultats de mesure restent clairs. En quelques lignes de script, je détecte le bruit des processus, les latences des fichiers, les retransmissions réseau et les temps d’attente des bases de données. Cette approche réduit sensiblement le temps moyen de résolution (Mean Time to Resolution) sur les hôtes en production. En intégrant bpftrace à son flux de travail, on résout les incidents d'hébergement de manière ciblée et on maintient les sites web ainsi que les API sensiblement réactif.
