La supervision réseau sous NagiosJulien Guellec

Les entreprises d'aujourd'hui sont de plus en plus dépendantes de leur système d'information et sont par conséquent de plus en plus vulnérables. La perte d'un serveur ou d'un actif réseau peut ralentir, voire stopper complètement leur activité. Les besoins en terme de disponibilité et de qualité de service n'ont jamais été aussi importants. Réagir rapidement en cas de panne devient donc absolument indispensable. Cet article a pour objectif de vous guider lors de l'installation et de la configuration d'un serveur de supervision sous Nagios qui vous permettra de répondre à ces demandes.

1. Introduction

La supervision d'un réseau est l'action de collecter des informations sur l'état d'une infrastructure et des entités qui y sont liées, de les analyser puis de les organiser de manière a en informer l'administrateur chargé de son bon fonctionnement. Nous le verrons par la suite, il est parfois possible de prendre certaines décisions en fonction des problèmes qui peuvent survenir.

Superviser un réseau c'est avant tout simplifier la vie de l'administrateur. En effet, les infrastructures deviennent de plus en plus grandes, de plus en plus complexes, et avec un nombre sans cesse croissant de machines, de matériels ou encore de services. Garantir un fonctionnement optimal, maintenir la cohésion entre tous ces matériels et services tout en pensant à son optimisation est une charge de travail colossale.

La mise en place d'un service de supervision peut se motiver par un grand nombre de raisons. En voici quelques-unes :

- vérifier le bon fonctionnement des services et machines,

- garder un oeil sur l'état du réseau,

- anticiper les pannes,

- limiter les déplacements dans l'entreprise pour une panne pouvant être réglée à distance,

- centraliser la gestion du réseau et de ses entités,

- alerter l'administrateur lorsqu'un problème survient.

A travers cet article nous allons décrire la mise en place d'un tel service basé sur l'utilitaire Open Source Nagios, référence absolue dans ce domaine. Il s'appuie sur le travail effectué lors de mes derniers stages au Lycée Hôtelier de La Rochelle ainsi que chez dimension iT (Saint Martin de Ré).

2. Présentation de Nagios

Après cette introduction présentant le concept général de la supervision de réseau, passons maintenant à la description plus précise de Nagios. Cet utilitaire, autrement connu sous le nom de NetSaint, connait un véritable succès. Il à en outre était choisi par la RATP, le CNRS, Régional (Air France) ou encore le Ministère des Finances. Il fait l'objet de nombreuses contributions et recherches et vous trouverez de nombreux plugins qui lui sont dédiés.

Les fonctionnalités de Nagios sont très nombreuses, aussi il serait quasiment impossible de toutes les citer dans la mesure où tout à chacun est libre d'y développer ses propres plugins, nécessaires à une utilisation bien spécifique. Parmis les fonctionnalités les plus communes, nous pouvons entre autre citer les suivantes :

- la surveillance de tous les services imaginables (SMTP, POP, HTTP, DNS, DHCP, ...),

- la surveillance des ressources des hôtes (charge CPU, utilisation RAM / disque dur, ...),

- la surveillance de n'importe quel processus (que ce soit sous Windows, Unix ou Mac OS X),

- le dessin d'un plan du réseau avec affichage de diverses informations (2D ou 3D),

- la notification par mail, sms ou encore messagerie instantanée en cas de problème,

- une interface web consultable de n'importe quelle machine (avec authentification).

2.1 Les greffons

Nagios fonctionne grâce à des plugins (ou greffons) écrit en Perl ou en C. Sans eux, il est totalement incapable de superviser quoi que ce soit et se résume à un simple noyau. Aussi, il se voit constamment enrichi par la communauté Open-Source qui met à disposition des utilisateurs des plugins aussi nombreux que variés. Pour vous en convaincre, il suffit d'aller faire un tour sur le site de Nagios Exchange [1]. Nous reparlerons de l'utilisation de ces ressources un peu plus tard. Pour le moment retenez simplement que pour les tâches de supervision relativement communes, quelqu'un à certainement déjà pensé à écrire un plugin. Avant de vous lancer dans la conception d'un greffon, allez donc faire un tour sur ce site : [1] pour voir s'il n'existe pas déjà.

Nagios est également livré avec un « package » de greffons standard regroupant les plus utilisés. Pour une utilisation simple, ils devraient être suffisants.

