Vous êtes sur la page 1sur 14

La supervision réseau sous Nagios

Julien 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/

Vous aimerez peut-être aussi