Maîtrise de la Performance : Guide Pratique de la Suite d'Outils Sysstat

Le travail de performance devient compliqué quand on n'a que l'instant présent. Un serveur est lent maintenant, mais l'était-il il y a dix minutes ? Le disque a-t-il commencé à saturer avant que le CPU ne monte ? Le problème a-t-il commencé après le cron job, le déploiement ou la fenêtre de sauvegarde ? La suite d'outils sysstat est utile car elle fournit à la fois des relevés en direct et un historique que vous pouvez comparer.

L'outil principal est sar, le System Activity Reporter. Je l'utilise quand top est trop bref, quand un incident est déjà passé, ou quand je dois montrer qu'un problème était dû au stockage, à la pression mémoire, au trafic réseau ou à la saturation du CPU plutôt que de deviner à partir des symptômes. Le reste de la suite, en particulier iostat et mpstat, apporte des détails lorsque sar vous oriente vers un goulot d'étranglement probable.

Ceci ne remplace pas une observabilité complète. Vous avez toujours besoin de métriques applicatives, de logs, de tracing et de vérifications externes. Mais sur un hôte Linux, sysstat est l'un des moyens les plus rapides de répondre à la première question pratique : que faisait réellement la machine ?

1. Installation et Configuration Initiale de Sysstat

Le paquet sysstat est généralement disponible dans les dépôts standards de toutes les distributions Linux majeures.

1.1 Commandes d'Installation

Utilisez la commande du gestionnaire de paquets appropriée pour votre système :

Debian/Ubuntu :

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora :

sudo yum install sysstat
# ou utilisez dnf pour les systèmes plus récents
sudo dnf install sysstat

1.2 Activation de la Collecte de Données Historiques

Pour que sar soit vraiment utile, il doit collecter des données historiquement. Par défaut, l'installation met souvent en place un cron job ou un timer systemd, mais la vérification est cruciale.

Sur les systèmes modernes, assurez-vous que le service sysstat est actif :

sudo systemctl enable --now sysstat

Fichier de Configuration

La fréquence de collecte des données est contrôlée par des fichiers de configuration, généralement situés dans /etc/default/sysstat (Debian/Ubuntu) ou /etc/sysconfig/sysstat (RHEL/CentOS). Recherchez le paramètre ENABLED ou HISTORY. Définir ENABLED="true" garantit une collecte quotidienne des données.

Astuce : Par défaut, les fichiers de données sysstat sont stockés dans /var/log/sa/ avec des noms de fichiers comme saXX où XX est le jour du mois. Certains systèmes basés sur Debian exposent également les rapports sous /var/log/sysstat/. Vérifiez les valeurs par défaut de votre paquet avant de supposer le chemin.

Après avoir activé la collecte, attendez au moins un intervalle et confirmez que les fichiers apparaissent :

ls -lh /var/log/sa/

Si le répertoire est vide, vérifiez les timers systemd :

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

Sur les systèmes plus anciens, la collecte peut encore être pilotée par cron. L'empaquetage exact varie selon la distribution, alors vérifiez plutôt que de vous fier à la mémoire d'un autre serveur.

2. L'Utilitaire Principal : System Activity Reporter (`sar`)

sar est l'interface principale pour visualiser les statistiques. Il peut afficher des données en temps réel ou analyser des données historiques précédemment collectées.

2.1 Syntaxe de Base pour la Surveillance en Temps Réel

La syntaxe de base est conçue pour rapporter des métriques spécifiques à un intervalle défini pour un nombre défini de fois.

sar [options] [intervalle] [nombre]

Exemple : Pour rapporter les statistiques générales du CPU toutes les 3 secondes, 10 fois :

sar -u 3 10

Cette commande est utile pendant un incident car elle fournit un court échantillon mobile au lieu d'un seul instantané. Une seule ligne peut capturer une seconde calme et vous induire en erreur. Dix échantillons sur trente secondes montrent si le motif est stable, en pics ou déjà disparu.

