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 -c /etc/nagios3/htpasswd.users <username>

pour le moment vous pouvez utiliser :

sudo htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

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

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.

choqué …

et décu….

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.

Pour utiliser un test de service il faut plusieurs choses :

• un greffon ou plugin utilisable en ligne de commande (le nom commence par check_ ) , il est très intéressant de le tester via la ligne de commande pour voir ses arguments
• Un objet Nagios définissant la command utilisant le plugin précédent
• un objet Nagios définissant le service utilisant la commande précédente

Pour récapituler :

script shell → chekcommands.cfg → services.cfg

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/nagios3/hosts.cfg./usr/local/nagios/etc/objects/localhost.cfg (à vérifier) /etc/nagios3/conf.d/localhost_nagios2.cfg

define host{
        use                     generic-host
        host_name               router
        alias                   Routeur vers exterieur - connexion internet
        address                 192.168.0.254
        check_command           check-router-alive
        }

define host{
        use                     generic-host
        host_name               fileserver
        alias                   Serveur fichiers
        address                 192.168.0.10
        check_command           check-host-alive
        }

define host{
        use                     generic-host
        host_name               mail
        alias                   Serveur mail
        address                 192.168.0.20
        check_command           check-host-alive
        }

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. Je ne definis dans ces 'hosts' que ce qui leur est propre.

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 lier un hôte a un groupe d'hotes).

Enfin, remarquez que pour chaque hôte on a indiqué quelle commande de vérification est utilisée. Ces commandes sont, soit des commandes de bases de Nagios, soit des commandes ajoutées manuellement dans le fichier commands.cfg. Vous pouvez obtenir toute la liste des commandes disponibles à travers l'interface web de Nagios (lien Configuration, Commands). Cette commande permet a Nagios de savoir si l'hôte est 'vivant', s'il ne l'est pas il enverra une notification pour signaler 'Host down' mais rien sur les services associes (qui seront aussi 'down' puisque le serveur est tombe). Le plus simple est de faire un test sur le ping ; mais ça peut ne pas convenir dans tous les cas, ex. si une machine a un firewall sur lequel vous n'avez pas la main, vous pouvez essayer de faire un check_ssh.

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/nagios3/conf.d/hostgroups.cfg. /etc/nagios3/conf.d/hostgroups_nagios2.cfg

Ici, nous allons déterminer deux groupes d'hôtes:

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

define hostgroup{
        hostgroup_name  mail-server
        alias           Serveurs de mails Ubuntu
        contact_groups  admins-ubuntu
        members         mail1, mail2
        }

Avec les groupes d'hôtes et les groupes de contacts, on peut subdiviser les machines par zone géographique ou par fonctions. De cette manière, on notifie ainsi 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 ou a un groupe d'hôtes. Les informations concernant les services sont contenues dans le fichier /etc/nagios3/conf.d/services.cfg /etc/nagios3/conf.d/generic-service_nagios2.cfg.