Nous l'avons vu, Nagios en lui même n'est donc qu'un noyau. Il se voit enrichi de plugins lui donnant toutes ses fonctionnalités et d'une IHM (Interface Homme-Machine) basée sur le serveur web Apache.

Les relations entre le noyau et les plugins sont assurées d'une part par les fichiers de configuration, mais aussi par le code retour d'un plugin :

Les greffons ainsi utilisés peuvent fonctionner soit en local (sur la machine supervisée), soit par des tests à distance. Ces tests à distance peuvent-être effectué selon 3 méthodes :

- via le protocole SNMP (Simple Network Management Protocol),

- via le plugin Nagios NRPE (Nagios Remote Plugin Executor),

- via le plugin Nagios NSCA (Nagios Service Check Acceptor).

Ci-dessous, un schéma de fonctionnement général de Nagios qui vous aidera certainement à mieux visualiser ce concept :

Les plugins utilisés en local se contentent bien souvent d'une vérification de « base ». Par exemple il est facile de contrôler le bon fonctionnement d'un service tel que le FTP, HTTP, etc... mais lorsqu'il s'agit de contrôler des ressources plus « privées » telles que l'utilisation de la RAM, la charge du CPU ou encore l'espace disque disponible, il est nécessaire d'installer les plugins sur la machine supervisée. Plusieurs solutions s'offrent à vous et pour décider de laquelle utiliser il faut prendre en compte le type de l'hôte et la politique de sécurité en vigueur. C'est ici qu'interviennent les plugins NRPE et NSCA.

2.1.1 Le cas de NRPE

NRPE, pour Nagios Remote Plugin Executor, est un agent installé sur le système supervisé. Un démon tourne en permanence sur cette machine et est à l'écoute des ordres qui lui parviennent du serveur. Lorsqu'il reçoit l'ordre de contrôler une ressource, le démon NRPE sous-traite cette demande en demandant au plugin installé localement de procéder à la vérification. Le plugin retourne le résultat au démon NRPE qui va lui-meme retourner ce résultat au

serveur. On dit que NRPE permet une surveillance active. Pour faire une comparaison, le fonctionnement de NRPE est similaire aux messages GET du protocole SNMP. Voici un schéma illustrant le fonctionnement de NRPE :

2.1.2 Le cas de NSCA

L'utilisation de NRPE nécessite pour le serveur d'avoir accès à la machine supervisée. S'il ne peux pas la contacter, par exemple en raison d'une politique de sécurité l'empêchant de le faire, l'utilisation de ce plugin est compromise. Vous pourrez alors faire appel à NSCA. Contrairement à NRPE, NSCA procède à une surveillance passive cela signifie que ce n'est pas le noyau qui demande explicitement le contrôle d'une ressource, mais c'est le démon NSCA installé sur la machine supervisée qui notifie périodiquement le serveur de l'état de cette ressource. Ainsi, seul la machine supervisée nécessite l'accès au serveur. Ce dernier déclarera le service comme DOWN s'il ne reçoit plus de notification du démon NSCA ou si ce dernier lui retourne un état critique. Son mode de fonctionnement peut-être rapproché aux message TRAP du protocole SNMP à la différence que les notifications ne se font pas uniquement lorsqu'un problème survient.

2.1.3 Pour les machines Windows

NRPE et NSCA fonctionnent sur des machines Unix. Pour contrôler des ressources sur une machine windows, vous devrez faire appel à un autre plugin : NSClient. Ce dernier est intéressant car il vous permet de superviser, en plus des classiques informations, n'importe quel processus.

2.2 La gestion des alertes

Un service de supervision serait totalement inutile s'il n'était pas capable de notifier un administrateur du mauvais fonctionnement d'une ressource. Nagios permet évidemment de notifier un (ou plusieurs) contacts si un service supervisé renvoie un état critique. Cette remontée d'alerte peut se faire de différentes façons : par mail, par sms ou encore par messagerie instantanée.

De plus, il est intéressant de signaler que Nagios permet une gestion avancée de ses contrôles, en les archivant d'une part, mais également en offrant la possibilité de tracer des statistiques par hôtes, services, etc... Cette fonction de statistiques est accessible à partir de l'interface Web de Nagios, sous le menu « Trends ».

2.3 Bilan intermédiaire

Vous l'aurez compris, Nagios est un outil aussi performant que riche. Le revers de la médaille est qu'il est relativement complexe à mettre en oeuvre et vous demandera un investissement (humain) important. Que ceux qui s'attendaient à pouvoir déployer un tel serveur en quelques lignes de commandes passent leur chemin.

