monitoring | Surveiller votre système avec SAR
Article publiée le 2 Septembre 2013
La surveillance de l'état de santé des machines est une tâche récurrente pour un admin système. Un bon admin système doit être capable de fournir rapidement toutes les informations sur son système (cause d'un ralentissement, dysfonctionnement etc.)
Ci dessous la présentation et le tuto d'installation d'un autre outil de monitoring (car on en a jamais assez!!) SAR.
Sar permet d'avoir l'historique concernant l'activité de votre système contrairement aux autres outils qui vous fournissent uniquement des informations en temps réels.
1) Installation
Pour installer Sar sous debian:
apt-get install sysstat
Pour installer Sar sous CentOs/Red-Hat/Fedora:
yum install sysstat.
2) Configuration
Sous debian activez le collecteur d'activité, pour cela éditez le fichier /etc/default/sysstat et remplacez ENABLED="false" par ENABLED="true"
Sous CentOs/Red-Hat/Fedora il vous suffit de démarrer le service: service sysstat start
Par défaut systat effectue une collecte toutes les 10 minutes. Je vous conseille, afin d'avoir une vision de votre système plus fine de réduire l'intervalle à 2 minutes:
- Editez la crontab de systat:
vi /etc/cron.d/systat
Sous debian modifiez cette ligne:
5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1
par
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1
Sous Centos/RedHat/Fedora modifiez cette ligne:
*/10 * * * * root /usr/lib64/sa/sa1 1 1
par
*/2 * * * * root /usr/lib64/sa/sa 1 1 1
- Enregistrez le fichier crontab
- Redemarrez le service systat
/etc/init.d/sysstat restart
3) Utilisation de la commande SAR
La commande SAR vous permettra d'afficher le contenu de votre systat dans la sortie standard (votre écran).
Exemple d'affichage de la commande sar -u (charge CPU):
Etat de la mémoire : sar - r
Etat du Swap: sar -W
Etat des IO disque : sar -b
IO par disque : sar -d
Enfin vous avez également la possibilité d'afficher le résultat de l'intégralité des commandes SAR via la commande:
sar -A
Enjoy! 🙂
Précisions :
*) SAR (pour « System Activity Report » et non « Source Approval Request » qui existe aussi) correspond au programme « sar » que l’on trouve dans beaucoup d’Unix (Solaris/AIX/etc.) -> https://en.wikipedia.org/wiki/Sar_(Unix)#References
*) SAR en lui-même ne permet pas d’avoir l’historique, mais de lire un fichier d’historique (option « -f ») Par défaut il l’état système qui correspond aux dernières minutes/heures selon le système.
*) Le paquetage « sysstat » de S. Godard contient le portage de « sar » sous Linux -> http://sebastien.godard.pagesperso-orange.fr/
*) Le paquetage « sysstat » fourni la commande « sacd » qui permet de garder l’historique dans « /var/log/sysstat/sa$(date +%d) » ; c’est la collecte à historiser qui est faite par le crontab « /etc/cron.d/sysstat »
Encore moi, pour une petite correction.
Le billet/article dit de remplacer les lignes ainsi :
– Debian remplacer :
5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1
par
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1
– Centos/RedHat/Fedora remplacer :
*/10 * * * * root /usr/lib64/sa/sa1 1 1
par
*/2 * * * * root /usr/lib64/sa/sa1 1 1
En faisant cela, certains se retrouveront avec des erreurs qui se manifestent par ce genre de mail (si pas de mail voir dans les logs):
From: Cron Daemon
Sent: dayname daynumber daymonth year 00:00
To: root@localhost
Subject: Cron command -v debian-sa1 > /dev/null && debian-sa1 60 2
flock: Resource temporarily unavailable
Normal… le script « sa1 » (appelé via « debian-sa1 » chez Debian/Ubuntu/etc.) permet de ne pas écraser l’historique d’un mois à un autre, puis appelle la commande « sacd » avec l’option « -L » qui permet de ne pas avoir de fichier corrompu en écrivant par deux processus en même temps. Et c’est ce qui arrive ici :
– Si on s’exécute toutes les (deux) minutes impaires, on se retrouve exécuté avec la seconde tâche de 23h59 ! Et le premier qui ouvre le fichier y écrit tandis que l’autre râle.
– Si on s’exécute toutes les (deux) minutes paires, on a moins de risque de tomber sur ce cas …sauf en cas de charge du serveur (sachant que beaucoup de tâches s’exécutent dans ces heures là) : la tâche de 0h00, 2 minutes après 23h58, ne pourra accéder au fichier si la tâche de 23h59, qui doit durer plus longtemps, n’a pas eu le temps de se terminer à temps et de passer la main sur le fichier.
Bref, pour une exécution toutes les deux minutes, je conseille plutôt :
– Debian/Ubuntu :
2-55/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1
– Centos/RedHat/Fedora remplacer :
2-55/2 * * * * root test -x /usr/lib64/as/sa1 && /usr/lib64/sa/sa1 1 1