Nagios - le moniteur de supervision

La gestion d'un parc de serveur est un travail de chaque instant. Un bon administrateur système doit savoir à tout moment l'état des différentes machines et des différents services. Un autre aspect clé est que l'administrateur ne peut pas se permettre de passer son temps devant un tableau avec des voyants verts en attendant qu'un voyant passe au rouge pour agir. Son temps est occupé à d'autres tâches et il ne peut donc pas surveiller le tableau de statut en permanence.

L'examen journalier des logs systèmes est un bon début. Cependant, si un problème survient, on s'en rend compte seulement le lendemain. Ce qui peut être très (trop ?) tard.

Pour se simplifier le travail, nous allons utiliser un moniteur de supervision. Le but d'un tel programme est de surveiller les services et les machines se trouvant sous notre responsabilité. Si un problème survient, le moniteur de supervision nous prévient (email, SMS, coup de téléphone,…) ou peut entreprendre certaines actions (relancer un service, tuer un processus, demander un reboot,…).

Le moniteur de supervision que nous allons envisager est Nagios qui est un des plus connus et des plus utilisés.

Page officielle de Nagios

L'architecture de base de Nagios est simple; elle est composée d'un scheduler, d'une interface web et de greffons.

Nagios est avant toute chose un moteur gérant l'ordonnancement des vérifications, ainsi que les actions à prendre sur incidents (alertes, escalades, prise d'action corrective).

L'interface web est la partie graphique visible via un serveur web tel que Apache et qui va permettre à l'administrateur d'avoir une vue d'ensemble de son réseau.

Les greffons de Nagios (ou sondes ou plugins) sont des petits scripts ou programmes qui sont la base des vérifications.

Le projet Nagios fournit en standard bon nombre de greffons de base, mais la simplicité de leur mode de fonctionnement nous a permis d'en écrire un certain nombre pour nos besoins propres (comme un vérificateur pour une application maison).

Pour plus d'information sur l'écriture de greffons, veuillez vous reporter à la section Techniques avancées.

Avant d'installer Nagios, il est préférable d'installer le serveur web Apache (c'est plus commode pour tester le bon fonctionnement de Nagios). Sans entrer dans les détails d'installation d'Apache, vous pouvez déjà avoir un serveur web fonctionnel en entrant la commande suivante :

sudo apt-get install apache2

Ensuite, il ne vous reste plus qu'à installer Nagios :

sudo apt-get install nagios-text

A la fin de l'installation, Nagios va vous demander d'introduire un mot de passe pour nagiosadmin.

Ici, pour des raisons de simplicité, nous utilisons la version text de Nagios; c'est-à-dire que les informations concernant les services sont stockés dans des fichiers textes. Il existe également une version mySQL dont nous ne parlerons pas dans ces quelques lignes.

Pour configurer le serveur Apache de telle manière que Nagios soit accessible, il vous suffit de faire un copier-coller du fichier /etc/nagios/apache.conf dans /etc/apache2/httpd.conf. Ensuite, vous devez recharger la configuration d'Apache à l'aide de la commande suivante :

sudo /etc/init.d/apache2 reload

Notez que selon les situations, la configuration a été assurée par le gestionnaire de paquets. Vous devriez avoir accès à la page principale de Nagios une fois que vous avez introduit votre mot de passe en consultant l'URL suivante, le login étant "nagiosadmin" :

http://hostname/nagios/

Si ce n'est pas le cas, vérifier la configuration de votre serveur HTTP Apache.

La configuration de Nagios peut paraître compliquée au premier abord. Il y a beaucoup de fichiers de configuration qui se trouvent dans /etc/nagios. Voyons ensemble une configuration basique.

La première chose à faire est d'ajouter des utilisateurs qui pourront se connecter à l'interface web de Nagios. Les droits d'accès de l'interface web se gèrent avec htpasswd qui est un utilitaire fournit avec le serveur Apache.

Pour ajouter un utilisateur, vous pouvez utiliser la commande suivante :

sudo htpasswd /etc/nagios/htpasswd.users <username>

Il faut également donner les droits d'accès à cet utilisateur en éditant le fichier /etc/nagios/cgi.cfg. Les lignes qui nous intéressent sont les suivantes ; elles sont composées d'une ligne de nom d'utilisateur (entrés à l'aide de htpasswd) séparés par des virgules.

