Nagios, qui s'appelait précédemment NetSaint, est un outil de supervision pour parc de serveurs. Il permet d'auditer en permanence des machines, des services sur ces machines, de recevoir des alertes en cas de problème et d'éditer des rapports sur les activités passées.

Le coeur de système est écrit en C en est contrôlable à travers une application Web à base de CGI accessible via Apache. Il existe une alternative à l'application web en question, il s'agit de Oreon. J'ai tenté de l'installé mais il est d'une lourdeur assez déconcertante, donc pour l'instant, je reste sur l'IHM de base fournit avec nagios.

Installation

Sous Mandriva, rien de sorcier, juste un urpmi nagios nagios-www permet d'installer le coeur et l'application web. Apache sera redémarré et le tout accessible via http://localhost/nagios.

Premier constat, dieu que c'est moche, limite glauque. Vieille fontes avec serifs, noir et blanc, c'est du pure Web 0.1 béta. Mais ça marche, c'est déjà cela. Et ce n'est que le visuel au fond, l'important est tout de même le coeur de supervision. Mais là non plus, ce n'est pas très rose.

Configuration

Nagios fait le café, ou presque. Il est sans aucun doute très complet mais cela se paye par un paramétrage digne d'un roman de Kafka. Je me suis frappé la config pour 4 pauvres serveurs, et j'imagine à peine l'enfer lorsqu'il y en a 100 ou 1000. Pour mieux comprendre, imaginons que nous ayons un serveur à rajouter et que nous voudrions auditer la bonne marche de son service HTTP. L'idée est donc d'ajouter ce nouveau serveur, d'y coller un service qui vérifie que le http est allumé et que la page de garde contient la phrase "Ceci est le site Web de Gaston".

Tout d'abord le serveur. Disons qu'il s'appelle Gaston. Nous allons donc créer un fichier /etc/nagios/servers/gaston.cfg dans lequel nous allons écrire :

Là ça passe où ça casse mais au moins cela donne la ligne où ça plante. Une fois que tout est correcte, on redémarre le service :

Il suffit d'aller sur l'URL de nagios, de faire un refresh pour voir un nouveau host apparaître. Dans un premier temps il apparaît en gris car la mise à jour des status est mise dans une file d'attente. Au bout de 5 minutes, cela devrait passer au vert, gaston est donc valide.

Deuxième étape, éditer à nouveau notre fichier gaston.cfg pour y ajouter le service à auditer :

En l'état cela ne marchera pas encore. En effet, il va falloir commencer par créer la commande Nagios check_http_text. En effet Nagios est fournit avec une foultitude de plugins permettant de tester un grand nombre de services. Mais pour une raison étrange, les plugins, qui sont de simple exécutables contenus en /usr/lib/nagios/plugins, ne sont pas reconnus directement. Il faut d'abord préalablement les déclarer dans le fichier /etc/nagios/commands.cfg. Une grande partie des plugins de base sont déjà configurés, par exemple s'il s'agissait de simple savoir si le serveur web était présent, la commande check_http aurait suffit. Mais là nous avons besoin d'un peu plus, il va donc falloir ajouter à la fin du fichier /etc/nagios/commands.cfg

Nous avons donc créé une commande check_http_text qui va invoquer le plugin check_http avec comme premier paramètre l'adresse IP du serveur, et en second paramètre une expression régulière à vérifier dans la page de garde. Ce paramètre correspond à ce qui se trouve après le point d'exclamation dans le service que l'on a écrit un peu plus haut check_http_text!Ceci est le site Web de Gaston. A notre que si nous avions créé une commande avec plusieurs paramètres, nous aurions rajouté des $ARG2$ ou $ARG3$ et aussi rajouté dans le service des paramètre précédé de leur point d'exclamation. Y'a pas à dire c'est totalement idiot comme formalisme.

Maintenant, on redémarre nagios et miracle, apparaît dans la liste des services notre nouveau audit.

A ce stade, vous avez presque toute les billes pour configurer nagios. C'est long, c'est fastidieux, on se trompe souvent mais on y arrive. L'ensemble est stable et ne plante pas, c'est déjà ça. Vous pouvez grouper les serveurs par groupe de serveur (objet hostgroup) et les services par groupe de service (servicegroup). Tout cela est dans la documentation et un exemple est présent dans /etc/nagios/localhost.cfg.

La dernière chose qu'il reste à voir pour passer cela en production sont les services locaux. En effet, une machine avec Nagios peut auditer tous les services publiques des autres machines (http, ftp, ldap, dns, etc...), elle peut aussi auditer ses ressources internes (état des disques, processus, charge, etc..), mais ce qu'elle ne peut pas faire c'est auditer les processus interne des autres machines. Par exemple connaître l'état de l'espace disque du serveur gaston.

