Passer au contenu 
sar sysstat Il me fournit des métriques historiques des serveurs Linux, grâce auxquelles je peux suivre avec précision, au fil du temps, les modèles de charge, les goulots d'étranglement et les comportements anormaux. Je peux ainsi analyser rétrospectivement l'utilisation du processeur, de la mémoire vive, des E/S et du réseau, et détecter les pics récurrents qu'un simple outil en temps réel risque facilement de négliger.
Points centraux
Je résume ci-dessous ces points essentiels de manière concise et claire.
- Historique Plutôt qu'un instantané : un enregistrement régulier permet de mettre en évidence les schémas de charge.
- Combinaison à partir de la collecte et de l'analyse : sysstat collecte les données, sar les traite.
- Largeur en termes de métriques : CPU, RAM, espace d'échange, E/S disque, réseau, etc.
- Diagnostic Causes : ajuster de manière ciblée les plages horaires et les comparer.
- Planification en tenant compte des tendances : dimensionner les capacités de manière réaliste.
À quoi servent sar et sysstat au quotidien ?
J'utilise sar en tant que « System Activity Reporter », qui rend lisibles les données enregistrées par sysstat. sysstat collecte régulièrement des données relatives au processeur, à la mémoire, aux E/S et au réseau, tandis que j'utilise sar pour générer des rapports ciblés sur des périodes spécifiques. Cela me permet d’identifier sans avoir à deviner les pics de charge récurrents dus aux sauvegardes, aux tâches cron ou aux pics de trafic. Contrairement à Outils en direct Contrairement à top ou htop, je ne me contente pas d'évaluer l'état instantané, mais je tiens compte de l'évolution dans le temps. Cette approche permet d'éviter les erreurs de diagnostic, car elle distingue la cause de l'effet et me fournit des indications fiables.
Installation et activation sur les distributions courantes
J'installe sysstat À l'aide du gestionnaire de paquets, active la collecte et vérifie les temporisateurs systemd. Sous Debian/Ubuntu, il suffit généralement de apt install sysstat et un aperçu de /etc/default/sysstatsuivi de systemctl enable --now sysstat. Sur RHEL/CentOS/Oracle Linux, j'utilise dnf install sysstat et contrôle les minuteries via systemctl. Les fichiers journaliers sont ensuite généralement enregistrés dans le répertoire /var/log/sa/ avec des noms tels que sa10 pour le 10 du mois. Je vérifie la saisie à l'aide de sar sans paramètre ou avec sar -u 1 3 pour une petite vérification ponctuelle.
Explication des commandes sar les plus importantes
Pour le processeur, j'utilise sar -u et, si nécessaire, par cœur sar -u -P ALLafin de Pointes impossible à ignorer. En ce qui concerne la mémoire et la mise en cache, je considère que sar -r et le swapping avec sar -S. Je lis l'activité du disque avec sar -d, le réseau avec sar -n DEV,ETCP,TCP,UDP. J'ouvre les fichiers historiques avec sar -f /var/log/sa/sa10 et délimiter des plages horaires avec -s HH:MM -e HH:MM . Pour les analyses détaillées des temps d'attente, j'ajoute « sar » à Analyser les temps d'attente d'E/S, car cela me permet de mieux évaluer les files d'attente et le débit, et Goulots d'étranglement identifie clairement.
Bien interpréter les valeurs mesurées : CPU, mémoire, E/S, réseau
Je me concentre sur quelques indicateurs clés qui me donnent rapidement une image fiable de la situation et que je compare au fil du temps. CPU-Idle Une valeur proche de 0 et un %iowait élevé indiquent la présence de files d'attente au niveau du disque. Un %steal élevé révèle une pénurie de ressources CPU dans l'environnement de virtualisation. Concernant la RAM, je surveille les pages de mémoire libres, le comportement du cache de pages et les entrées/sorties de la zone d'échange. Pour le réseau, les erreurs de paquets, les pertes et les retransmissions permettent de détecter les limites de capacité ou les perturbations.
| Métriques | commutateur SAR | Valeurs inhabituelles | mesure immédiate |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle très bas, %iowait élevé | Vérifier les E/S, répartir les threads, valider les besoins en CPU |
| Mémoire | sar -r | peu d'espace libre, forte perte de cache de page | Optimiser les services, augmenter la mémoire vive, évaluer la mise en cache |
| Swap | sar -S | changements fréquents de joueurs | Alléger la mémoire vive, ajuster les limites |
| E/S de disque | sar -d | Valeurs élevées pour « await » et « svctm », la file d'attente s'allonge | Vérifier le profil d'E/S, ajuster la hiérarchisation du stockage ou les fenêtres de traitement par lots |
| Réseau | sar -n DEV,ETCP | Perte de paquets, erreurs, retransmissions | Tester le MTU et le déchargement, analyser la bande passante et la latence |
Analyser les données historiques et les plages horaires
Je travaille presque toujours avec plages horaires, par exemple sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 pour les missions de nuit. Je compare ainsi des plages horaires identiques sur différents jours et identifie des tendances plutôt que des cas isolés. Pour l'analyse automatique, j'enregistre les données avec sadf -d au format CSV et je les importe dans mon propre tableau de bord. En cas de pics inhabituels, j'examine les intervalles adjacents afin d'écarter tout effet secondaire. Je privilégie cette méthode simple, car elle me fournit rapidement des informations exploitables sans nécessiter de long travail préparatoire.
Analyse des tendances et planification des capacités
J'utilise les valeurs archivées pour Prévisions et je dimensionne les ressources en fonction de données réelles plutôt que de mon intuition. Si l'utilisation du processeur augmente d'une semaine à l'autre, je prévois des cœurs ou des réserves de fréquence supplémentaires. Si les besoins en mémoire vive augmentent en raison des caches, je compare les avantages d’une extension de RAM. Si le chemin d’E/S présente des temps d’attente accrus, j’opte pour un stockage plus rapide ou des fenêtres de traitement par lots découplées. Pour la visualisation, j’intègre les données soit à Grafana et Prometheus et associe les tendances SAR aux indicateurs provenant des exportateurs.
Cas pratique : serveur web soumis à des pics de charge
Je vais décrire un cas où les sites WordPress mettent du temps à répondre chaque soir et Utilisateur Signaler les interruptions. Avec sar -u -s 18:00:00 -e 20:00:00 et sar -d Je constate des pics d'E/S simultanés pendant les sauvegardes. Parallèlement, on observe sar -n DEV une augmentation du débit du réseau, ce qui vient compléter le tableau de la charge. Le test de vérification effectué le lendemain, sans sauvegarde, confirme cette tendance. Je déplace la tâche, j'optimise les requêtes de base de données et je rééquilibre les caches, ce qui fait disparaître les pics du soir et permet aux temps de réponse de redevenir constants.
Conseils pour la gestion, la rotation et la conservation des données
Je vérifie les Rangement dans /etc/sysconfig/sysstat ou /etc/default/sysstat et je règle la durée de conservation en fonction des besoins. Pour les hôtes critiques, je conserve les données pendant 30 à 90 jours afin de détecter les effets saisonniers. La taille des fichiers reste gérable tant que les intervalles sont raisonnables et qu’aucune fréquence excessive à la seconde n’est activée. Je transfère les archives les plus anciennes vers un répertoire central ou je les ajoute à un simple système de stockage à long terme. Je garantis ainsi la disponibilité des données sans surcharger le système ni ralentir l'analyse.
Intégration avec les piles de surveillance et les journaux
Je définis sar comme Données brutes-fournisseur et je l'associe à une surveillance centralisée, à l'analyse des journaux et à un système d'alerte. Une pile APM ou de journaux me fournit des événements, tandis que sar permet de situer chronologiquement les valeurs de l'infrastructure. Pour les hôtes particulièrement « bruyants », j'utilise en outre pidstat et iostat, afin d'associer les processus et les chemins d'E/S. De plus, cela m'aide à Comptabilité analytique, d'identifier clairement les processus gourmands en ressources. Cette combinaison entre la vue des événements et celle des métriques m'évite d'avancer à l'aveuglette et réduit considérablement le temps que je passe à rechercher les erreurs.
Réglage fin de la configuration : intervalles, sa1/sa2 et minuterie
Je pose les Fréquences d'enregistrement de manière à ce qu'elles correspondent à la dynamique du système. Un intervalle d'une minute constitue la norme, tandis que pour les hôtes très volatils, un intervalle de 10 à 30 secondes peut également s'avérer judicieux. La collecte prend en charge sa1 (échantillons fréquents), le résumé quotidien sa2 (Rapports quotidiens). Sous systemd, je vérifie les temporisateurs ou services concernés et j'ajuste la fréquence. Sous Debian/Ubuntu, j'active souvent explicitement la collecte avec ENABLED="true" dans /etc/default/sysstat. Je consigne les intervalles pour chaque environnement afin que les comparaisons ultérieures soient correctes et que personne ne tire de conclusions erronées en comparant des échantillons de 5 secondes à des données sur 1 minute.
Aperçu des options avancées de sar
Outre les commandes classiques, des boutons supplémentaires me permettent de Vue d'ensemble: sar -b indique le débit d'E/S par blocs agrégé, sar -B le comportement de pagination du noyau et sar -W l'activité de swap en détail. Avec sar -q Je vois la file d'attente Runqueue (les processus en attente de CPU) et l'évolution de la charge. sar -H fournit des données Hugepage, le cas échéant. Pour les disques, j'utilise, si nécessaire, sar -d -p, afin d'examiner les partitions séparément. Je fais attention avec svctm: Cette valeur est parfois peu fiable ou égale à 0 dans les noyaux modernes ; je préfère considérer await (latence de bout en bout) et avgqu-sz/aqu-sz (taille de la file d'attente). Et quand j'ai besoin d'une vue d'ensemble rapide, cela me donne sar -A une vue d'ensemble que j'affine ensuite.
Évaluer correctement les machines virtuelles et les conteneurs
À l'adresse suivante : Virtualisations Je porte une attention particulière à %steal : des valeurs élevées de « Steal » indiquent que l'hyperviseur prélève du temps CPU à la VM. Cela peut facilement conduire à des erreurs d'interprétation si je ne tiens compte que de %idle. Je mets donc en corrélation l'utilisation du processeur, le « Steal » et la file d'attente d'exécution (sar -q) ensemble. Dans les environnements de conteneurs, je sépare la vue de l'hôte et celle de la charge de travail : sar surveille l'hôte, et non les conteneurs individuels. Si j'ai besoin de détails par service, j'ajoute pidstat (par processus) et tiens compte des limites des cgroups. Je vérifie également la modulation de la fréquence du processeur et les états d'alimentation (changements de fréquence), car ils peuvent entraîner des latences à court terme qui, hors contexte, peuvent donner l'impression d'une pénurie de ressources CPU.
Référence temporelle : fuseaux horaires, heure d'été et corrélation fiable
Je fais attention à base de temps constante, afin que les comparaisons soient correctes. Par défaut, sar enregistre les données en heure locale ; dans le cas des clusters, il est préférable d'utiliser un fuseau horaire uniforme (souvent UTC). À l'occasion du passage à l'heure d'été, je vérifie s'il y a des plages horaires en double ou manquantes et, si nécessaire, j'utilise la sortie de sadf avec des horodatages au format ISO. Pour établir des corrélations avec les journaux ou les événements APM, je synchronise les fuseaux horaires afin de faire correspondre précisément les pics dans les métriques avec les événements (déploiements, sauvegardes, tâches Cron). Des références temporelles précises réduisent considérablement les malentendus lors des analyses rétrospectives d'incidents.
Automatisation et exportation avec sadf
Pour les rapports et les tableaux de bord, j'exporte les données à l'aide de sadf. Au quotidien, j'utilise sadf -d (CSV) pour des analyses simples, ou bien sadf -j (JSON) pour les pipelines flexibles. Une exportation type se présente comme suit : sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18h00 -e 20h00 > sar_soir.csv. Je génère ainsi un fichier contenant les indicateurs relatifs au CPU, à la RAM, aux E/S par blocs et au réseau pour une plage horaire en soirée. Dans des scripts, je les utilise pour comparer automatiquement les jours de la semaine, calculer la médiane et le 95e centile, et signaler les valeurs aberrantes. Je limite volontairement le nombre de métriques afin de préserver la lisibilité et d’éviter les fausses alertes.
Cas pratique : serveur de base de données soumis à une forte pression sur le cache de pages
Un serveur MySQL signale des latences sporadiques au niveau des requêtes. sar -r montre une diminution du cache de pages en soirée, sar -S des swaps occasionnels. Parallèlement, on observe chez sar -d le await-temps, et sar -b indique une augmentation des flux d'écriture. La corrélation avec les rotations des journaux et une tâche ETL explique ce phénomène : d'importantes vagues d'écriture séquentielles saturent le cache et poussent les lectures de la base de données vers les E/S. J'étale les tâches, j'augmente modérément la mémoire vive et j'agrandis de manière ciblée la taille du tampon de la base de données. Par la suite, les valeurs « await » et « swap » restent stables, les latences diminuent et le cache de pages conserve de manière fiable les ensembles les plus actifs en mémoire.
Aspects opérationnels : frais généraux, listes d'équipements et filtres
Je tiens le Overhead petit, en sélectionnant des échantillons proportionnés. Sysstat lit principalement à partir de /proc et écrit en binaire ; avec des intervalles d'une minute, je ne ressens pratiquement pas la charge. Sur les hôtes comportant un très grand nombre de périphériques ou des périphériques bloc à durée de vie courte (par exemple lors de snapshots), je filtre la sortie de manière ciblée et n'évalue que les chemins pertinents. Pour les périphériques dm-crypt, MD-RAID ou multipath, je vérifie à la fois le périphérique logique et, dans la mesure du possible, le périphérique sous-jacent, afin d’identifier correctement les goulots d’étranglement. Je documente les noms des périphériques afin que les comparaisons ultérieures ne soient pas compromises par des chemins renommés.
Méthodologie : valeurs de référence et jours de comparaison
Je définis, pour chaque hôte, une Ligne de base par tranche horaire (par exemple : 1 h – 5 h : traitement par lots, 9 h – 18 h : bureau, 18 h – 22 h : pic d'activité). Pour chaque tranche, je note les valeurs médianes typiques et les centiles acceptables (par exemple : CPU-%idle, await, avgqu-sz, retransmissions). En cas d'écarts, je commence par rechercher de nouvelles tâches, de nouveaux déploiements ou de nouveaux modèles de trafic ; ce n'est qu'ensuite que j'envisage d'augmenter les capacités. Cet ordre rigoureux évite les décisions précipitées : souvent, un petit changement de plan ou un ajustement des limites suffit davantage qu’une augmentation coûteuse du matériel. sar me fournit pour cela une base de données fiables sur plusieurs semaines et plusieurs mois.
Limites et compléments utiles
Je ne considère pas sar comme un substitut à Alerte, car par défaut, il ne surveille aucun seuil et n'envoie aucune notification. Les alertes en temps réel relèvent de systèmes dédiés qui gèrent les règles, les escalades et les workflows d'équipe. Je couvre également les métriques approfondies relatives aux applications, aux bases de données ou aux JVM à l'aide d'Exporter et de Tracing. sar s’avère particulièrement utile lorsque je souhaite comparer l’historique des ressources système et identifier les goulots d’étranglement dans le fonctionnement. En résumé, je l’utilise de manière ciblée lorsque des réponses rapides et reproductibles à des questions d’infrastructure sont nécessaires.
En bref
J'utilise sar et sysstat, afin de transformer les données de mesure en un historique clair de la charge du serveur. La combinaison d'une collecte régulière et d'une analyse rétrospective ciblée permet d'identifier les causes plutôt que de se contenter de deviner les symptômes. En quelques commandes, je détecte les problèmes liés au processeur, à la mémoire, aux E/S et au réseau, et je les situe dans le temps. J’en tire des décisions réalistes en matière de capacité et identifie les routines inefficaces, telles que les sauvegardes mal programmées. Les responsables de serveurs Linux qui adoptent cette méthode bénéficient d’une orientation fiable et gagnent du temps lors de l’analyse, de la planification et de l’exploitation.