• authorized_for_system_information : indiquent quels sont les utilisateurs pouvant voir l'état des services.
• authorized_for_configuration_information : indiquent quels sont les utilisateurs pouvant voir la configuration de serveur Nagios.
• authorized_for_system_commands : indiquent quels sont les utilisateurs pouvant exécuter des commandes systèmes au travers de l'interface de Nagios.
• authorized_for_all_services : indiquent quels sont les utilisateurs pouvant voir l'état de tout les services (par défaut, on voit uniquement les services pour lesquels l'utilisateur est une personne de contact).
• authorized_for_all_hosts : idem que ci-dessus mais pour les hôtes (les machines).
• authorized_for_all_service_commands : indiquent quels sont les utilisateurs pouvant exécuter des commandes pour tous les services (par défaut, on peut exécuter des commandes uniquement sur les services pour lesquels l'utilisateur est une personne de contact).
• authorized_for_all_host_commands : idem que ci-dessus mais pour les hôtes (les machines).

Une fois que les droits d'accès ont été indiqués, vous pouvez vous connecter avec votre nouvel utilisateur au travers de l'interface web.

Afin de se simplifier la vie, nous allons d'abord examiner la configuration basique de Nagios, ensuite, nous envisagerons la configuration des services de surveillance.

Nous allons commencer par configurer les périodes de temps qui préoccupe notre serveur. Ces périodes de temps se configurent dans le fichier /etc/nagios/timeperiods.cfg.

Vous remarquerz que certaines périodes de temps sont déjà indiquées dans le fichier. Ces périodes sont 24x7 qui signifie 24h/24h et 7j/7j; workhours qui est l'horaire habituel de travail; nonworkhours qui définit l'horaire habituel de non-travail.

Ces périodes peuvent être reconfigurées à votre guise pour coller à l'organisation de votre surveillance. Par exemple, sur le serveur de supervision, j'ai ajouté l'horaire service_open de la manière suivante :

define timeperiod{
        timeperiod_name service_open
        alias           Heures de service
        monday          07:00-22:00
        tuesday         07:00-22:00
        wednesday       07:00-22:00
        thursday        07:00-22:00
        friday          07:00-22:00
        saturday        07:00-22:00
        }

Les mots clés utilisés pour la configuration d'une plage horaire se passent de commentaires.

Cet horaire indique les périodes d'activité de certains services. Les définitions des plages horaires nous serviront dans la suite de la configuration.

Les personnes de contacts sont les personnes physiques à contacter en cas d'incidents. Quand un problème survient, Nagios va notifier ces personnes d'après les degrés de notification.

Les personnes de contacts se configurent dans le fichier /etc/nagios/contacts.cfg et les entrées ont un format similaire à celui-ci :

define contact{
        contact_name                    ostaquet
        alias                           Olivier Staquet
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,u,r
        service_notification_commands   notify-by-email,notify-by-sms
        host_notification_commands      host-notify-by-email,host-notify-by-sms
        email                           username@domaine.net
        pager                           +329999999999
        }

Voici à quoi servent les différents champs :

• contact_name : pseudo de la personne de contact, ce pseudo sera utilisé dans d'autres fichiers de configuration.
• alias : nom complet de la personne de contact.
• service_notification_period : période de temps durant laquelle le contact peut être notifié d'un problème qui survient pour un service. Les périodes sont définies dans le fichier /etc/nagios/timeperiods.cfg.
• host_notification_period : période de temps durant laquelle le contact peut être notifié d'un problème qui survient pour un hôte (un serveur). Les périodes sont définies dans le fichier /etc/nagios/timeperiods.cfg.
• service_notification_options : états des services pour lesquels le contact doit être notifié. Les lettres qui suivent signifient :
  • w : le service est en état avertissement (warning).
  • u : le service est en état inconnu (unknown).
  • c : le service est en état critique (critical).
  • r : le service est revenu dans un état OK (recovery).
• host_notification_options : états des hôtes (machines) pour lesquels le contact doit être notifié. Les lettres qui suivent signifient :
  • d : l'hôte est éteint (down).
  • u : l'hôte est injoingnable (unreachable).
  • r : l'hôte est à nouveau accessible (recovery).
• service_notification_commands : commandes à utiliser pour notifier un état pour un service. Ces commandes sont décrites dans le fichier /etc/nagios/misccommands.cfg.
• host_notification_commands : commandes à utiliser pour notifier un état pour un hôte. Ces commandes sont décrites dans le fichier /etc/nagios/misccommands.cfg.
• email : email de la personne de contact.
• pager : numéro de pager pour la personne de contact (à utiliser aussi pour les notifications par SMS).

Les groupes de contacts sont des groupes regroupant plusieurs contacts. On utilisera cette notion de groupe dans les déclarations concernant les hôtes et les services à surveiller.

Les groupes de contacts se définissent dans le fichier /etc/nagios/contactgroups.cfg et les entrées ont un format ressemblant à ceci :

define contactgroup{
        contactgroup_name       admins-ubuntu
        alias                   Administrateurs machines Ubuntu
        members                 ostaquet,david,manu
        }

Il n'est pas nécessaire d'expliquer les champs plus en détail.

La surveillance de services et d'hôtes s'articule autour de plusieurs fichiers de configuration et ces fichiers sont tous liés les uns aux autres. C'est pour cela que je vais plutôt envisager un petit exemple plutôt que de me lancer dans une explication détaillée de toutes les options.

Remarque : Les explications concernant les différentes options sont disponibles sur votre serveur Nagios au travers de l'interface web. En haut à gauche de l'écran, il y a un lien Documentation qui mène directement à la doc. Elle explique exhaustivement les différents paramètres.

Notre exemple consiste en deux hôtes (un serveur mail et un serveur de fichier). Le serveur mail possède un service SMTP et un service IMAP. Le serveur de fichier possède un service NFS. Ces deux hôtes sont connectés sur un routeur-switch qui est le lien vers l'extérieur. Nous allons tester ces différents hôtes et services.

Tout d'abord, nous allons définir notre fichier d'hôtes. Ce fichier se trouve dans /etc/nagios/hosts.cfg.

define host{
        use                     generic-host
        host_name               router
        alias                   Routeur vers exterieur - connexion skynet
        address                 192.168.0.254
        check_command           check-router-alive
        max_check_attempts      20
        notification_interval   60
        notification_period     24x7
        notification_options    d,u,r
        }

define host{
        use                     generic-host
        host_name               fileserver
        alias                   Serveur fichiers
        address                 192.168.0.10
        check_command           check-host-alive
        max_check_attempts      20
        notification_interval   60
        notification_period     24x7
        notification_options    d,u,r
        }

define host{
        use                     generic-host
        host_name               mail
        alias                   Serveur mail
        address                 192.168.0.20
        check_command           check-host-alive
        max_check_attempts      20
        notification_interval   60
        notification_period     24x7
        notification_options    d,u,r
        }

Ce qu'il est important de remarquer dans ces quelques lignes, c'est le fait que tous utilisent un modèle (template) qui définit un comportement commun de base pour tous les hôtes. Personnellement, je n'ai pas modifié l'entrée generic-host ajoutée automatiquement pas Nagios.

Une autre chose à laquelle vous devez faire attention, ce sont les noms d'hôtes. En effet, ce sont ces noms qui serviront dans les autres fichiers de configuration (notamment, pour attacher un service à un hôte).

Enfin, vous remarquez que pour chaque hôte, on a indiqué quel commande de vérification est utilisée. Ces commandes sont, soit des commandes de bases de Nagios, soit des commandes qui vous ajouté dans le fichier misccommands.cfg. Vous pouvez obtenir toute la liste des commandes disponibles à travers l'interface web de Nagios (lien Configuration, Commands).

Pour que les notifications soient effectives pour les hôtes, les hôtes doivent être mis dans des groupes d'hôtes. Dans ces groupes d'hôtes, un (ou plusieurs) groupe de contact est assigné. C'est-à-dire que si il y a un problème sur un hôte et que le degré de notification est atteint, les contacts du groupes d'hôtes sont notifiés. Les groupes d'hôtes sont définis dans le fichier /etc/nagios/hostgroups.cfg.

Ici, nous allons déterminer deux groupes d'hôtes : un pour les machines et un pour la connectique.

define hostgroup{
        hostgroup_name  connectique
        alias           Routeurs, firewalls et gateway
        contact_groups  admins-router
        members         router
        }

define hostgroup{
        hostgroup_name  ubuntu
        alias           Machines Ubuntu
        contact_groups  admins-ubuntu
        members         mail,fileserver
        }

Avec les groupes d'hôtes et les groupes de contacts, on peut subdiviser les machines par zone géographique ou par compétences. De cette manière, on notifie le groupe de contact qui peut intervenir au plus vite.

L'avant dernière étape de configuration est de définir quels sont les services à surveiller. Ces services sont toujours attachés à un hôte. Les informations concernant les services sont contenues dans le fichier /etc/nagios/services.cfg.

Dans notre cas, nous surveillons les services de nos machines de la manière suivante :

define service{
       use                             generic-service
       host_name                       router
       service_description             PING
       is_volatile                     0
       check_period                    24x7
       max_check_attempts              3
       normal_check_interval           5
       retry_check_interval            1
       contact_groups                  admins-routers,admins-ubuntu
       notification_interval           60
       notification_period             24x7
       notification_options            c,r
       check_command                   check_ping!100.0,20%!500.0,60%
       }

define service{
        use                             generic-service
        host_name                       mail
        service_description             SMTP
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              3
        normal_check_interval           3
        retry_check_interval            1
        contact_groups                  admins-ubuntu
        notification_interval           60
        notification_period             24x7
        notification_options            w,u,c,r
        check_command                   check_smtp
        }

define service{
        use                             generic-service
        host_name                       mail
        service_description             IMAP
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              3
        normal_check_interval           5
        retry_check_interval            1
        contact_groups                  admins-ubuntu
        notification_interval           60
        notification_period             service_open
        notification_options            w,u,c,r
        check_command                   check_imap
        }

Ce qu'il faut noter au travers de ces quelques lignes est la manière dont on peut passer des paramètres aux commandes. Dans la définition du service ping pour le routeur, on indique les différents arguments avec des ! (point d'exclamation). Dans ce cas, cela signifie que l'on passe en état warning lorsqu'on perd plus de 20% des paquets ou si le temps de réponse est > 100ms. On indique également que l'on passe en état critical lorsqu'on perd plus de 60% des paquets ou si le temps de réponse est > 500ms.