Une deuxième faiblesse de cet outil réside dans le fait que Nagios ne dispose pas, à l'heure actuelle, d'un plugin de

découverte du réseau. Cela implique que si vous avez l'intention de superviser 200 hôtes, il vous faudra les ajouter un à un à la configuration. Il existe cependant une astuce qui consiste à utiliser les services du logiciel Nmap, mais nous y reviendrons par la suite.

En revanche, un serveur de supervision opérationnel récompensera très largement cet investissement. Retroussez vos manches, allez vous chercher un bon café et commençons l'installation.

3. Installation de Nagios

3.1 Sur le serveur Web Apache2

L'installation de Nagios n'est pas difficile en soit. Dans cet article nous prenons pour base une distribution Debian 4.0. L'installation par le gestionnaire de paquet de Debian installera le noyau ainsi que les plugins standard.

apt-get install nagios2

Ceci étant fait, il faut maintenant modifier le fichier de configuration de votre serveur Apache2. En effet, pour pouvoir accéder à l'interface de Nagios, nous devons impérativement ajouter un alias dans ce apache2.conf mais également sécuriser un minimum cet accès à un administrateur. Voici les lignes que vous devrez ajouter :

ScriptAlias /cgi-bin/nagios2 /usr/lib/cgi-bin/nagios2

ScriptAlias /nagios2/cgi-bin /usr/lib/cgi-bin/nagios2

Alias /nagios2 /usr/share/nagios2/htdocs

<DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>

Options FollowSymLinks

DirectoryIndex index.html

AllowOverride AuthConfig

Order Allow,Deny

Allow From All

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /etc/nagios2/htpasswd.users

require valid-user

</DirectoryMatch>

Pour vous éviter de recopier toutes ces lignes et par la même occasion éviter les erreurs de frappes, vous trouverez dans le répertoire de nagios (/etc/nagios2/) un fichier d'exemple contenant ces informations. Faites une copie de sauvegarde de votre ancien fichier de configuration puis à l'aide d'un cat, redirigez la sortie standard de ce fichier sample dans le apache2.conf :

cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.OLD

cat /etc/nagios2/apache2.conf >> /etc/apache2/apache2.conf

Relancez votre serveur Apache2 :

/etc/init.d/apache2 restart

Apache2 est maintenant correctement configuré, nous devons à présent mettre en place la politique d'accès à l'inteface de Nagios. N'importe qui ne doit pas y avoir accès dans la mesure où cette interface révèlera des informations sensibles de votre réseau.

Dans un premier temps nous allons créer un fichier qui contiendra les utilisateurs autorisés à accéder à cette interface :

cd /etc/nagios2/

htpasswd -c /etc/nagios2/htpasswd.users nagiosadmin

On vous invite alors à entrer un mot de passe pour l'utilisateur nagiosadmin (ce mot de passe sera crypté et n'apparaitra donc pas en clair dans le fichier). Vous pouvez vérifier que tout a fonctionné correctement :

cat /etc/nagios2/htpasswd.users

cela devrait vous retourner quelque chose de la forme :

nagiosadmin:rdLrkmS5eb7hg

Dans un second temps, nous allons créer un fichier de configuration d'Apache : .htaccess, qui nous permettra de définir les règles d'accès à notre interface :

cd /etc/nagios2 && vim .htaccess

Ajoutez alors les lignes suivantes à ce fichier :

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /etc/nagios2/htpasswd.users

require valid-user

Pour que toutes ces modifications prennent effet il faut vérifier que dans le fichier cgi.cfg le paramètre use_authentication soit bien positionné à 1. Pour vous en assurez :

cat /etc/nagios2/cgi.cfg | grep use_authentication

Les droits d'accès sont maintenant correctement définis.

Nagios devrait être en mesure de démarrer. Il est maintenant temps de voir à quoi ressemble ce formidable outil. Avant de se lancer tête baissée, vérifions tout de même que tous nos paramètres d'initialisation soient correctement configurés en utilisant la commande suivante :

/usr/sbin/nagios2 -v /etc/nagios2/nagios.cfg

Retenez bien cette commande : elle vous sauvera la vie de nombreuses fois. En effet, elle vérifie dans les fichiers de configuration de Nagios si tout va bien et qu'ils ne comportent aucune erreur. Les vérifications effectuées sont les suivantes :

- tous les contacts sont membres d'au-moins un groupe de contacts

