Surveiller une machine Linux peut se faire avec différent logiciel. Nous choisissons Munin pour sa simplicité « out of the box » sur une distribution Ubuntu. Aussitôt installé, on dispose de jolies graphiques pour suivre l’état du système dans un navigateur.
L’application Munin permet par ailleurs d’envoyer des alertes quand une variable sort d’une limite prédéfinie. L’alerte peut être un mail ou un script appelé par Munin. L’avantage du mail est qu’il ne nécessite aucun développement pour être mis en oeuvre. Le client mail du N900 se chargeant de faire la notification. Le mail présente aussi l’avantage de pouvoir être lu en asynchrone mais le gros désavantage c’est que une fois faite la notification de l’arrivée d’un nouveau message, l’utilisateur qui est submergé de mail risque de ne pas prendre en compte une alerte au fin fond de sa boîte de réception.
Des améliorations au mail peuvent être trouvées par l’utilisation d’une boîte dédiée par exemple mais cela ne change pas le problème de fond: une alerte doit être visible et se signaler en permanence. L’idée du voyant vert qui passe au rouge s’impose et ce voyant ne doit pas être une application mais un widget sur le bureau.
Il nous faut donc faire le lien entre les informations que Munin produit avec le bureau Hildon. Le monde Linux à alors de nombreux atouts. Contrairement au monde Microsoft/Window où la facilité d’entrée permet au tout venant de faire des applications qui seront mal conçues, Linux à cause d’une barrière d’entrée plus élevée et, grâce à l’open-source et le libre, crée des applications mieux conçus et plus modulaires. Ainsi dans notre cas, surveiller un serveur Linux équipé de Munin via un mobile sous Maemo 5 est un jeu d’enfant.
Tout d’abord on peut laisser en place la notification par mail et décider de se spammer pour les alertes critiques. Ensuite on s’aperçoit que les pages web générées par Munin ne contiennent aucune information textuelle sur l’état du serveur: Munin produit des graphiques sous forme d’images. Mais les développeurs de munin ont bien architecturé l’application. Ainsi dans le fichier /var/lib/munin/limits il y a l’état de toutes les sondes surveillées en texte. Il suffit de le rendre disponible depuis le web pour que le N900 mette à jour les widgets.
De même historiquement les utilisateurs de Linux sont plus conscients de leur informatique et l’outillage de l’administrateur est un souci permanent voire même le premier souci puisque un système qui n’est pas bien administré, fonctionnera mal et ne sera pas utilisé ! Donc il n’est pas étonnant de voir parmi les applications produites par la communauté pour le N900, un grand nombre d’applications d’administration parmi lesquelles Queen BeeCon Widget (QBW). Ce dernier se présente sous la forme de petits widget dont la couleur change en fonction du code de sortie d’une commande arbitraire. Il y a par défaut 3 états:
- icône verte quand le code de sortie est 0
- icône orange quand le code de sortie est 1
- icône rouge quand le code de sortie est 2
Commençons par la validation da la connectivité. Il s’agit de faire un simple ping sur le serveur. Dans le cas d’un serveur derrière un routeur, on se contentera d’un ping sur le routeur. Il suffit de créer un widget QBW avec pour commande:
tokenfound=`sudo ping -c 1 -q 127.0.0.1 | grep "1 packets received" | wc -l'`;
if [ $tokenfound -eq 1 ]; then echo "OK"; exit 0; else echo "KO"; exit 2; firemplacer l’ip 127.0.0.1 par celle du serveur ou celui du routeur (adresse externe)
Pour vérifier que le serveur web répond du point de vue d’un utilisateur réel, il suffit de s’assurer que le résultat d’une url de référence contient bien un mot-clé. Dans le cas d’un apache fraichement installé on peut vérifier que la page racine contient bien « It works ». Voici la commande qui sera associée au widget QBW:
tokenfound=`wget -O - -T 3 -t 1 -q http://127.0.0.1/ | grep "It works" | wc -l'`; if [ $tokenfound -eq 1 ];
then echo "OK"; exit 0; else echo "KO"; exit 2; fiDès lors que le serveur est joignable et que le serveur web apache répond, on peut vérifier que les pages html générées par munin sont présentes. Voci la commande pour QBW:
tokenfound=`wget -O - -T 3 -t 1 -q http://127.0.0.1/munin | grep "This page was generated by <a href="http://munin-monitoring.org/">Munin</a> version 1.4.4" | wc -l`; if [ $tokenfound -eq 1 ]; then echo "OK"; exit 0; else echo "KO"; exit 2; fi
Bien sûr le script précédent gagnerait à vérifier la date de mise à jour de la page !
Une fois que le fonctionnement de munin est acté, on peut passer en revue les sondes intéressantes dans la surveillance du serveur. Prenons l’exemple des sonde de température. Disons que l’on veut surveiller toutes sondes confondues si au moins l’une pose un problème. Dans le cas d’une sonde munin on peut avoir envie d’accéder au graphique de la sonde. Disons que lorsque l’on tape sur le radar du widget, le navigateur s’ouvre sur le graphique de la sonde. Il suffit de créer un widget avec la commande:
if [ $QBW_HOTSPOT_PRESS -eq 9 ]; then dbus-send --system --type=method_call --dest=com.nokia.osso_browser
/com/nokia/osso_browser/request com.nokia.osso_browser.load_url
string:"127.0.0.1/munin/localdomain/localhost.localdomain/sensors_temp-day.png"; fi;
limits_file=/home/user/limits_sensors_temp; wget -O - -T 3 -t 1 -q http://127.0.0.1/munin/limits
| grep sensors_temp > $limits_file; if [ $? -ne 0 ]; then echo "??"; exit 1; fi;
tokencount=`cat $limits_file | grep "critical" | wc -l`; if [ $tokencount -gt 0 ]; then echo "critical";
exit 2; else tokencount=`cat $limits_file | grep "warning" | wc -l`; if [ $tokencount -gt 0 ];
then echo "warning"; exit 1; else echo "OK"; exit 0; fi;fi