La dernière étape est la configuration du fichier /etc/nagios/escalations.cfg.

define serviceescalation{
        host_name                       router
        service_description             PING
        first_notification              2
        last_notification               6
        contact_groups                  router-admins
        notification_interval           0
        }

Pour démarrer ou arrêter Nagios, vous pouvez le faire en ligne de commande de la manière suivante :

 sudo /etc/init.d/nagios start
 sudo /etc/init.d/nagios stop

Pour recharger la configuration de Nagios (et en même temps la tester), utilisez la commande suivante :

 sudo /etc/init.d/nagios reload

Lorsqu'on fait de la supervision, on fait essentiellement de la notification par email. C'est la méthode la moins coûteuse et la plus aisée à mettre en place.

Cependant, si votre serveur mail ou la ligne internet est inaccessible, l'email n'arrive jamais (ou vous ne savez pas le lire) et vous ne savez donc pas prendre les mesures qui s'imposent.

Une solution est d'utiliser un serveur de SMS (ou Texto). Il existe des solutions clé sur porte proposées par la plupart des opérateurs de téléphonie mobile. Mais ces solutions sont assez coûteuse si vous devez envoyer un SMS de temps en temps.

Nous avons adopté une solution basique qui fonctionne bien pour les petits volumes; il s'agit de piloter un GSM directement par le serveur Ubuntu en utilisant un câble data USB. La plupart des GSM conviendront à cet usage, l'unique condition est que le GSM possède un modem intégré qui répond aux commandes AT.

