Passer au contenu 
Avec strace Linux je vois en direct lesquelles Appels système Je peux vraiment analyser mon application en profondeur et repérer ainsi beaucoup plus rapidement les goulots d'étranglement, les problèmes de droits d'accès et les fichiers manquants. Au lieu de journaux incompréhensibles, strace m'indique, à l'endroit crucial, le premier appel ayant échoué, ses arguments et le code d'erreur – c'est précisément ce qui réduit sensiblement le temps passé à rechercher les erreurs.
Points centraux
Les points clés suivants m'aident à détecter plus rapidement les sources d'erreurs avec strace et à les cerner avec précision.
- Transparence: L'analyse directe des appels système permet d'identifier les causes.
- Filtre: Suivre uniquement les fichiers, les processus ou les réseaux ciblés.
- Analyse en direct: Suivre les PID en cours et identifier les goulots d'étranglement.
- Comparaison: Comparer différents hôtes et versions.
- Résumé: Aperçu synthétique des appels fréquents et coûteux.
Aperçu rapide des appels système
Je mets strace lorsqu'une application se bloque, semble fonctionner de manière anormalement lente ou s'arrête sans raison apparente, car la sortie m'indique immédiatement le véritable Déroulement entre l'espace utilisateur et le noyau. Ces lignes contiennent les noms des appels, les paramètres, les valeurs de retour, errno et les signaux, ce qui me permet d’identifier immédiatement où le bât blesse. Très souvent, le premier message d’erreur indique déjà le véritable point de départ d’un problème, par exemple un appel openat renvoyant ENOENT pour un fichier attendu. Si un processus se bloque, j’interprète les appels récurrents à futex ou au polling comme des schémas d’attente. Pour moi, cela ne remplace pas les journaux, mais les complète en apportant une profondeur décisive directement à la frontière du système.
Début : exécuter des processus directement avec strace
Lorsque je souhaite analyser une session récente, je lance directement le programme avec strace, par exemple avec « strace ls », ce qui me permet d'obtenir la liste complète Séquence des fonctions système appelées. Avec -e trace=file, je me concentre sur les accès aux fichiers, tandis que -e trace=process m'affiche les fork, execve et exit. Pour les cas liés au réseau, j'utilise -e trace=network afin que les appels connect, sendto et recvfrom ressortent immédiatement. Si le nombre de lignes ne me fournit pas suffisamment de structure, j’utilise l’option -c pour obtenir des statistiques compactes sur la fréquence et la durée. Je peux ainsi identifier en un clin d’œil quels appels dominent le temps d’exécution et où se forme un goulot d’étranglement.
Ajouter et mettre en avant les services en cours
Pour les services déjà actifs, j'utilise strace -p PID et je me joins à la discussion en question Instance, sans risque de redémarrage ni de temps d'arrêt. L'option -f me permet d'inclure les processus enfants, ce qui est essentiel notamment pour les serveurs web et les workers. Les horodatages avec -tt et les durées indiquées via -T m'aident à interpréter clairement les dépendances et les temps d'attente dans le temps. Si je souhaite uniquement visualiser les accès aux fichiers, je limite la sortie avec -e trace=file et réduis ainsi la charge sur le système. Si vous avez besoin d’une introduction concise aux transitions du noyau, vous trouverez ici une présentation simple : Comprendre les appels système, ce qui facilite la lecture des lignes de strace.
Identifier rapidement les causes des erreurs : fichiers, droits d'accès, blocages
Je reconnais les schémas typiques à quelques Remarques: ENOENT m'indique des chemins manquants ; les codes EACCES ou EPERM indiquent Autorisations, tandis que des appels futex persistants ou l'utilisation de ppoll/pselect indiquent la présence de verrous ou de conditions d'attente. Si je rencontre les codes d'erreur EADDRINUSE ou ECONNREFUSED, je vérifie les ports et les entités distantes. En cas de problèmes TLS ou DNS, j’évalue les historiques des appels `connect` et `recvfrom` ainsi que les intervalles de temps entre les lignes. Si les appels `openat` sur le même fichier se répètent sans succès, cela est généralement dû à un chemin de recherche incorrect ou à une variable d’environnement défectueuse. Je mets donc rarement longtemps à localiser la première erreur majeure.
Rendre visible la structure des coûts et des délais
Avec l'option -c, j'obtiens des statistiques condensées qui me fournissent Parts et indique la fréquence d'appel par fonction du système, ce qui me permet de définir des priorités pour Tuning Je m'en rends compte. En ajoutant les suffixes -tt et -T, j'enregistre des horodatages précis ainsi que la durée de chaque appel, ce qui vaut son pesant d'or en cas de blocages sporadiques. De longs intervalles entre deux lignes m’amènent à soupçonner des pauses d’E/S ou de réseau. Si je constate de nombreux petits accès en lecture, je vérifie la mise en mémoire tampon et les accès au système de fichiers de mon application. Cela me permet de cibler mes optimisations sans tâtonner dans le noir.
Comparaisons entre hôtes et versions
Si une opération fonctionne sur l'hôte A mais échoue sur l'hôte B, je lance les deux exécutions avec strace et compare les Différences au niveau des chemins d'accès, de `errno`, des bibliothèques et des variables d'environnement. Cela me permet de déterminer rapidement si un paquet manque, si un autre chemin de recherche est actif ou si les droits d'accès diffèrent. Si les appels système tels que openat et statx diffèrent dans leur ordre ou leur chemin cible, cela indique généralement un contexte de démarrage différent. Pour les questions de performances plus approfondies, j’utilise également des outils complémentaires ; cet aperçu sur bpftrace dans l'hébergement Cela m'aide à analyser encore plus précisément les événements du noyau. Utilisés conjointement, strace et bpftrace me fournissent une vue d'ensemble claire du parcours d'une requête à travers le système.
Compléter les journaux, ne pas les remplacer
Je continue à lire Journaux d'application, mais strace comble les lacunes entre le code et le noyau lorsque les messages sont énigmatiques ou font totalement défaut, ce qui Recherche considérablement réduites en fonction des causes. Pour les questions liées à la sécurité, j'aime associer cette analyse à des audits ; ceux qui enregistrent systématiquement les incidents de sécurité tireront profit de ce guide : Enregistrer correctement les informations d'audit. Cela me permet de voir si, par exemple, une règle de sécurité bloque l'accès, tandis que strace m'indique la valeur errno correspondante. Ces deux points de vue offrent une vision plus complète. Il est toutefois important de limiter la durée d'exécution de strace afin que la sortie ne devienne pas trop volumineuse.
Flux de travail en cabinet pour une identification rapide
Je commence par définir la Question concernant le processus : plantage, erreur, résultat erroné ou réponse lente, afin que je puisse trouver la bonne Option Je choisis. Si je redémarre, j'utilise strace avec des filtres tels que -e trace=file ou -e trace=network ; sinon, je me connecte au service avec l'option -p. Ensuite, j'observe jusqu'à ce que l'erreur apparaisse, puis je mets fin à la session. Je traite immédiatement la ligne incriminée : je vérifie le chemin d'accès, j'ajuste les droits d'accès et je teste le point de terminaison. Si la piste ne permet pas de clarifier la situation, j'élargis les informations temporelles et j'utilise l'option -c pour détecter les points chauds.
Enregistrer les résultats et les analyser ultérieurement
Si une erreur se produit rarement, je redirige la sortie avec -o dans un fichier et active la division avec l'option -ff PID . Cela me permet de distinguer les activités des processus parents et enfants. Avec l'option -s, j'augmente la longueur d'affichage des arguments lorsque des chemins tronqués me privent d'informations importantes. Pour les exécutions longues, je définis une condition d’arrêt claire, par exemple jusqu’au prochain point d’erreur, afin que le volume de données reste gérable. Par la suite, je filtre le fichier avec grep en fonction de la valeur d’errno ou des types d’appels, ce qui me permet d’obtenir les lignes pertinentes en un clin d’œil.
Aperçu des principales options de strace
Le tableau suivant résume les plus courants Options et leurs aspects pratiques Avantages ensemble, pour que je n'aie pas à chercher longtemps lors d'analyses de bogues menées dans l'urgence.
| Option | Objectif | Utilisation typique |
|---|---|---|
| -e trace=fichier | Se concentrer sur les opérations sur les fichiers | Vérification rapide des fonctions open/openat, statx et access |
| -e trace=process | Afficher les activités du processus | Suivre les appels « fork », « execve », « clone » et « exit » |
| -e trace=réseau | Filtrer les appels réseau | Isoler les fonctions connect, sendto et recvfrom |
| -p PID | Se joindre à des processus en cours | Analyser les services sans redémarrage |
| -f | Inclure les processus enfants | Recenser intégralement les travailleurs et les spawns |
| -c | Statistiques succinctes | Fréquence et durée par appel |
| -tt / -T | Des horaires plus précis | Identifier les intervalles de temps et les durées |
| -o FICHIER | Rediriger la sortie | Permettre une analyse ultérieure |
| -ff | Écriture par fichier de processus | Séparer les parents et les enfants |
| -s N | Augmenter la longueur de l'argument | Afficher les chemins coupés |
Sécurité, droits et effets secondaires
Je calcule toujours le Overhead car strace intercepte et enregistre chaque appel, ce qui permet de déterminer les Effets peut entraîner. Dans les environnements de production aux ressources limitées, je procède donc à un traçage ciblé et succinct. Selon le système, des mécanismes de sécurité tels que ptrace_scope ou les politiques SELinux, qui limitent l'accès, peuvent s'appliquer ; je vérifie cela au préalable. Lorsque j’interviens sur des processus traitant des données sensibles, je veille à ce que les résultats soient anonymisés ou j’effectue l’analyse dans un environnement isolé. Je préserve ainsi la confidentialité, maintiens une charge modérée et obtiens malgré tout des résultats rapides.
Exemples pratiques tirés de la vie quotidienne
Un service Web démarre, mais renvoie une erreur 500 : Avec -e trace=fichier je trouve rapidement ce qui manque Config-File, car openat renvoie ENOENT. Un outil CLI s'interrompt immédiatement : je constate une erreur EACCES sur une bibliothèque et je modifie les droits en conséquence. Une application semble lente : -c affiche de nombreux petits appels read, j'augmente la mise en mémoire tampon et je réduis le flux d'appels système. Un thread de travail se bloque : futex reste bloqué indéfiniment, je vérifie les verrous dans le code et je résous le blocage. Un délai d'expiration DNS est détecté : des intervalles entre sendto et recvfrom m'indiquent un problème réseau extérieur à l'application.
Rendre visibles le contenu des données et le contexte des descripteurs
Si les valeurs de retour seules ne me suffisent pas, j'affiche de manière ciblée tampon de données et le contexte de Déscripteurs de fichiers un. Avec -s N j'augmente la longueur visible de la chaîne pour les arguments (par exemple 256 ou 1024 caractères) afin de voir les chemins d'accès complets, les blocs JSON ou les en-têtes. Pour les contenus non imprimables, j'utilise -x (caractères non ASCII sous forme hexadécimale) ou -xx (tout en hexadécimal), ce qui est particulièrement utile pour les protocoles binaires. Avec -e lecture=tous et -e write=all j'affiche les données utiles réelles des appels read()/write() et je vérifie ainsi si les requêtes et les réponses semblent plausibles. En parallèle, j'aime bien activer -y, afin que strace affiche également les chemins d'accès correspondant aux descripteurs de fichiers (par exemple 3), et -yy pour plus de détails sur les sockets. J'utilise cette profondeur avec parcimonie, car elle génère rapidement un volume important de données de sortie et peut contenir des informations sensibles ; c'est pourquoi, dans les environnements de production, j'opte pour un décolleté étroit et renouvelle régulièrement les fichiers.
Filtres plus précis : appels système, chemins d'accès et exclusions
Pour rester concentré, j'utilise, en plus des catégories prédéfinies, également filtres à grains fins. Je précise que -e trace=openat,statx,access saisir précisément les appels système qui m'intéressent actuellement, ou continuer à accéder à des catégories telles que -e trace=signal ou -e trace=ipc je reviens à cela lorsque je souhaite surveiller les signaux ou la communication interprocessus. De plus, il est pratique de -P CHEMIN, afin de limiter l'accès à un ou plusieurs des pistes concrètes à voir, par exemple -P /etc,/var/www. Quand un classique comme futex Si cela me dérange, je n'ai qu'à inverser le principe de filtrage et à l'exclure en ne spécifiant explicitement que les appels pertinents. J'obtiens ainsi une à faible bruit Identifier la zone d'erreur tout en limitant les frais généraux.
Enregistrer de manière fiable les chronologies, les traces de pile et les exécutions de courte durée
Les horaires sont ma boussole. À côté de -tt Pour obtenir des horodatages précis, j'utilise volontiers -ttt, lorsque je souhaite comparer des exécutions sur plusieurs hôtes, car les horodatages d'époque facilitent l'analyse. -r m'indique les distances relatives depuis le départ, ce qui facilite la détection de Espaces d'attente d'avoir une vue d'ensemble. En cas de plantages sporadiques, cela m'aide à -i (pointeur d'instruction) ainsi que -k (trace de pile), afin de déterminer de quel contexte de pile provient un appel coûteux ou défectueux – particulièrement utile lorsque des informations de débogage sont disponibles. Pour les très de courte durée Pour lancer des programmes ou des tâches cron, je les exécute directement sous strace ou j'utilise -ff -o, afin de ne manquer aucun appel execve précoce ni aucune initialisation. Si je souhaite comparer plusieurs exécutions, je trie les statistiques -c à l'aide de -S time, afin de détecter plus rapidement les pics de durée totale.
Maîtriser les threads, les forks et les arborescences de services complexes
Dès que plusieurs processus ou threads sont impliqués, je passe à -f pour que les processus enfants s'exécutent, et je m'assure avec -ff des fichiers de sortie distincts par PID. Cela me permet ensuite d'analyser séparément chaque thread pour chaque worker et d'éviter toute confusion. Dans les environnements comportant de nombreux processus enfants à courte durée de vie, la combinaison de -e trace=process (execve/clone/fork/exit) et Horaires, afin de comprendre l'émergence et la disparition des processus au fil du temps. Des schémas récurrents tels que „ Parent attend Child “, reconnaissables à wait4 ainsi qu'un manque d'activité de la part de l'enfant, indiquent la présence de blocages ou un manque de ressources. Lorsque j'accompagne des migrations, je compare les arborescences de services entre l'ancien et le nouvel hôte, ce qui me permet de voir si Répartition des travailleurs ou Pré-fork se déroule de manière identique ou s'écarte sans que l'on s'en aperçoive.
Les conteneurs, les espaces de noms et les droits au quotidien
Dans des conteneurs ou Espace de nommage- Dans ces scénarios, je planifie les autorisations à l'avance. Pour me connecter à des processus tiers, j'ai besoin des droits ou des capacités appropriés (tels que CAP_SYS_PTRACE), ainsi que de mécanismes de sécurité tels que ptrace_scope ou certaines politiques peuvent bloquer l'accès. Si Ziel et Tracer s'exécutent dans différents espaces de noms, soit je m'inscris dans le même espace de noms, soit je passe délibérément dans le contexte cible. Dans les environnements orchestrés, je tiens également compte du fait que les PID ont une durée de vie limitée et Faire pivoter les traces afin de ne pas perdre la période concernée. Je réduis au minimum les données transmises (par exemple, pas de charges utiles complètes) lorsque des données sensibles transitent par la ligne, et je limite strictement la durée d'exécution à la phase problématique, afin de limiter les effets secondaires.
Strace dans les pipelines de compilation et de déploiement
J'utilise aussi strace tôt dans CI/CD, afin de valider le packaging, les chemins d'accès et les autorisations. Un test à sec avec -e trace=fichier permet de vérifier rapidement si un binaire issu du conteneur de compilation trouvera ultérieurement les mêmes bibliothèques et chemins de configuration sur le système cible. Pour les tests de régression, je m'assure d'avoir une Ligne de base: Une brève exécution avec l'option -c et des options cohérentes (par exemple -ttt, -S time) sert de référence. Dans les pipelines ultérieurs, je compare les statistiques afin de détecter d'éventuels pics soudains dans statx, lire ou se connecter à repérer rapidement. Pour que les artefacts restent légers, je veille à ce que les traces restent ciblées, je nomme les fichiers de manière déterministe (en incluant les identifiants de build ou de commit) et je normalise les PID ou les horodatages si nécessaire, lorsque je génère des différences textuelles.
Les écueils typiques et les schémas d'interprétation
Je prends systématiquement note de certaines particularités. En cas d'appels interrompus, on observe souvent EINTR (interrompu par des signaux) – une occurrence isolée n'est pas préoccupante, mais une succession d'occurrences est suspecte. Est-ce que je vois ERESTARTSYS- des messages de ce type indiquent que le noyau a relancé des appels système ; je vérifie les sources de signaux et les masques. Lorsque les sorties de différents processus mélangé apparaissent, je les sépare rigoureusement à l'aide de « -ff » et j'utilise les horodatages pour les regrouper. Les traces sans errno- Les erreurs, mais accompagnées de longs intervalles, m'amènent à soupçonner des temps d'attente liés aux E/S ou au réseau ; je me concentre alors sur les opérations de lecture, d'écriture et de connexion, et j'ajoute des mesures de temps. Les chemins restent inchangés. coupé, j'augmente encore la valeur de -s ou je désactive les raccourcis en optant pour un affichage détaillé. Si des différences apparaissent entre les binaires 32 bits et 64 bits (par exemple,. ouvrir vs. openat), je tiens compte de l'architecture et, en cas de doute, je compare les deux variantes.
Sélectionner des publications ciblées : privilégier la lisibilité face à l'avalanche d'informations
C'est justement lorsque je suis sous pression que je veille à doser mes efforts : je définis précisément Questions (Fichier manquant ? Réseau bloqué ? Arbre des processus interrompu ?), applique ensuite les filtres minimaux nécessaires et termine la trace immédiatement après le Preuve. Pour les relais en équipe, j'écris de courts Notes d'accompagnement dans la description du ticket : appel concerné, paramètres, errno, contexte temporel et cause présumée. Lors de longues sessions, je n'active pas toutes les options en même temps, mais je les active progressivement À savoir : d'abord -e trace=…, puis -tt/-T, ensuite -y/-s, et si nécessaire -x/-xx. Cette approche par étapes m'évite d'être submergé par les données et accélère la tirée de conclusions proprement dite. Lorsque les performances sont un enjeu, je privilégie l'option -c (avec -S time) et une sélection restreinte d'appels avant de lancer des traces complètes.
Résumé concis
Avec strace je repère plus rapidement les sources d'erreurs, car j'ai de vraies Appels système au lieu de simples textes de journal. Les filtres, les horodatages et les statistiques -c me fournissent des pistes claires sur les chemins d'accès, les droits d'accès, les réseaux et les temps d'attente. Je lance les programmes directement sous strace ou je me connecte brièvement aux PID en cours d'exécution, je focalise la sortie et j'arrête dès que l'erreur apparaît. Pour une analyse ultérieure, j’enregistre les fichiers avec les options -o et -ff, j’augmente la valeur de -s si nécessaire et je compare les exécutions entre les hôtes afin de mettre en évidence les différences. C’est ainsi que je résous les problèmes quotidiens sur les serveurs Linux en quelques minutes plutôt qu’en plusieurs heures.