- tous les contacts spécifiés dans chaque groupe de contacts sont valides

- tous les hôtes sont membres d'au-moins un groupe d'hôtes

- tous les hôtes spécifiés dans chaque groupe d'hôtes sont valides

- tous les hôtes sont associés à au-moins un service

- toutes les commandes utilisées dans les contrôles de services et d'hôtes sont valides

- toutes les commandes utilisées dans les gestionnaires des services et d'hôtes sont valides

- toutes les commandes utilisées dans les notifications de contacts, services et hôtes sont valides

- toutes les périodes de notification spécifiées pour les services, hôtes et contacts sont valides

- toutes les périodes de contrôle de service spécifiées pour les services sont valides

Si tout va bien, lancez Nagios :

/etc/init.d/nagios2 restart

et accédez (enfin !) à l'interface en vous rendant à l'adresse suivante :

http://adresse_ip_de_votre_serveur/nagios2

Authentifiez vous avec comme utilisateur nagiosadmin et le mot de passe que vous avez défini plus haut. Vous devriez voir apparaitre l'interface de Nagios :

3.2 Sur le serveur web LigHTTPd

LigHTTPd est un serveur HHTP qui devient de plus en plus utilisé. En avril 2007 il est entré dans le Top 5 des serveurs Web les plus utilisés. Il est donc intéressant de détailler la configuration de Nagios pour ce serveur.

Tout d'abord veuillez installer LighHTTPd, si ce n'est déjà fait tapez la commande suivante :

apt-get install lighttpd

Vous devrez également installer les paquets suivants :

apt-get install php5 php5-cgi