Remarque : Certains Nokia peuvent poser des problèmes de compatibilités car ils utilisent un protocole propriétaire à la firme finlandaise.

Nous avons choisi un GSM de marque Siemens AX75 et son câble data DCA-510 pour effectuer nos notifications SMS. Il suffit juste d'acheter une carte prépayée ou un abonnement uniquement SMS pour pouvoir se connecter au réseau de l'opérateur mobile. Nous avons choisi Siemens car les câbles data servent également à recharger le téléphone cellulaire via l'alimentation de la fiche USB. En effet, sur la plupart des mobiles, vous ne pouvez pas connecter le cordon d'alimentation et le câble data en même temps. C'est un des points à surveiller quand vous acheterez le GSM servant à la notification.

Pour piloter le GSM, nous avons besoin de la bibliothèque gsmlib. Cette bibliothèque se trouve dans le paquet gsm-utils du dépôt Universe. Pour installer le paquet, introduisez la commande suivante :

 sudo apt-get install gsm-utils

Ensuite, connectez le GSM via son câble data à un des connecteurs USB. Si tout se passe bien, le système Hotplug va charger le module usbserial et vous obtenez une device supplémentaire /dev/ttyUSB0. Pour vérifier ceci, entrez cette commande :

 sudo ls -al /dev/ttyUSB*

Si vous n'avez pas de ttyUSBx, chargez le module manuellement :

 sudo modprobe usbserial