# Generic service definition template
define service{
        ; The 'name' of this service template, referenced in other service definitions
        name                            generic-service
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/disabled
        parallelize_check               1       ; Active service checks should be parallelized
                                                ; (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is disabled
        flap_detection_enabled          1       ; Flap detection is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
        is_volatile                     0
        check_period                    24x7
        normal_check_interval           5       ; Do a check for this service every X minutes
        max_check_attempts              3       ; After X checks non OK , status will change from soft to hard and trigger notifications if any
        retry_check_interval            1       ; If the status was non OK, redo a check for this service every X minutes
        notification_interval           0       ; Every X minutes, Nagios will resend a notification, 0 to disable that
        notification_period             24x7
        notification_options            c,r

        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }



define service{
       use                             generic-service
       host_name                       router
       service_description             PING
       contact_groups                  admins-routers,admins-ubuntu
       check_command                   check_ping!100.0,20%!500.0,60%
       }

define service{
        use                             generic-service
        hostgroup_name                  mail-server
        service_description             SMTP
        contact_groups                  admins-ubuntu
        check_command                   check_smtp
        flap_detection_enabled          0       ; Flap detection is disabled for this service
        }

define service{
        use                             generic-service
        host_name                       mail
        service_description             IMAP
        contact_groups                  admins-ubuntu
        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. Dans tous les cas il faut se rapporter a la définition de la commande et tester le script pour voir comment il se comporte.

Les lignes :

      normal_check_interval           5       ; Do a check for this service every X minutes
      max_check_attempts              3       ; After X checks non OK , status will change from soft to hard and trigger notifications if any
      retry_check_interval            1       ; If the status was not OK, redo a check for this service every X minutes

méritent peut-être un peu d'attention. Rien de pire que les fausses alertes, ici Nagios testera les services toutes les 5 minutes, si un des services est dans un statut non OK (warning, critical, unknown) il va ressayer de le contacter une minute plus tard, et ceci 3 fois de suite puis déclenchera l'alerte (envoi de mail, etc), dès que le service répond de nouveau OK Nagios 'réinitialise' les compteurs et reprend les checks sur l'intervalle normale (normal_check_interval).

Avantages :

• On réduit les chances de fausse alerte : le service a été testé 3 fois comme non OK.

Inconvénients :

• On n'a pas d'alerte à la seconde ou Nagios a détecté le problème.

À vous de régler max_check_attempts suivant vos services. Plus d'infos sur la page Checkscheduling.

Pensez aussi à la notion de flapping : imaginons que vous surveilliez le load d'une machine vous définissez les valeurs pour lequel Nagios doit vous alerter. Si cette valeur est '3' (pour le load à 5 minutes), imaginons que votre machine est chargée, le load vu par Nagios va osciller entre 2.5 et 3.5… À chaque oscillation Nagios va vous envoyer un mail, sauf si vous avez activé le flapping :

 flap_detection_enabled          1       ; Flap detection is enabled

L'escalation est optionelle, donc ne commencez pas par ça … Elle permet de mettre en place des niveaux d'alerte. Scénario simple : vous définissez les contacts pour vous et vos collègues administrateurs : c'est tout ce beau monde qui recevra immédiatement une alerte en cas de soucis, si l'alerte est encore effective après 2 notifications des principaux intéressés, d'autres personnes peuvent être prévenues, les commerciaux, votre supérieur hierarchique, la cellule communication/relation presse… à vous de voir en fonction des besoins de votre entreprise.

Cette étape est décrite dans le fichier « /etc/nagios3/conf.d/service-escalations.cfg ».

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

Si vous ne voulez pas utiliser l'escalation renommez le fichier en .cfg.no ou tout autre extension différente de .cfg

À chacun des hôtes et services peuvent être rattachés des arguments de type liens hypertextes et images. Pour cela, éditer le fichier de configuration cgi.cfg

Éditez le fichier /etc/nagios3/cgi.cfg et rajoutez-y les 2 lignes suivantes :

xedtemplate_config_file=/etc/nagios3/conf.d/hostextinfo.cfg
xedtemplate_config_file=/etc/nagios3/conf.d/serviceextinfo.cfg

Créer les 2 fichiers suivants qui géreront respectivement les informations liées aux hôtes et services :

touch /etc/nagios3/conf.d/hostextinfo.cfg
touch /etc/nagios3/conf.d/serviceextinfo.cfg

Exemple de fichiers et d'arguments possibles pour chacun des 2 fichiers :

define hostextinfo{ 
 host_name monitoring
 icon_image ubuntu.png 
 icon_image_alt Ubuntu 
 vrml_image ubuntu.png
 statusmap_image s_ubuntu.jpg
 notes_url http://192.168.2.1
    }

define serviceextinfo{ 
 host_name monitoring 
 service_description service apache 
 notes_url http://monitoring/nagios/
 icon_image apache.jpg 
 icon_image_alt Acces a Nagios 
    }

Le paramètre icon_image correspond à l'image associée à un host (la miniature est gérée automatiquement) ; vrml_image correspond à l'image utilisée dans la 3-D statusmap ; et statusmap_image à l'image affichée dans la 2-D statusmap.

Les images doivent être stockées dans le répertoire /usr/share/nagios/htdocs/images/logos

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

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

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

 sudo /etc/init.d/nagios3 reload

hihi

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/nagios3/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).

tu envoies rien du tout

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

# Inclusion de le mini librairie definissant les etats et quelques fonctions de base
source /usr/lib/nagios/plugins/utils.sh

/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. Je vous renvoie au site web de Nagios pour de plus amples informations à ce sujet.

ERGTEGG

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

Le plugin check_nt permet de récupérer des informations sur des hôtes basés sur le système d'exploitation Windows. Il fonctionne avec NSClient, qu'il faut installer sur la machine cliente à superviser.

Penser à préciser le mot de passe qui protège NSClient des requêtes frauduleuses. Le mot de passe est stocké sur le pc où est installé l'agent dans la clé de registre « HKEY_LOCAL_MACHINE\SOFTWARE\NSClient\Parms ». Le mot de passe est à inclure dans la requête après le commutateur -s qu'il faut donc rajouter. Si la clé ne contient aucun mot de passe, alors le mot de passe est None (respect de la casse).

Pour paramétrer le mot de passe sur la requête envoyée par le serveur Nagios, éditer le fichier /etc/checkcommands.cfg puis modifier les lignes correspondant à l'exécution du plugin check_nt pour ajouter « -s <mot de passe > » :

# 'check_nt_disk' command definition
 define command{
 command_name check_nt_disk
 command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v USEDDISKSPACE -l $ARG1$ -w $ARG2$ -c $ARG3$ **-s None**
 }

Nagios Exchange fournit un joli choix de scripts de check pour Nagios, evidemment vous pouvez écrire votre propre script (voir plus haut) et s'il fonctionne bien pourquoi ne pas le proposer sur NagiosExchange.

Le Virtual Reality Modeling Language (abrégé en VRML) est un Langage de programmation spécialisé dans la représentation d'univers virtuels en 3 dimensions. Ce langage interprété est une norme internationale ISO et les fichiers VRML ont habituellement pour extension .wrl. C'est ce type de fichier qui s'affiche pour consulter la 3-D Status Map.

Il faudra donc installer sur les postes clients un plugin VRML ; le plugin Cortona fait office de référence pour Windows et Mac mais n'existe pas pour Linux. Nous utiliserons FreeWRL.

Un paquet au format deb existe pour Ubuntu Dapper et fonctionne pour Edgy ; commencer par récupérer le paquet sur le site sourceforge.net ou par la commande :

wget http://prdownloads.sourceforge.net/freewrl/freewrl_1.18.2-1_i386.deb?download

Ce paquet est dépendant de celui nommé lesstif2, disponible dans le dépot Universe. Il faudra donc exécuter les commandes suivantes :

sudo apt-get install lesstif2
sudo dpkg -i freewrl_1.18.2-1_i386.deb

Vous pouvez installer le plugin Nagios Checker pour les navigateurs internet Firefox et Chromium, ou pour le gestionnaire de courrier Thunderbird. Le paramétrage est complet (possibilité de notifications visuelles et/ou sonore, gestion des accès authentifiés…). Vous aurez ainsi la possibilité de superviser les problèmes directement dans la barre d'état de votre navigateur ou gestionnaire de courrier !

• Plugin pour Mozilla Firefox
• Plugin pour Mozilla Thunderbird
• Plugin pour Chromium

À partir d'Ubuntu 10.10, le paquet nagstamon permet d'ajouter une applet en barre des tâches ou une simple fenêtre flottante. Plusieurs options permettent de personnaliser les alertes.

Nb: le fonctionnement de la fenêtre flottante demanderait à être testé en environnement 11.04/Unity

NON !

• (en) Le site officiel de Nagios
• (en) La documentation officielle de Nagios
• (fr) Articles et tutoriels sur Nagios
• (fr) Forum sur Nagios et la supervision système et réseau
• (fr) Tutoriel installation Nagios-Centreon sous Ubuntu
• (en) icinga, un fork de nagios basé sur Nagios 3.
• (fr) Comment superviser avec Nagios / Icinga ? Article Opendoc.net
• (fr) http://www.alarmtilt.com/fr/gerez-vos-alertes-nagios-avec-teamtilt.html
• Shinken, écrit en python et pleinement compatible avec Nagios

Contributeurs : Ostaquet, sidney_v,Ju., Nicolargo.