Audit de services internes à distance

Ne vous attendez pas à un système génial par appels RPC et synchronisation des données. La solution Nagios pour ce cas de figure consiste à installer un nouveau service sur chaque machine qui va servir de relais. Ce service s'appelle nrpe. Il s'agit d'un petit serveur qui va se mettre en écoute d'un port de la machine distante et répondre aux requêtes de votre nagios. Lorsqu'il reçoit une demande, il va exécuter un plugin nagios en local et transmettre sa réponse à Nagios. Conséquence directe, nrpe a son propre fichier de configuration qui n'a rien à voir avec celui de nagios. Donc si vous pensiez paramétrer cela à distance c'est raté.

Pour reprendre l'exemple de l'audit à distance de l'état des disques. Nous allons donc déjà installer sur gaston le service nrpe via un urpmi nrpe. Sur la machine nagios nous allons installé le plugin nrpe via un urpmi nrpe-plugin. Ensuite nous allons éditer sur gaston le fichier /etc/nagios/nrpe.cfg et localiser la ligne contenant command[check_disk1]. Vous commencez à comprendre, cette ligne publie via nrpe un paramétrage spécifique du plugin check_disk qui pour l'instant utilise la partition /dev/hda1. Changer la référence de la partition pour par exemple auditer le répertoire /var en /dev/sda3. On remplace donc hda1 par sda3. Le reste ne change pas. Ensuite il faut sauver et redémarrer nrpe via un service nrpe restart.

Maintenant il faut, au niveau du serveur Nagios, créer une nouvelle commande qui prends en charge le plugin nrpe. Pour cela il faut à nouveau édite le fichier /etc/nagios/commands.cfg et ajouter à la fin :

Maintenant nous allons ajouter un nouveau service à /etc/nagios/servers/gaston.cfg en ajoutant à la fin du fichier :

Notez le paramètre !check_disk1, il va être transmis à la commande et remplacer l'argument $ARG1$ avant que le plugin nrpe soit exécuté. Le serveur gaston va recevoir la demande de plugin check_disk1 et va donc exécuter en local le plugin check_disk sur la partition /dev/sda3. Le résultat est renvoyé à nrpe, qui le revois au plugin nrpe sur la machine nagios qui va le rendre à nagios lui-même. ouf ! Dans la série pourquoi faire simple lorsque l'on peut faire compliqué...

conclusion

Tout d'abord les points forts :

• Grande richesse de plugins. On peut tester à peu près tout d'un serveur FTP à un annuaire LDAP en passant par l'interrogation d'un routeur via SNMP
• Très rapide, tout est écrit en C, y compris les CGI. L'ensemble prends peu de ressources
• L'architecture des objets est bien pensée même si logique. Nagios gère des groupes de serveurs, un group de serveur gère un ensemble de serveurs, un serveur gère un ensemble de services. Et les services peuvent eux-mêmes être associés en groupe de service (ex. Les services Web).
• Le paramétrage est orienté objet. C'est à dire que l'on peut définir un template de service, qui hérite d'un autre template et avoir un service qui hérite du tout. Un peu comme des feuilles CSS.
• Tout est paramétrable, jusqu'aux horaires de notification.

Tout d'abord les points faibles :

• La syntaxe des fichiers de configuration est absolument idiote. On se croirait revenu à l'époque du Cobol où même la taille de la tabulation compte. Des fichiers XML seraient autrement plus intelligent respectant mieux la logique architecture de ce type de produit.
• Les plugins sont à déclarer en double ce qui est idiot. Et ça l'est encore plus de par le changement de syntaxe (passage des arguments de l'exécutable à ces stupides point d'exclamation). La logique est sûrement de simplifier les appels mais alors pourquoi ne pas avoir utilisé le même système de templates que pour le reste, où chaque attribut serait un paramètre de la commande ?
• Impossible de mettre des symboles autres que de l'alpha numérique sans accent dans les descriptions.
• Le système de groupe de services et de hosts est une très bonne idée mais prise à l'envers. Ce n'est pas pratique de définir un groupe de service et d'y mettre tous les services associés. On aurait préféré un attribut group dans les services, celait aurait été largement plus simple.
• L'utilisation de NRPE est une hérésie pure et simple. Elle rends impossible la centralisation des configurations. Je n'ai rien contre un service sur la machine distante qui serve de Proxy mais il faudrait que la configuration en soit sur le serveur Nagios qui puisse, à distance, lancer un plugin via un attribut sur le service de type remote $HOSTNAME$.
• L'IHM est triste à mourir
• Version imprimable
• PDF version

Commentaires