Nagios est un formidable outil permettant de gérer d'immenses parcs de machine, d'afficher des plans d'architecture, des rapports d'erreurs, etc. Maintenant lorsque l'on a dans son "parc" personnel deux pauvres serveurs qui se battent en duel, passer des heures à paramétrer et maintenir un tel système n'est pas forcement rentable. Maintenant refaire soi-même à la main toute cette mécanique ne l'est pas non plus, voici donc une voie du milieu.

L'idée de base

Comme nous l'avons déjà vu, Nagios est un système de supervision évolué, doté d'une interface WEB, d'une très dense bibliothèque de greffons, d'une base de donnée et de tout le tremblement. Pour zapper joyeusement la case "je me prends la tête avec la configuration", on peut légitiment se demander s'il est pas possible de détourner ces greffons pour un usage un peu plus simpliste.

Prenons l'exemple du greffon qui fait "ping" (c'est le greffon le plus dispendieux de l'établissement !). Il se trouve dans le dossier /usr/share/nagios/plugins sous le nom check_ping. Tentons de le lancer avec les paramètres qui vont bien, ceux que l'on trouve dans /etc/nagios/objects/commands.cfg

Nous constatons d'abord qu'un greffon nagios est une simple commande qui communique avec son maître par le biais d'une ligne écrite dans la sortie standard et du code d'erreur retourné.

La ligne comporte une petite section précédant le signe - qui indique le nom du test, PING, et le status OK, WARNING ou CRITICAL. Après nous avons des indications sur ce qui c'est passé jusqu'au signe |, puis ce sont des mesures permettant d'évaluer les performances du test.

Le code de retour est très logiquement 0 si tout va bien et autre chose si ça coince.

Sachant que tous les greffons se comportent exactement de la même manière, que dans la majorité des cas les appeler avec -h en paramètre nous en donne la syntaxe, et que le cas échéant nous avons le fichier commands.cfg pour s'aider, pourquoi ne pas écrire un petit programme tout bête dont le seule rôle sera d'encapsuler le lancement de ces plugins et écrire dans la sortie standard en cas d'erreur.

Je rappelle qu'ici le but est de travailler avec deux pauvres machines, et que tout ceci n'est qu'une glutte adaptée à ce contexte et ce contexte uniquement, pas la peine de venir me faire la morale

Points de vue

Tant qu'à faire, autant améliorer un aspect qui me fatigue un peu (ou peut-être suis-je trop fatigué pour savoir comment faire) avec Nagios. Le cas est assez simple, lorsque je décris les services de la machine A, une partie de ceux-ci sont locaux, d'autres sont publiques. Par exemple la charge CPU est locale, un serveur HTTP est publique. Pour tester le service HTTP de ma machine A, il est plus fiable de ce placer sur la machine B et regarder si ce service fonctionne que de rester sur A. Mon point de vue sur le service sera donc de B sur A. Et lorsque je cherche à vérifier la charge, je vais rester sur A, il sera donc de A sur A.

In extenso, si je cherche à tester les services locaux de la machine B qui n'est pas celle qui exécute les tests (machine A). Mes services locaux sont à réaliser avec un point de vue de B sur B.

Dans mon petit code, pour chaque test je vais donc définir un point de vue. S'il est "local" (cas par défaut), c'est qu'il part de la machine qui teste vers la machine à tester. S'il est "remote", il part de la machine à tester vers elle-même. Et s'il est "autre chose", il par de n'importe quelle machine du réseau vers la machine à tester.

Après c'est au code de se débrouille pour lancer le greffon réellement localement, ou par l'intermédiaire d'un canal SSH vars la machine source du point de vue. Je pars donc du principe que les machines qui se surveillent ont leurs clefs correctement configurées.

Le script

Comme pour le backup via rdiff, l'idée est de régler cela en le minimum de ligne, mais en perl cette fois. D'ailleurs j'ai prévu de tout migrer définitivement vers ce langage, du moins tout ce qui relève du domaine du script.

Je ne vais pas vider le code ici, il n'a absolument aucun interêt, il ne fait, comme pour le backup, que fournir des fonctions qui vont être utilisées par un script principal, celui de supervision. Pour récuperer, vous pouvez aller ici.

Pour notre script de supervision, les choses sont ultra simples, nous disposons d'une commande pour définir le destinataire des alertes (define_alert), d'une autre pour définir une machine (define_host) et enfin d'une dernière pour ajouter un test (add_test). Après le tout est de prendre la bonne syntaxe et les bons greffons.

#! /usr/bin/perl

unshift(@INC,"/usr/share/mes_librairies/perl");
require "nagios.pm";

# test sur la machine qui test
if (define_host("machine_qui_teste", "192.168.0.1")) {
  # vérification de l'espace disque disponible
  add_test (label=>"Espace disque",
    command=>"check_disk -w 10% -c 5% -p /var -p /tmp -p /storage -p /home -p /");
}

# test sur une machine distante
if (define_host("machine_distante", "98.190.35.43")) {
  # un ping au cas où...
  my $is_alive = add_test (label=>"Vivant",
    command=>"check_ping -H HOST_ADDRESS -w 3000.0,80% -c 5000.0,100% -p 1");

  # pas la peine de continue si la machine est sur le toit.
  if ($is_alive) {
    # Demande de l'état d'un service local sur une machine distante (pov=remote)
    add_test (label=>"Espace disque", pov=>"remote",
      command=>"check_disk -w 10% -c 5% -p /var -p /tmp -p /storage -p /home -p /");

    # On vérifie que le ssh publique est disponible sur cette machine
    # en prenant comme origine du point de vue une autre machine qui a accès
    # au net.
    add_test (label=>"SSH", pov=>'machine_avec_acces_au_net',
      command=>"check_ssh  HOST_NAME");
  }  
}

# fin des tests, on ferme tout
mischief_managed();

Avouez que c'est un peu moins compliqué qu'une configuration Nagios au grand complet. En plus l'immense avantage est qu'en lançant ce script, vous savez tout de suite s'il fonctionne. Dés qu'une erreur est détectée, un message écrit dans la sortie standard. De même une liste de tous les états de toutes les machines est maintenue dans le fichier /var/lib/supervision (prendre soin de créer ce dossier avant de lancer le script).

Ensuite, il ne vous reste plus qu'à mettre cela dans une entrée du CRONTAB sur une période correspondant à vos besoins. L'utilisation de CRON permet de prendre en charge les erreurs et de les envoyer par mail à qui de droit.

Conclusion

Même si "supervision du pauvre" porte ici bien son nom, cela reste une approche pragmatique et très rentable car utilisant à plein tous les greffons de Nagios. Après de nombreuses petites optimisations sont possible mais en l'état cette librairie répond déjà, et ce depuis un certain temps déjà, à mes modestes besoins.

Commentaires