Ensuite éditez le fichier de configuration de ligHTTPd (/etc/lighttpd/lighttpd.conf) et ajoutez-y les références suivantes juste avant les inclusions (#### external configuration files) :

alias.url = (

"/nagios2/cgi-bin" => "/usr/lib/cgi-bin/nagios2",

"/nagios2/stylesheets" => "/etc/nagios2/stylesheets/",

"/cgi-bin/nagios2" => "/usr/lib/cgi-bin/nagios2",

"/nagios2" => "/usr/share/nagios2/htdocs"

)forcez ensuite votre serveur à installer le module de gestion des CGI en tapant les commandes suivantes :

/usr/sbin/lighty-enable-mod

puis entrez : cgi

Relancez ensuite le serveur :

/etc/init.d/lighttpd force-reload

Vous devriez maintenant pouvoir consulter l'interface de Nagios à l'adresse :

http://adresse_ip_de_votre_serveur/nagios2

Pour le support de l'authentification, cela se passe un peu différemment de Apache2. Commencez par éditer le fichier /etc/lighttpd/conf-available/10-auth.conf. Ajoutez-y les lignes suivantes :

auth.backend = "htpasswd"

auth.backend.htpasswd.userfile = "/etc/nagios2/htpasswd.users"

auth.require = ( "/nagios2/" =>

( "method" => "basic",

"realm" => "Nagios",

"require" => "valid-user"

)

)Ceci prend en considération que vous disposez d'un fichier htpasswd.users. Si ce n'est pas le cas, créez ce fichier au préalable. Vous trouverez la procédure à suivre dans la section de configuration du serveur web Apache. La commande à utiliser est la suivante :

htpasswd -c /etc/nagios2/htpasswd.users nagiosadmin

Ensuite forcer votre serveur à utiliser ce nouveau module en utilisant les commandes suivantes :

/usr/sbin/lighty-enable-mod

puis entrez : auth

Relancez ensuite le serveur :

/etc/init.d/lighttpd force-reload

4. Exploration de l'interface

Bien que très simple à comprendre, décrivons brièvement cette interface.

Sur la gauche vous trouverez le menu de navigation qui vous permettra d'afficher les différents modules. Voyons un peu plus en détails ceux qui vous seront le plus utiles :

- Tactical Overview : vue très pratique de l'ensemble des services et des hôtes supervisés. Vous visualisez d'un seul coup d'oeuil les données vitales de votre réseau. Cette vue est idéale si vous disposez d'un moniteur allumé en permanence pour le contrôle de vos hôtes et services.

- Service Detail : comme son nom l'indique cette vue vous propose, hôte par hôte la liste des services; leurs statut et diverses informations telles que l'heure de la dernière vérification etc... Cette vue est intéressante mais peut rapidement devenir encombrée si vous supervisez un grand nombre de services.

- Status Map : carte 2D du réseau.

Je vous laisse le soin de découvrir les autres modules.

5. Mise en place d'une configuration basique

Actuellement nous disposons d'une configuration de base, celle déployée lors de l'installation qui se contente de superviser quelques services de la machine sur laquelle est installé le serveur. Peut-être avez-vous l'intention d'aller un peu plus loin ? Nous allons expliquer à travers un exemple comment ajouter un hôte et ses services associés. Vous serez ainsi en mesure de le faire pour n'importe quelle entité de votre réseau, que ce soit un serveur, un poste client ou encore un routeur.

Notre exemple consistera à ajouter un routeur (borne Airport Xtrem) d'adresse ip : 10.0.1.1 à notre serveur Nagios. Pour commencer nous allons reprendre un fichier de configuration déjà existant et le modifier pour l'adapter à ce routeur. Chaque hôte que vous allez ajouter disposera d'un fichier de configuration qui décrira tous les renseignements nécessaires à la supervision de celui-ci. Dans la plupart des cas vous allez vous retrouver avec un grand nombre de fichiers de configuration, je vous conseille donc vivement de bien vous organiser. Par exemple créez un dossier « routers » qui contiendra tous les fichiers de configuration de vos routeurs, faites de même pour les imprimantes avec un dossier « printers » etc... Ce n'est pas une obligation mais il est préférable de créer ces dossier dans le répertoire /etc/nagios2/conf.d/ car c'est ici que ce trouvent la plupart des fichiers de configuration. Dans notre exemple nous commençons donc par créer un dossier « routers » puis nous copions un fichier de configuration déjà existant :

mkdir /etc/nagios2/conf.d/routers

cp /etc/nagios2/conf.d/localhost_nagios2.cfg /etc/nagios2/conf.d/routers/airport_xtrem.cfg

Un fichier de configuration type comprend :

- une section de définition de l'hôte (adresse ip, nom, etc..)

- une section de définition des services associés

Dans notre cas, nous allons modifier le fichier ainsi :

define host {

use generic-host

host_name airport_xtrem

alias airport

address 10.0.1.1

}

define service {

use generic-service

host_name airport_xtrem

service_description Ping test

check_command check_ping!100.0,20%!500.0,60%

}

On peut difficilement faire plus simple : on définit l'hôte, son adresse ip, et un service basique qui test si l'hôte est bien présent sur le réseau par un simple « ping ». Notons simplement que le fichier de configuration de la commande « check_ping », ainsi que tous les fichiers de configuration des commandes faisant appel aux plugins de Nagios se trouvent dans le répertoire suivant : /etc/nagios-plugins/config. Si vous voulez ajouter d'autres services, référez-vous à ces fichiers pour voir comment les implémenter. Les plugins sont, eux, situés dans un autre répertoire : /usr/lib/nagios/plugins/.

Le paramètre « use » définit un fichier à inclure dans la configuration de l'hôte ou du service, ce fichier peux contenir diverses informations comme les contacts à notifier, des paramètres sur les remontées d'alertes etc... L'utilité de tels fichiers vous permet de ne pas avoir à ré-écrire toutes ces informations pour chacun des hôtes (ou service) que vous définissez. Vous pourrez par exemple avoir un fichier admins-host qui ne notifiera que les administrateurs de votre réseau, pendant une certaine période de temps etc... Editez ces fichiers et vous comprendrez rapidement leurs fonctionnement.

Lorsque vous faites des modifications sur des fichiers de configuration il est nécessaire de redémarrer Nagios pour que les changements prennent effet. Assurez-vous auparavant que vous n'avez pas commis d'erreurs dans vos modifications en utilsant la ligne de commande que nous avons vu précédemment, a savoir :

/usr/sbin/nagios2 -v /etc/nagios2/nagios.cfg

Si tout c'est bien passé, redémarrez Nagios et connectez-vous pour voir les changements :

/etc/init.d/nagios2 reload

Nous avons vu ici le minimum à savoir pour pouvoir commencer à utiliser Nagios correctement. Vous savez à présent comment ajouter un hôte et ses services associés. Inspirez-vous des autres fichiers de configuration pour implémenter d'autres services.

6. Les fichiers de configuration principaux

Nous en avons vu quelques-un, ceux qui vous sont nécessaires à l'ajout d'hôtes et de services. Le but de cette section ne sera pas de paraphraser la documentation de Nagios très bien faite à ce sujet (et je vous conseille d'ailleurs vivement de vous y référer, ici : [2] ) mais simplement d'avoir un rapide aperçu de ces derniers pour vous permettre simplement de savoir où chercher l'information.

/etc/nagios2/nagios.cfg : fichier de configuration principal de Nagios. Attention, ce dernier est dense (!) mais néanmoins très pratique. il vous permet d'affiner la configuration standard, comme par exemple modifier les intervalles de temps entre chaque vérification de services, vous permet d'ajouter vos propres fichiers de configuration, d'organiser votre serveur à votre guise... Le consulter n'en sera que bénéfique pour vous.

/etc/nagios2/commands.cfg : ce fichier contient à l'origine les définitions de toutes les commandes, mais sous Debian, nous l'avons vu, les définitions des commandes de plugins sont « éclatées »dans le répertoire des plugins standards de Nagios. Néanmoins ce fichier contient les définitions des commandes externes, telles que celles qui vous seront utiles pour la remontée d'alerte.

/etc/nagios2/cgi.cfg : ce fichier gère tout ce qui est lié aux CGI (Common Gateway Interfaces). Il est rare d'avoir à y faire des modifications mais il peut être intéressant lorsque vous voulez définir des préférences concernant l'interface web de Nagios.

/etc/nagios2/conf.d/contacts_nagios2.cfg : ce fichier contient tous les contacts qui seront joints par Nagios pour les notifications. C'est ici que vous définissez également les groupes de contacts (techniciens, commerciaux, etc...).

/etc/nagios2/conf.d/extinfo_nagios2.cfg : ce fichier contient les références de vos hôtes qui seront utilisées pour la cartographie (icônes, coordonnées sur la carte, etc...)

/etc/nagios2/conf.d/hostgroups_nagios2.cfg : dans ce fichier sont déclarés les groupes d'hôtes.

7. Pour aller plus loin

Comme je le précisais dans mon introduction il serai difficile de décrire toutes les possibilités que Nagios vous offre. Cependant, il est encore intéressant d'aborder quelques autres fonctionnalités très utiles.

7.1 Remontée d'alerte

Et bien oui, à quoi sert un serveur de supervision s'il ne vous permet pas de vous notifier en cas de problème ? La remontée d'alerte est l'action entreprise par Nagios lorsqu'un service ou un hôte vient à passer dans un état critique. Elle peut être de formes très différentes, à savoir :

- notification par sms / pagger ,

- notification par Email,

- notification par messagerie instantanée,

- alerte sonore,

- ...

Pour mettre en place les notifications il va nous falloir aborder de nouvelles notions. La première étant celle que chaque hôte dispose d'un groupe de personnes qui en est responsable. Pour une petite entreprise cette personne sera l'administrateur réseau mais il est possible de définir autant de groupe que vous voulez. Faisons simple et partons du principe qu'une seule et même personne sera responsable de nos hôtes. Cette personne dispose d'heures de travail, sauf pour certains cas, il n'est pas forcément nécessaire de réveiller l'administrateur au milieu de la nuit pour un service qui serait tombé. Ceci constitue la deuxième notion : les heures de travail. Et enfin, vous ne voulez peut être pas forcément être notifié de tous les problèmes qui pourraient survenir, mais seulement les services critiques ou les problèmes pouvant survenir sur des serveurs d'une grande importance. Toutes ces notions se traduisent dans les fichiers de configuration et vont pouvoir vous permettre d'optimiser au mieux la remontée d'alerte.

Tout d'abord reprenons l'exemple de notre routeur. Celui-ci étant d'une importance suprême, nous allons mettre en place une remontée d'alerte sur le service PING que nous avons défini tout à l'heure. Pour se faire éditez le fichier de configuration de l'hôte (/etc/nagios2/conf.d/routers/airport_xtrem.cfg) et ajouter dans la section du service PING les lignes suivantes :

notification_interval 30

notification_period 24x7

notification_options c

contact_groups linux-admins

Qu'avons-nous fait ? Tout d'abord la première ligne défini le temps (en minutes) au bout duquel Nagios relancera une notification si le statut du service n'est pas revenu à la normale.

La deuxième ligne définit une période pendant laquelle la notification est effective. Dans le cas présent, l'administrateur sera susceptible d'être dérangé 24h/24 7j/7 (il vous en remerciera...). Les périodes de temps sont définies dans un fichier de configuration bien spécifique (/etc/nagios2/conf.d/timeperiods_nagios2.cfg). Ainsi vous pourrez être plus gentil avec votre administrateur et définir de nouvelles plages horaires. Il en existe des prédéfinies, notamment les heures standard de bureau etc.. Je vous laisse le soin de consulter ce fichier et de l'adapter à votre guise.

La troisième ligne que nous avons ajoutée correspond au type d'évènement qui déclenchera la notification. Ces évènements sont les suivants :

- w (WARNING) : envoi de notification lorsque l'hôte ou le service retourne un simple avertissement,

- u (UNKNOWN) : envoi de notification lorsque l'hôte ou le service retourne un statut inconnu,

- c (CRITICAL) : envoi de notification lorsque l'hôte ou le service retourne un statut d'alerte

il en existe d'autres, mais ce sont les trois plus importants.

Enfin, la quatrième ligne définit le groupe à notifier en cas d'alerte. Toutes les personnes du groupe linux-admins seront contactées s'il survient une erreur critique.

Ce dernier point me permet d'embrayer sur la notion de groupe et nous allons voir comment il est possible de les définir. En effet, le groupe linux-admins n'est pas un groupe définit par défaut ainsi, si vous essayez de relancer le serveur maintenant il refusera de démarrer. Utilisez donc la ligne de commande de vérification que nous avons déjà vu, cela vous donnera une idée de ce que celle-ci vous retourne en cas d'erreur.

Il est donc nécessaire à ce stade d'ajouter le groupe linux-admins et d'y intégrer notre administrateur. Cette notion de groupes et de contacts fait appel au fichier de configuration suivant : /etc/nagios2/conf.d/contacts_nagios2.cfg. Comme vous pourrez le constater en l'éditant, ce fichier est scindé en deux parties : la première vous permet de définir les contacts, la deuxième les groupes de contacts. Dans notre cas ajoutons dans la première partie les lignes suivantes pour définir notre administrateur :

define contact {

contact_name admin

alias Julien Guellec

service_notification_period 24x7

host_notification_period 24x7

service_notification_options w,u,c

host_notification_options d,r

service_notification_commands notify-by-email

host_notification_commands host-notify-by-email

email jguellec@supinfo.com

}

Vous connaissez déjà la plupart des lignes qui viennent d'être ajoutées. Notons simplement qu'ici l'administrateur sera en charge des services mais aussi des hôtes. Ajouter ensuite ce contact dans le nouveau groupe linux-admins.

define contactgroup {

contactgroup_name linux-admins

alias Administrateurs Linux

members admin

}

Pour ajouter d'autres utilisateurs dans ce groupe, ajoutez-les simplement à la fin de la ligne « members » en les séparant par une virgule.

Vous pouvez à présent relancer votre serveur Nagios. Notez qu'il vous faut un service de mail qui tourne sur votre machine pour que celle-ci soit capable d'envoyer la notification. Vous pouvez à votre guise changer la commande « notify-by-email » et l'adapter à votre configuration (/etc/nagios2/commands.cfg). Pour ce qui est des notifications par sms il est nécessaire d'utiliser les services d'un prestataire et de logiciels tierces. Vous trouverez plus d'informations à ce sujet dans la documentation officielle, à cette adresse : [2].

7.2 NRPE

Nous en parlions tout à l'heure, voyons maintenant comment installer et utiliser NRPE. Rappelons que celui-ci nécessite un processus s'exécutant côté serveur, et un autre côté client. Pour installer la partie du plugin côté serveur exécutez la commande suivante :

apt-get install nagios-nrpe-plugin

Un nouveau plugin nommé « check_nrpe » sera ajouté à votre répertoire : /usr/lib/nagios/plugins

Il s'utilise comme n'importe quel autre plugin : lors de la définition de votre service, dans le fichier de configuration de votre hôte, utilisez simplement la commande : « check_nrpe ». Pour avoir des détails sur le fonctionnement de ce plugins (les différentes options, etc...) utilisez la commande :

/usr/lib/nagios/plugins/check_nrpe --help

Plus généralement, cela fonctionne avec n'importe lequel des plugins de Nagios :

/usr/lib/nagios/plugins/votre_plugin –help

L'installation de la partie « cliente » de NRPE s'effectue de la façon suivante :

apt-get install nagios-nrpe-server

Le fichier de configuration sera créé dans /etc/nagios/ (les paquets Debian de la version Etch ne sont pas à jour et NRPE se configure dans l'ancien répertoire de nagios... pour le moment). NRPE sera présent sur votre système comme un simple démon.

Vous pouvez également utiliser le plugin check_by_ssh si vous n'avez pas envie d'installer NRPE. Ce plugin vous permettra d'exécuter n'importe quelle commande sur l'hôte distant.Vous pouvez ainsi lancer l'exécution d'un script à distance dans la mesure où celui-ci est capable de retourner une valeur à Nagios, pour que ce dernier puisse définir l'état du service qui lui correspond (pour les valeurs à retourner, référez-vous au tableau donné en début d'article).

7.3 Un mot sur NSCLIENT

Le but n'est pas de passer en revue tous les plugins utilisables par Nagios (c'est d'ailleurs pour cela que j'ai volontairement omis de décrire NSCA) mais il est intéressant de parler rapidement de NSCLIENT. Pourquoi ? Tout simplement car ce dernier conditionne la supervision de machine sous Windows et qu'il peut donc, par conséquent, vous être utile.

Pour superviser un service avec NSCLIENT vous devez l'installer sur votre machine Windows. Rendez-vous à l'adresse suivante : [3] et téléchargez la dernière version en date. L'installation est très simple : copiez le répertoire correspondant à vos besoins (à priori Win_2k_XP_Bin) et son contenu dans n'importe quel répertoire de votre disque dur. Par exemple à la racine du C:\ dans le répertoire « nsclient ». Ouvrez ensuite une console dans ce répertoire et tapez les commandes suivantes :

pNSClient.exe /install

net start nsclient

Ainsi, NSClient tournera en tant que service sur la machine. Une clé de registre a été ajoutée, elle se trouve à cet emplacement :

HKEY_LOCAL_MACHINE\SOFTWARE\NSClient

Vous pourrez par exemple vous y référez si vous voulez modifier le mot de passe nécessaire pour récupérer les informations remontées par le plugin.

L'utilisation de NSClient est ensuite très simple, vous utilisez le plugin « check_nt » de Nagios. Pour connaitre son mode de fonctionnement tapez simplement la commande suivante :

/usr/lib/nagios/plugins/check_nt -h

ou référez-vous à la documentation de NSClient, section « Plugin Syntax ».

7.3 Base de connaissances

Cet article touche bientôt à sa fin. Je pense que vous êtes maintenant apte à gérer votre serveur Nagios. Pour parfaire votre autonomie voyons encore un dernier point. Vous allez probablement, à un moment ou à un autre, vous retrouvez dans le cas où vous êtes intéressé par la supervision d'un service qui ne se trouve pas dans les plugins standards. Il existe une énorme base de connaissances sur internet, regroupant aussi bien des plugins que des images et toutes sortes de contributions de développeurs.

Référez-vous au site Nagios Exchange [1] c'est une véritable mine d'or !

7.4 Découverte du réseau

Lors de mon bilan intermédiaire j'abordais le problème de la découverte du réseau. Il serait en effet intéressant que Nagios dispose d'un tel plugin, mais ce n'est malheureusement pas encore le cas. Pour vous éviter de devoir ajouter tous les hôtes un à un, une solution intermédiaire serait d'utiliser Nmap pour découvrir le réseau, suivant une plage d'adresse IP, puis d'enregistrer le résultat dans un fichier xml. Ainsi, à l'aide d'un petit script bash, perl ou autre, vous serez en mesure d'automatiser l'ajout d'hôtes à votre serveur.

Une autre solution est l'utilisation du très bon outil OCS Inventory qui permettra de faire un inventaire de vos machines avant de les intégrer à Nagios. La configuration d'OCS pouvant faire l'objet d'un article à part entière je vous laisse le soin de vous documenter sur le web. Sachez simplement qu'il pourra vous être utile lors du déploiement d'un serveur de supervision Nagios.

8. Conclusion

A travers cet article nous avons abordé le concept de supervision réseau et comment tirer parti du serveur Nagios afin de rendre votre infrastructure plus fiable. Il n'avait pas la prétention de décrire toutes les fonctionnalités que Nagios est capable de vous apporter mais simplement de vous donner les bases nécessaires à la supervision de réseaux. Gardez bien à l'esprit qu'il vous reste une quantité de choses à découvrir sur ce formidable outil.

9. Liens

[1] Site Nagios Exchange : http://www.nagiosexchange.org/

[2] Documentation officielle : http://www.nagios.org/docs/

[3] NSClient : http://nsclient.ready2run.nl/download.htm

Julien Guellec

SUPINFO Paris

jguellec@supinfo.com

http://www.guellec.fr/