rstatd est un moyen simple et discret pour superviser une machine Linux (voire UNIX-Like comme Solaris). Plus simple que SNMP et présentant un faible overhead (empreinte mémoire et taux CPU).

Bien avant l’avènement de XML-RPC, dès 1986, Sun a planché sur le protocole ONC/RPC (Open Network Computing Remote Procedure Call) permettant de faire des appels distants à différents programmes entre machines. Autant dire que ce protocole est éprouvé et qu’il est très largement répandu. Sachez aussi que la norme qui en décrit les échanges (XDR) est toujours d’actualité (NFS, Firebird, HLA, …). La solution que je vais vous présenter dans ce billet s’appuie sur ce protocole.

Présentation de rpc.rstatd

rpc.rstatd est un utilitaire à installer et à configurer sur toutes les machines UNIX-Like (Linux, Solaris, BSD, …) que vous souhaitez surveiller. Il permet de collecter un nombre limité d’indicateurs du noyau Linux (listés dans le tableau suivant). Ces indicateurs sont peut-être limités en nombre, mais suffisant pour déceler un problème ou orienter les investigations sur de mauvaises performances.

L’intérêt de rpc.rstatd réside dans son faible overhead et la simplicité d’utilisation. L’overhead est lié à la sollicitation du processeur serveur (rstatd) collectant les indicateur. C’est-à-dire que plus on fera de demandes d’actualisation des statistiques, plus l’impact CPU augmentera — dans des proportions qui resteront toutefois très raisonnables, puisque le fait d’avoir un taux d’échantillonnage inférieur à une seconde est limité et que le programme est vraiment très léger. L’empreinte mémoire est limitée et constante, puisque le processus serveur ne stocke pas d’historique des mesures.

Une fois que tout est configuré, l’accès aux statistiques est simple. La plupart des programmes clients ne demandant que l’adresse IP de la machine à superviser ainsi qu’une liste des indicateurs à collecter. Pas de rechercher dans une arborescence comme avec SNMP ou WMI.

Indicateur	Description
Average load	Nombre moyen de processus simultanément en état «　Prêt (READY)　» durant la minute écoulée.
Collision rate	Nombre de collisions par seconde détectées sur le câble Ethernet.
Context switches rate	Nombre de commutations entre processus ou threads par seconde.
CPU utilization	Pourcentage de temps durant lequel le CPU est utilisé.
Disk rate	Taux de transfert disque.
Incoming packets error rate	Nombre d’erreurs par seconde détectée durant la réception des paquets Ethernet.
Incoming packets rate	Taux de réception de paquets Ethernet.
Interrupt rate	Nombre d’interruptions matériel par seconde.
Outgoing packets errors rate	Nombre d’erreurs par seconde détectée durant l’émission des paquets Ethernet.
Outgoing packets rate	Taux d’émission de paquets Ethernet.
Page-in rate	Nombre de pages lues depuis la mémoire physique, par seconde.
Page-out rate	Nombre de pages lues depuis la mémoire physique et stockées dans l’espace de swap, par seconde.
Paging rate	Nombre de pages lues depuis la mémoire physique ou depuis l’espace de swap, par seconde.
Swap-in rate	Nombre de processus déchargés de la mémoire physique et stockés dans l’espace de swap.
Swap-out rate	Nombre de processus chargés depuis l’espace de swap et rechargés dans la mémoire physique.
System mode CPU utilization	Pourcentage de temps durant lequel le CPU est utilisé par le système d’exploitation.
User mode CPU utilization	Pourcentage de temps durant lequel le CPU est utilisé par des processus utilisateurs.

Accès aux statistiques côté client

La plupart des logiciels de test de charge (Performance Center, LoadRunner, Silk Performer, Rational ou JMeter) supportent ou acceptent un module permettant de collecter les statistiques d’une machine Linux durant un tir. Par exemple, ceux qui utilisent JMeter pourront y brancher un collecteur pour rstatd.

Si vous avez besoin d’un simple outil de supervision ou de vérifier la configuration côté client, je vous conseille JPerfmeter, un utilitaire Java multiplateforme simple à prendre en main :

rstatd_JPerfmeter_outil_Java_supervision — Présentation de l'application JPerfmeter

Les aspects principaux de l’interface :

Graphiques des statistiques collectées en temps-réel. Avec la possibilité de faire glisser un curseur d’historique.
Accès à la configuration de l’utilitaire par un clic droit.
Nom ou adresse IP du serveur sur lequel tourne rstatd.
Indicateurs système à collecter.
Taux d’échantillonnage et durée de l’historique. Plus la durée d’échantillonnage sera élevée, moins le processus serveur rpc.rstatd perturbera le comportement du système supervisé.

Installation

Téléchargement et compilation

Il ne me semble pas qu’il existe de paquet contenant rpc.rstatd. Il nécessite au préalable l’installation de portmap (pour lequel des paquets existent). On peut télécharger les sources à partir de Sourceforge. Puis on le compile (Attention à l’option --prefix qui serait à passer au programme de préparation de la compilation (./configure), car en fonction de celle-ci – ou de l’absence de celle-ci, l’installation du serveur peut être dans le répertoire /usr/local/bin).

Configuration du démon

Que vos services systèmes soient gérés par xinetd ou inetd, le principe est à peu près le même. Il faut ajouter un fichier texte nommé rstatd dans le répertoire /etc/xinetd.d/rstatd ayant, par exemple, ce contenu :

# default: off # description: An xinetd internal service which rstatd's characters back to clients. service rstatd { type = RPC rpc_version = 2-4 socket_type = dgram protocol = udp wait = yes user = root only_from = 10.0.95.0/24 log_on_success += USERID log_on_failure += USERID server = /usr/sbin/rpc.rstatd disable = no }

On adaptera la variable server avec l’emplacement du binaire (cf. remarque précédente sur la compilation). Ainsi que la variable only_from si vous souhaitez restreindre la plage des adresses IP des machines qui souhaitent accéder au service. enfin, on redémarrera le gestionnaire de services avec la commande

root# /etc/rc.d/init.d/xinetd restart

Test de l’installation et dépannage

Bien sûr, vous pouvez tester la bonne installation directement du côté client. Il existe des tests côté serveur, par exemple :

root# rup 127.0.0.1 qui ne doit pas retourner rup: 127.0.0.1: RPC: Program not registered.
rcpinfo -p qui devrait lister le service rpc.rstatd.

Si cela ne marche toujours pas, vous pouvez vérifier du côté du pare-feu Linux qui doit certainement bloquer le port 110 utilisé par ONC / RPC.

Sources documentaires

Pour aller plus loin sur le sujet, vous trouverez plusieurs informations sur la page Wikipédia de présentation. Sachez que si vous souhaitez développer un outil basé sur le protocole ou exploitant un composant serveur, il existe une implémentation Java ainsi que pour .Net.