Le paquet gsm-utils fournit quelques commandes pour dialoguer avec le GSM. Pour vérifier si le GSM répond bien, introduisez la commande suivante :

 sudo gsmctl -d /dev/ttyUSB0 ALL

Vous devriez obtenir toutes les informations disponibles sur le GSM.

Maintenant, essayez d'envoyer un SMS de la manière suivante :

 sudo gsmsendsms -d /dev/ttyUSB0 +3299999999 "Nagios - Test SMS OK"

Si tout se passe bien, vous n'avez plus qu'à configurer Nagios pour qu'il puisse envoyer des SMS (en utilisant le champ pager des contacts).

• Vous devez autoriser l'utilisateur nagios à utiliser les commandes modems en l'ajoutant au groupe d'utilisateur dialout.
• Vous devez configurer la commande permettant à Nagios d'envoyer des SMS. Pour ce faire, j'utilise les commandes suivantes définies dans le fichier /etc/nagios/misccommands.cfg :

define command{
        command_name    notify-by-sms
        command_line    /usr/bin/gsmsendsms -d /dev/ttyUSB0 $CONTACTPAGER$ "Nagios - $NOTIFICATIONTYPE$ : $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ($OUTPUT$)"
        }

define command{
        command_name    host-notify-by-sms
        command_line    /usr/bin/gsmsendsms -d /dev/ttyUSB0 $CONTACTPAGER$ "Nagios - $NOTIFICATIONTYPE$ : Host $HOSTALIAS$ is $HOSTSTATE$ ($OUTPUT$)"
        }

Remarque : Il est inutile de me contacter pour des problèmes de compatibilité de GSM, câble et gsmlib. Veuillez directement vous adresser au développeur de gsmlib (site web).

Comme nous l'avons dit précédemment, les vérifications sont assurées par des greffons, dont le développement est séparé du moteur principal.

La relation entre le moteur et les greffons est assurée d'une part dans la configuration de Nagios (dans les services et les misccommands), pour que Nagios sache quelles vérifications lancer sur ou à destination de quelles machines ou services, d'autre part par le code de retour ainsi que la sortie standard d'un greffon.

En effet, un greffon n'est qu'un script/programme/ce que vous voulez, pourvu que ce greffon sache fournir un code retour (0 : tout va bien, 1 : avertissement, 2 : alerte), et éventuellement un petit message décrivant le déroulement de l'exécution.

Pour information, les codes retours sont :

• 0 - OK
• 1 - WARNING
• 2 - CRITICAL
• 3 - UNKNOWN

Ce sont donc ces états qui seront ensuite remontés au moteur qui prendra les décisions et lancera les actions programmées.

Ces greffons fonctionnent soit en local sur la machine supervisée (par exemple les vérifications sur les disques), soit effectuent des tests à distance (tests sur des protocoles réseaux tels SMTP ou exécution à distance via SSH ou autre).

Exemple :

Sur notre serveur de supervision, nous utilisons un GSM pour envoyer des SMS en cas d'incident. Normalement, ce GSM est alimenté par le port USB du serveur ainsi que par sa batterie. Cependant, si le GSM n'est plus alimenté (problème avec le port USB ou si quelqu'un place l'interrupteur du cable sur No charge), les administrateurs doivent être avertis.

Pour ce faire, on utilise le script suivant :

#!/bin/sh

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3

/usr/bin/gsmctl -d /dev/ttyUSB0 BATT > /tmp/check_gsm_battery

POWER=`awk '$1 == "<BATT1>" {print $2}' /tmp/check_gsm_battery`

if test `grep -c "battery connected, but is not powered by it" /tmp/check_gsm_battery` -ne 1
then
        echo "Battery disconnected or gsm powered by battery (load: $POWER%)"
        exit $STATE_CRITICAL
else
        echo "Battery connected, powered by cable (load: $POWER%)"
        exit $STATE_OK
fi

Sans entrer dans les détails, on indique des informations sur le sortie standard avec les commandes echo et on retourne des codes d'erreurs ou d'alertes avec les commande exit.

Nagios est capable de tourner en mode redondance. C'est-à-dire que deux serveurs de supervision se partagent les mêmes fichiers de configuration. Ainsi, si l'un tombe en panne, la supervision est quand même assurée par le second. epuis c aussi de la grosse merde a configuré

Je vous renvoie au site web de Nagios pour de plus amples informations à ce sujet.

Vous trouverez toutes les informations nécessaires sur la page traitant des Load Average.