Option	Description
`-u`	Utilisation du CPU (par défaut)
`-r`	Statistiques mémoire et pagination
`-d`	Activité des périphériques bloc (E/S disque)
`-n`	Statistiques réseau (ex. `-n DEV` pour les stats d'interface)
`-q`	File d'attente et charge moyenne
`-W`	Activité de swapping (pagination)
`-A`	Toutes les métriques (utile pour des instantanés complets)

Pour les fichiers historiques, la forme est la même. Vous ajoutez -f pour choisir le fichier de données et souvent -s et -e pour limiter la plage horaire. Cela compte car lire une journée entière de sortie pendant une panne est lent et bruyant.

3. Métriques de Performance Clés et Exemples Pratiques de `sar`

Comprendre la sortie de sar nécessite de connaître les métriques qui indiquent la santé ou le stress des performances.

3.1 Utilisation du CPU (`sar -u`)

L'utilisation du CPU est souvent le premier endroit où chercher des goulots d'étranglement. Une utilisation élevée dans des catégories spécifiques indique la nature de la charge de travail.

sar -u 5 3

Métrique	Description	Indicateur de Goulot d'Étranglement
`%user`	Temps CPU passé à exécuter des processus en espace utilisateur.	Élevé indique une saturation de l'application/service.
`%system`	Temps CPU passé à exécuter des tâches noyau/système.	Élevé suggère des appels système intensifs ou des problèmes de pilote.
`%iowait`	Temps CPU inactif en attendant des opérations d'E/S (disque/réseau).	Élevé indique un goulot d'étranglement d'E/S, pas un manque de CPU.
`%idle`	Temps CPU passé à ne rien attendre (disponible).	Faible (ex. < 5%) suggère une saturation du CPU.

Soyez prudent avec %iowait. Il est souvent mal interprété comme "le CPU est occupé avec le disque". En réalité, cela signifie que le CPU était inactif alors qu'au moins une requête d'E/S était en attente. Une valeur élevée peut pointer vers une latence de stockage, mais elle nécessite une confirmation avec les métriques disque. Sur un serveur de base de données, par exemple, un %iowait élevé associé à un await disque élevé est un signal beaucoup plus fort que %iowait seul.

Une autre vue CPU utile est la file d'attente d'exécution :

sar -q 5 5

runq-sz montre combien de tâches attendent de s'exécuter. Si la charge moyenne est élevée mais que runq-sz est modeste et %iowait est élevé, vous pourriez être confronté à des E/S bloquées plutôt qu'à une pression pure sur le CPU. Si runq-sz reste élevé et %idle est proche de zéro, la machine a probablement besoin de moins de processus exécutables, de code plus rapide ou de plus de capacité CPU.

3.2 Mémoire et Pagination (`sar -r` et `sar -W`)

Les statistiques mémoire révèlent à la fois la consommation et si le système a recours au swapping ou à la pagination.

Utilisation de la Mémoire (sar -r) :

sar -r 1 5

Concentrez-vous sur kbavail (mémoire disponible). Si kbmemfree est faible, mais que kbcached et kbbuffers sont élevés, la mémoire est utilisée efficacement par le mécanisme de cache du noyau.

Activité de Swapping (sar -W) :

sar -W 1 5

Regardez pswpin/s (pages échangées en entrée) et pswpout/s (pages échangées en sortie). Toute valeur non nulle significative ici indique que le système effectue un swapping agressif, signalant une pression mémoire (un fort goulot d'étranglement).

La sortie mémoire de Linux peut sembler alarmante jusqu'à ce que vous vous rappeliez que le cache n'est pas de la mémoire gaspillée. Un serveur avec très peu de kbmemfree peut encore être sain si kbavail est confortable et que l'activité de swap est calme. Le motif dangereux est différent : la mémoire disponible chute, l'activité de swap-in et swap-out apparaît, et la latence des applications grimpe. Cela vous indique que les processus accèdent à une mémoire qui ne tient plus dans la RAM.

Pour un serveur web, cela peut arriver après un déploiement qui double accidentellement le nombre de workers. Pour un hôte batch, cela peut arriver lorsque deux gros travaux se chevauchent. sar ne vous dira pas quel processus en est la cause, mais il vous donne la chronologie. Associez-le à ps, top, les logs de service ou les métriques cgroup pour identifier le responsable.

3.3 Activité des E/S Disque (`sar -d`)

La surveillance de l'activité disque est cruciale pour les serveurs de bases de données ou les systèmes de stockage fortement utilisés.

sar -d 3 5

Cette sortie nécessite d'identifier les périphériques spécifiques (ex. sda, vda). Les métriques clés incluent :

tps : Transferts par seconde (une valeur élevée indique des requêtes d'E/S élevées).
rd_sec/s & wr_sec/s : Quantité de données lues/écrites par seconde.
%util : Pourcentage de temps pendant lequel le périphérique était occupé à traiter des requêtes. Si %util reste proche de 100% sur un périphérique bloc traditionnel, le stockage peut être saturé.

Sur les SSD modernes et les disques virtuels, %util mérite un contexte. Certains périphériques gèrent bien les E/S parallèles, et les volumes cloud peuvent être limités par les IOPS provisionnés, le débit ou les crédits burst. Traitez %util comme une invitation à regarder de plus près, pas comme un diagnostic complet. Confirmez avec iostat -xd, la latence applicative et les métriques de stockage au niveau de la plateforme si vous êtes sur AWS, Azure, GCP ou un autre environnement virtualisé.

Un workflow pratique est :

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Utilisez sar pour trouver la mauvaise heure, puis utilisez iostat lors d'une récurrence en direct pour inspecter la latence au niveau du périphérique.

3.4 Statistiques Réseau (`sar -n`)

sar peut rapporter l'activité sur différentes couches réseau. La vérification la plus courante est l'activité de l'interface (DEV).

sar -n DEV 5 1

Cette commande affiche des métriques comme rxpk/s (paquets reçus par seconde) et txkB/s (kilooctets transmis par seconde) pour chaque interface réseau. Utilisez-la pour identifier les interfaces subissant une charge lourde ou des erreurs potentielles.

Pour les compteurs d'erreurs, ajoutez EDEV :

sar -n EDEV 5 3

Cela peut montrer les erreurs de réception, les erreurs de transmission, les pertes et les collisions là où le pilote le supporte. Les pertes sont particulièrement utiles lorsqu'un service se plaint de timeouts intermittents mais que le CPU et le disque semblent normaux. Si les pertes augmentent lors des pics de trafic, vous devrez peut-être inspecter les files d'attente NIC, les paramètres réseau du noyau, la mise en réseau des conteneurs ou le chemin du répartiteur de charge.

Pour le comportement au niveau TCP, essayez :

sar -n TCP,ETCP 5 3

Les retransmissions, les réinitialisations et les tentatives de connexion échouées peuvent transformer un rapport vague "le site est lent" en un problème réseau ou amont plus spécifique.

4. Analyse Historique et Création de Références

La véritable puissance de sysstat réside dans sa capacité à analyser l'activité du système sur de longues périodes, ce qui est essentiel pour établir des références de performance (ce qui est normal pour votre système).

4.1 Analyse des Jours Précédents

Pour visualiser les données collectées un jour précédent, utilisez le drapeau -f pour spécifier le chemin vers le fichier saXX quotidien.

Exemple : Pour visualiser les statistiques CPU du 10ème jour du mois en cours :

sar -u -f /var/log/sa/sa10

Pour examiner les statistiques sur une fenêtre de temps spécifique ce jour-là, ajoutez les drapeaux -s (heure de début) et -e (heure de fin) (au format 24 heures).

# Voir les stats réseau de 14:00 à 16:30 le 10
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Établissement de Références

Collectez des Données : Exécutez sysstat pendant les périodes normales de forte et de faible charge.
Identifiez les Normes : Analysez les données historiques (sar -f) pour déterminer l'utilisation moyenne du CPU (%user, %system), la latence maximale des E/S (%util) et l'utilisation moyenne de la mémoire.
Définissez des Seuils : Traitez les écarts soutenus par rapport à votre propre référence comme des déclencheurs d'investigation. Un hôte de base de données occupé et un serveur de rebond calme ne devraient pas partager les mêmes seuils.

Les références sont plus utiles lorsqu'elles sont liées à des rythmes métier réels. Une importation batch du lundi matin, une sauvegarde nocturne et un lancement de produit créent tous des formes "normales" différentes. Prenez des notes lorsque vous enquêtez : "sauvegarde démarrée à 01:00", "nouvelle version à 14:30", "email marketing à 09:05". Ces notes rendent la sortie historique de sar beaucoup plus facile à interpréter plus tard.

5. Outils Sysstat de Support

Bien que sar soit l'outil parapluie, la suite sysstat comprend des utilitaires spécialisés qui offrent des rapports ciblés et très détaillés.

5.1 iostat (Statistiques d'Entrée/Sortie)

iostat fournit des métriques détaillées spécifiquement axées sur l'utilisation des périphériques, particulièrement utile pour diagnostiquer les goulots d'étranglement de stockage.

# Rapporter les stats disque toutes les 2 secondes, 4 fois, y compris les stats étendues (x)
iostat -xd 2 4

Métriques clés d'iostat :

%util : Le pourcentage de temps CPU pendant lequel des requêtes d'E/S ont été émises vers le périphérique (indicateur crucial de saturation).
await : Le temps d'attente moyen (en millisecondes) pour les requêtes d'E/S émises vers le périphérique. Un await élevé indique une lenteur de réponse du stockage.

Si await grimpe mais que le débit n'est pas élevé, recherchez des petites E/S aléatoires, des problèmes de système de fichiers, des voisins bruyants sur une infrastructure virtuelle, ou une application effectuant des écritures synchrones lourdes. Si le débit est élevé et que la latence augmente avec lui, le périphérique a peut-être simplement atteint sa limite pratique.

5.2 mpstat (Statistiques Multi-Processeurs)

Si vous suspectez des problèmes d'ordonnancement du CPU ou une répartition inégale de la charge de travail entre les cœurs, mpstat fournit des statistiques d'utilisation par processeur, ce que sar -u agrège.

# Afficher l'utilisation pour tous les CPU (A) toutes les 2 secondes
mpstat -P ALL 2 1

Ceci est inestimable pour identifier les applications monothread qui saturent un seul cœur tandis que les autres restent inactifs, ou pour diagnostiquer l'efficacité de l'hyperthreading.

5.3 sadf (Exportation des Données Sysstat)

sadf lit les mêmes données collectées que sar mais peut les imprimer dans des formats plus faciles à consommer pour les scripts et les tableaux de bord.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

La sortie -d est utile pour le traitement de texte délimité. La sortie -j est utile lorsque vous voulez du JSON. C'est pratique lorsque vous devez joindre des preuves à un examen d'incident ou comparer deux hôtes sans copier manuellement la sortie du terminal.

6. Une Procédure Pas à Pas d'Incident Pratique

Imaginez un serveur API qui a commencé à expirer à 10:15. Les logs applicatifs montrent des requêtes qui s'accumulent, mais ils n'expliquent pas pourquoi. Commencez par la vue historique du CPU :

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Si %user est élevé et %idle est faible, l'application est peut-être limitée par le CPU. Vérifiez l'utilisation par cœur :

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Si un cœur est saturé tandis que les autres sont calmes, suspectez un worker monothread, un verrou chaud ou une distribution inégale des processus. Si tous les cœurs sont occupés, examinez le taux de requêtes, les déploiements récents et les chemins de code coûteux.

Si le CPU semble principalement inactif mais que %iowait augmente, passez au disque :

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Une utilisation élevée du périphérique ou une profondeur de file d'attente croissante à peu près au même moment pointe vers le stockage. Sur un service basé sur une base de données, l'étape suivante est les logs de la base de données et les données de requêtes lentes. Sur un hôte servant des fichiers, vérifiez si une sauvegarde, un job de compression ou une rotation de logs a eu lieu au même moment.

Si le CPU et le disque semblent corrects, inspectez la mémoire et le réseau :

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Le but n'est pas d'exécuter toutes les commandes à chaque fois. Le but est de suivre les preuves. sar vous donne une chronologie à travers les classes de ressources, ce qui est généralement ce dont vous avez besoin pour arrêter de courir après le symptôme le plus bruyant.

Une Habitude Opérationnelle Simple

La meilleure façon d'apprendre sysstat est de l'utiliser avant que quelque chose ne se casse. Vérifiez un serveur sain pendant le trafic normal. Vérifiez-le pendant les sauvegardes. Vérifiez-le après un déploiement. Enregistrez quelques modèles de commandes qui correspondent à votre environnement.

Lorsqu'un incident se produit, vous saurez déjà à quoi ressemble la normale. C'est la véritable valeur de la suite d'outils. sar, iostat, mpstat et sadf ne diagnostiquent pas l'application comme par magie, mais ils maintiennent la conversation ancrée dans les preuves : quand le problème a commencé, quelle ressource a changé, et si l'hôte était réellement sous pression.