Nagios

v 1.
4 Janvier 2019
Ressources documentaires :
 BE Nagios : Etude de la logique de supervision dans Nagios 3. Juillet 2011

o Aboubacar BARRY, Benjamin PICARD, Romain LAMOUR, Vincent WATREMEZ
 Documentation Nagios Version 3.x. - Ed. Française Docbook. Mars 2011
o Ethan Galstad
 Nagios Nicolargo. eBook
o Nicolas Hennion, aka Nicolargo
 Nagios 3 pour la supervision et la métrologie. Eyrolles 2009
o Jean Gabès
 Supervision centralisée d’infrastructures distantes en réseaux avec gestion des alarmes et
notification des alertes. 2005
o CHUNG CHOONG LON François
o LOUSSE Jonathan
M. T. Ait Messaoud| Administration et supervision sous Nagios

Table des matières
1 La supervision : ....................................................................................................................................................... 1
2 Nagios : Les notions de base : ................................................................................................................................. 6
2.1 Historique : ..................................................................................................................................................... 6
2.2 Architecture : .................................................................................................................................................. 7
2.3 Les modes de supervision : ............................................................................................................................. 9
2.3.1 Les contrôles actifs : ................................................................................................................................ 9
2.3.2 Les contrôles passifs :............................................................................................................................ 10
2.4 Rôle des agents : ........................................................................................................................................... 10
2.4.1 NRPE :.................................................................................................................................................... 11
2.4.2 SSH : ...................................................................................................................................................... 14
2.4.3 SNMP : .................................................................................................................................................. 15
2.4.4 NSClient++ : ........................................................................................................................................... 17
2.5 Types d’état SOFT et HARD : ......................................................................................................................... 18
2.6 Données à définir dans Nagios : .................................................................................................................... 22
2.6.1 Arguments, macros et variables d’environnement : ............................................................................. 23
2.6.2 Commande de vérification : .................................................................................................................. 24
2.6.3 Commande de notification : .................................................................................................................. 25
2.6.4 Hôtes : ................................................................................................................................................... 25
2.6.5 Les services : ......................................................................................................................................... 26
2.6.6 Les contacts : ......................................................................................................................................... 27
2.6.7 Groupe de contacts : ............................................................................................................................. 29
2.6.8 Durée et fréquence des checks : ........................................................................................................... 29
2.6.9 Relation parent/enfant : ....................................................................................................................... 32
2.7 Les périodes de temps : ................................................................................................................................ 35
2.8 NSClient++ .................................................................................................................................................... 37
3 Nagios : Configuration .......................................................................................................................................... 47
3.1 Installation : .................................................................................................................................................. 47
3.2 Les fichiers de configuration : ....................................................................................................................... 48
3.2.1 Configuration de Nagios: nagios.cfg ...................................................................................................... 48
3.2.2 Configuration des CGI: cgi.cfg ............................................................................................................... 49
3.2.3 Ressources : .......................................................................................................................................... 49
3.2.4 Commandes : ........................................................................................................................................ 50
3.2.5 Hôtes : ................................................................................................................................................... 67
3.2.6 Services : ............................................................................................................................................... 68
3.2.7 Contacts : .............................................................................................................................................. 69
3.2.8 Groupe de contacts : ............................................................................................................................. 69
3.3 Diagramme des objets Nagios :..................................................................................................................... 70
4 Etude de cas : ........................................................................................................................................................ 71
M. T. Ait Messaoud| Administration et supervision sous Nagios

Administration et supervision Nagios
1 La supervision :
Les objectifs de la supervision, les techniques disponibles :
Les systèmes informatiques d'entreprises associent une diversité de services (routage,
messagerie, proxy, serveur Web, services de fichiers et d'impressions, ...) à plusieurs types
de réseaux (LAN, Intranet, DMZ, Internet, ...). La disponibilité et le bon fonctionnement de
chaque machine et logiciel participant à cet ensemble ont besoin d'être vérifiés
régulièrement.
Des logiciels, les moniteurs, existent afin d'automatiser la vérification des systèmes
informatiques. Ces outils ne fonctionnent pas tous sur le même principe (par exemple tester
les services, interroger ces services sur leurs états, ou attendre une éventuelle alerte émise
par le service). Par ailleurs, l'outil de supervision ne doit pas remettre en cause
l'architecture: il supervise dans les meilleures conditions toutes les machines du réseau sans
l'affaiblir, c’est-à-dire qu'il assure la sécurité tout en absorbant la montée en charge.
La supervision a deux objectifs principaux :

• La prévention des pannes :
La surveillance d'un système permet de connaître sa disponibilité à un instant t, mais
aussi de mesurer dans le temps l'évolution d'un certain nombre de paramètres tels
que l'occupation de l'espace disque ou la charge mémoire. Il devient alors possible par
extrapolation de prévenir le moment de rupture du système en prenant des mesures
préventives.
• La reprise sur incident :
En général, un incident est connu lorsque l'utilisateur final se plaint d'un
disfonctionnement dans sa perception normale d'utilisation. Il faut alors qualifier la
panne, vérifier son origine s'il s'agit réellement d'une panne, puis réparer.
Le cycle d'intervention peut être grandement réduit par le biais de la supervision: dans le
cas d'une panne avérée, le système prévient automatiquement l'équipe concernée, la
réparation s'effectue alors avant même que l'utilisateur ne se soit aperçu du problème;
d'autre part dans le cas d'une fausse alerte (erreur de manipulation de l'utilisateur), le
système de supervision s'assure du bon fonctionnement de tous les équipements d'un coup
d’œil. Enfin, l'archivage des informations sur l'état des systèmes au cours du temps est une
source d'information pour l'analyse "post mortem" d'un incident.
M. T. Ait Messaoud| Administration et supervision sous Nagios Page 1

En résumé, l'objectif est triple: prévenir les incidents par extrapolation des données
fournies, agir rapidement dès qu'un système est noté en erreur et permettre l'analyse "post
mortem" d'un problème grâce aux informations collectées. Un logiciel dit de supervision
doit permettre de remplir tous ces objectifs.
La supervision est un vaste domaine de l'informatique qui inclut plusieurs activités:

surveiller, visualiser, analyser, piloter, agir, … La supervision informatique supervise
l'ensemble du système d'information de l'entreprise qui comprend notamment le réseau et
ses équipements, les serveurs, les périphériques et les applications. Plusieurs méthodes
existent:
 analyser les fichiers log
 récupérer des résultats de commandes et de scripts locaux ou distants
 utiliser le protocole SNMP (Simple Network Management Protocol)
Autour de la supervision, plusieurs modules coexistent:
 La supervision réseau s'occupe de composants matériel tels que serveur, imprimante,

pare-feu, …
 La supervision système s'occupe des applications et logiciels
 La notification permet l’envoi d'alertes par email, par sms, par téléphone, par
avertissement sonore, …
 L'exécution de commandes permet de relancer une application qui fait défaut
 La retranscription d'état du système permet de voir à tout moment l'état de tous les
composants et applications supervisés sous forme d'un graphique, d'une carte ou
d'un tableau. Son but est de rendre les résultats plus lisibles
 La cartographie visualise le réseau supervisé par l'intermédiaire de carte, de
graphique, de tableau, …
 Le "reporting" consiste en un historique complet de la supervision

Rappels sur le protocole SNMP :
 Présentation :
SNMP signifie Simple Network Management Protocol (protocole simple de gestion de
réseau en Français). C'est un protocole qui permet comme son nom l'indique, de gérer les
équipements réseaux ainsi que les machines informatiques. Ce protocole est donc utilisé
par les administrateurs réseaux pour détecter à distance les problèmes qui surviennent
sur leur réseau.
Chaque machine, que ce soit sous Windows ou sous Linux, possède de nombreuses
informations capitales pour l'administrateur réseaux. On retrouve des informations
comme la quantité de RAM utilisé, l'utilisation du CPU, l'espace disque et encore bien
d'autre indicateurs.
SNMP va permettre de remonter ces informations à l'administrateur de façon centralisé
pour pouvoir réagir au plus vite aux pannes éventuelles.
 Fonctionnement :
o Les agents :
Sur une machine à superviser, pour que SNMP envoie les informations que l'on
souhaite il faut qu'un agent soit installé sur celle-ci. Cet agent écoute sur le port 161
et attend que le serveur lui envoie des requêtes pour lui répondre.
L'agent pourra aussi envoyer des alertes lui-même si l'administrateur l'a configuré. Par
exemple pour surveiller l'occupation CPU l'administrateur définira une valeur critique
pour laquelle une alerte doit lui être émise.
Pour finir l'agent pourra aussi agir sur l'environnement local. C'est pourquoi ce
protocole est critique car il peut servir a d'autres personnes mal intentionnées pour
prendre le contrôle a distance de certains équipements sur le réseau.
o Les systèmes de management de réseaux :

Généralement, l'administrateur possède un outil permettant de centraliser ce que lui
retournent ses agents. Et c'est donc cet outil qui va interroger les équipements du
réseau. Il va donc pouvoir gérer un réseau entier grâce à cela.

 La MIB :
o Présentation :
Pour que SNMP fonctionne, il est nécessaire qu'un protocole d'échange soit définit. Il
y a aussi une standardisation des informations que ce protocole peut transporter. C'est
un protocole Internet, il doit être utilisable sur des plates-formes hétérogènes
(matériel comme système d'exploitation).
C'est pour cette raison que l'on parlera de MIB (Management Information Base). En
effet, la MIB est une base de données des informations de gestion maintenue par
l'agent. C’est cette base à laquelle on va demander les informations.
o Structure de la MIB :
La structure de la MIB est hiérarchique : les informations sont regroupées en arbre.
Chaque information a un OID (Object identifier), une suite de chiffres séparés par des
points, qui l'identifie de façon unique et un nom, indiqué dans le document qui décrit
la MIB.
Par exemple, 1.3.6.1.2.1.2.2.1.2 est l'OID ifDescr qui est la chaîne de caractères
décrivant une interface réseau (comme eth0 sur Linux ou Ethernet0 sur un routeur
Cisco).
o Les commandes SNMP :

Il existe 4 types de requêtes SNMP :
 get-request : Le Manager SNMP demande une information à un agent SNMP
 get-next-request : Le Manager SNMP demande l'information suivante à l'agent
SNMP
 set-request : Le Manager SNMP met à jour une information sur un agent SNMP
 trap : L'agent SNMP envoie une alerte au Manager
Les alertes sont transmises lorsqu’un événement non attendu se produit sur l’agent.
Ce dernier informe le manager via une « trap ».
Plusieurs types d’alertes sont alors possibles : ColdStart, WarmStart, LinkDown,
LinkUp, AuthentificationFailure.
Pour chaque envoi de message, une réponse est retournée à l’exception de la
commande « trap ».
Les réponses sont du type suivant :
 get-response : L’information a bien été transmise.
 NoSuchObject : Aucune variable n’a été trouvée.
 NoAccess : Les droits d’accès ne sont pas bons.
 NoWritable : La variable ne peut être écrite.
Echange de message

Voici un schéma récapitulant les échanges pouvant être effectués entre un agent et le
manager :
Le protocole SNMP est principalement utilisé avec UDP/IP. (Il peut aussi utiliser TCP).
L’utilisation d’UDP permet un échange de message plus rapide que l’utilisation de TCP.
L’inconvénient est qu’il est possible de perdre des trames lors de l’échange de
messages (mode non connecté). Les ports UDP sont donc le 162 pour le manager et le
161 pour les agents.
 Solutions applicatives :
Pour simplifier le travail de supervision et ne pas être dépendant du protocole SNMP, les
logiciels de supervisions développent souvent un protocole ou un agent particulier pour
leur solution (NRPE pour Nagios, agent zabbix, etc.).
 Définition des ressources à surveiller :

Globalement, les outils de supervision sont utilisés pour la surveillance :
o Matérielle (activité d'un équipement, charge, ...)
o Réseau (débit, latence, taux d'erreur, QoS, protocoles, sécurité ...)
o Système (logs, performances, intégrité)
o Applicative (performances, modifications de configuration, analyse)
Les actions liées aux événements peuvent être :
o Un enregistrement dans un journal
o Un tracé graphique
o Une alerte (mail, SMS, …)
o Une exécution de script pour automatiser les tâches à faire.

2 Nagios : Les notions de base :
2.1 Historique :
L’histoire d’un outil peut nous en apprendre beaucoup sur lui.
Nagios est développé par Ethan Galstad et débute son histoire en 1999 sous le nom de
NetSaint. Quelque temps plus tard, à cause d’un problème de propriété intellectuelle sur le
nom, il devient Nagios. Actuellement en version 4.1.1, il a plus de dix-sept ans d’existence.
Il a évolué depuis ses tous débuts afin de s’adapter à des parcs de plus en plus importants,
tout en améliorant ses performances et ses capacités de gestion de configuration.
Atouts de Nagios par rapport aux autres outils open source :

Nagios n’est pas le seul outil de supervision open source. Par rapport à ses concurrents, sa
plus grande force réside dans sa modularité complète. Il n’a pas de domaine de prédilection
et peut observer tout ce que ses plug-ins sont capables de rapporter.
D’autres outils open source de supervision existent, mais ils ne sont pas aussi modulaires ou
performants que Nagios. On trouve aussi sur le marché des outils de même envergure, mais
non complètement libres.
Zabbix : la supervision simplement

Ce premier outil est très orienté système et s’occupe en interne de la métrologie. Il n’est pas
aussi modulaire que Nagios. Il est beaucoup plus orienté tout-en-un, avec des agents dédiés
qu’il faut déployer sur les éléments distants.
Si ce choix permet de gagner du temps lors de la première mise en place, il se révèle gênant
lorsqu’il s’agit de superviser des éléments non prévus par la solution.
Quant aux possibilités de configuration elles sont moins étoffées que celles de Nagios, ce qui
peut être contraignant lorsque le nombre d’éléments commence à devenir important. Il
manque à Zabbix des solutions simples pour gérer les pertes massives de connexion et tout
ce qui concerne la gestion des dépendances entre éléments.
Ce dernier point est, encore une fois, problématique lorsque la supervision couvre un
nombre élevé d’éléments.
Cacti : la métrologie avec SNMP

Cacti, quant à lui, est bien plus orienté réseaux et métrologie. Il repose principalement sur
l’utilisation du protocole SNMP – très répandu dans le monde des réseaux.
La supervision n’est pas le rôle premier de Cacti. Elle est basée principalement sur des
indicateurs qui doivent rester en deçà de seuils fixés. Nagios préfère laisser le choix au plug-
in de se baser ou non sur des valeurs. Cacti est cependant très efficace dans la gestion des
données de performances. C’est pour cela qu’il est parfois utilisé pour gérer les données
issues de Nagios.
Nous utiliserons pour la métrologie plutôt une méthode basée sur Centreon, qui s’intégrera
plus naturellement dans la solution globale que nous mettrons en place par la suite.
OpenNMS : la supervision très SNMP
Cet outil de supervision est globalement moins avancé que Nagios. Sa configuration est très
lourde à gérer, même lorsque le nombre d’éléments supervisés est réduit. Il ne possède pas
de fonctionnalité de gestion des dépendances, ce qui représente un handicap lourd dans les
environnements complexes.
Hors des tests SNMP classiques, OpenNMS est très vite limité. Il est possible d’inclure des
tests supplémentaires, mais c’est une solution relativement lourde à gérer.
Ganglia : la métrologie des clusters

Ganglia est dédié à la métrologie des performances pour les environnements de type cluster.
Il est conçu pour minimiser son impact sur les machines supervisées. Il n’est pas aussi
modulaire que Nagios et ne gère que très mal les parcs hétérogènes. Il n’est pas axé
supervision mais bien métrologie et ses possibilités d’alertes s’en ressentent fortement.
Zenoss : très bonne supervision, mais pas complètement libre

Concurrent très sérieux de Nagios, il a comme particularité de ne pas être complètement
libre. Là où Nagios est entièrement en GPL, Zenoss est disponible sous trois versions
différentes, dont deux non libres et soumises à licences. La version libre est assez limitée
dans ses possibilités. Les fonctionnalités de haute disponibilité ou de supervision des
environnements virtualisés ne sont tout simplement pas accessibles dans cette version.
Si les versions sous licences possèdent des avantages face à Nagios, comme la possibilité
native d’avoir une découverte du réseau, elles sont moins avancées sur certains points tels
que l’envoi d’alertes, limité aux e-mails et aux SMS, ou, à l’instar de Zabbix, sur les possibilités
de configuration qui restent limitées.
Zenoss ressemble fortement à Zabbix au sens où il gère aussi lui-même la métrologie et
propose une interface web complète, là où Nagios délègue ces aspects à des outils tiers.
En matière de performances, Nagios n’a rien à envier aux outils de supervision propriétaires.
Il permet, avec un serveur modeste, de surveiller près de 10 000 éléments.
Si cette performance est déjà tout à fait honorable, Nagios propose des options pouvant
sensiblement augmenter cette valeur.
L’architecture même de Nagios permet de surveiller autant de nœuds que souhaite
l’utilisateur. La supervision peut être distribuée entre plusieurs serveurs, tout en centralisant
l’administration sur une unique console.
2.2 Architecture :
Nagios est un simple programme écrit en langage C. Si on exclut la partie interface web de
visualisation, il ne fait pas plus de 60 000 lignes de code, ce qui est assez faible pour un outil
d’une telle renommée.

Nagios se lance en tant que processus d’arrière-plan sur un serveur Unix, GNU/Linux de
préférence. Il lit la configuration fournie par l’utilisateur et commence à ordonnancer ses
vérifications. Lorsqu’il s’aperçoit d’une erreur sur un élément supervisé, il notifie les
utilisateurs concernés.
 Le Cœur :
Le cœur de Nagios consiste avant tout en un moteur d'ordonnancement. Cet ordonnanceur
gère le séquencement des vérifications, ainsi que des événements, tels que les alertes, les
escalades (notifications progressives en fonction du temps) et les actions correctives. Il est
important d’étaler au maximum les vérifications pour lisser la charge qui risque d’être trop
importante pour que les sondes aillent au bout de leurs tâches. (cf. annexe : pour plus
d’information sur l’étalement des vérifications)
 Base de données :
Permet d’enregistrer des événements, les données de performances relatives aux contrôles
et aux plugins. Dans le cas d’instances multiples de Nagios, cette base de données permet
de centraliser leurs informations.
 CGI (Common Gateway Interface) :

C’est une interface utilisée par un serveur http permettant d’intégrer des services écrits dans
différents langages de programmation.
 L’Interface Web :
C’est une interface graphique qui permet d’avoir une visualisation complète des hôtes et
ressources supervisés. De plus, il est possible de gérer une partie de la configuration via cette
interface.

 Les Plugins :
Les plugins sont des programmes exécutables ou des scripts qui permettent de déterminer
le statut des hôtes ou services sur le réseau. Ces plugins peuvent être développés avec
n’importe quel langage de programmation mais doivent respecter un certains formats
d’affichage de retour afin de garantir leur interopérabilité.
La convention à respecter est la suivante :
0 : « Tout va bien » (OK)
1 : Avertissement (WARNING)
2 : Alerte (CRITICAL)
3 : Statut inconnu (UNKNOWN)
2.3 Les modes de supervision :
2.3.1 Les contrôles actifs :

La méthode de supervision qui, pour la plupart des utilisateurs, paraît la plus naturelle est la
méthode active. Celle-ci consiste à faire lancer par Nagios une commande qui va vérifier l’état
d’un élément distant.
Pour cela, l’utilisateur doit fournir à Nagios, dans la configuration, les commandes à lancer
pour effectuer ces vérifications. Ces commandes correspondent à des scripts ou des
exécutables déposés sur le serveur de supervision : ce sont nos sondes. Nagios va simplement
les lancer à intervalles réguliers et recevoir en résultat l’état de l’élément surveillé.
Pour lancer cette vérification, Nagios se dédouble et l’un des deux Nagios résultant lance la
commande demandée. Il peut fournir à la commande des arguments particuliers, afin que
celle-ci interroge le bon hôte distant. Une fois que le plug-in a l’information, il la traite et
décide si elle est correcte ou non. Il renvoie enfin le résultat au premier Nagios.
Obtention sans rebond

La technique sans rebond consiste à aller chercher l’information de manière directe, sans
passer par des intermédiaires. On peut, par exemple, décider de vérifier directement si un
port réseau est ouvert sur un serveur.

Obtention avec rebond
La méthode avec rebond consiste à demander à un autre élément de faire la vérification à
notre place. Ceci se justifie, par exemple, pour des raisons de sécurité ou bien de
performances.
Effectuer soi-même la vérification peut être consommateur de ressources. On peut
demander à un autre membre du réseau de prendre en charge une partie du travail.
Lorsque l’accès à certaines zones du réseau n’est autorisé que pour certains membres, ce
sont eux qui vont pouvoir faire les interrogations en lieu et place du serveur central.
2.3.2 Les contrôles passifs :

Une autre méthode, moins connue, consiste à faire envoyer au serveur central les
informations de supervision. Celui-ci n’a plus qu’à attendre l’arrivée des informations et à les
traiter de la même manière qu’avec une interrogation active.
Cette méthode peut être justifiée pour des raisons de performances ou bien être particulière
à certains éléments surveillés.
Certaines erreurs sont complexes à vérifier de manière active. On peut prendre comme
exemple la supervision des sauvegardes. Elles ne se terminent pas toujours à la même heure
et il est donc très compliqué de décider d’une heure de vérification.
Un envoi passif effectué par le script de sauvegarde avertit Nagios de la réussite ou non de
l’opération.
Cette méthode est, dans ce genre de situation, beaucoup plus simple à mettre en place que
la méthode active. En outre, en plus d’être complexe à ordonnancer, ce genre de méthode
doit vérifier dans les journaux de la sauvegarde si elle s’est bien passée ou non – la charge de
lancer les commandes de vérification pouvant se révéler très lourde pour le serveur central.
La méthode passive est donc plus légère pour le serveur principal. Il faut tout de même faire
attention car ceci a un coût au niveau de la gestion de configuration. Il faut qu’un élément
décide de l’envoi d’informations. Si ce n’est pas Nagios qui le fait, ce doit être l’élément
distant. L’envoi des informations doit être planifié et implique une configuration particulière
des éléments concernés. Ainsi décentralisée, une telle configuration peut être très ardue à
maintenir.
2.4 Rôle des agents :

Par exemple, pour obtenir les informations de charge des serveurs, il faut se placer
directement sur ces serveurs.
Nagios ne peut pas lancer seul une commande de vérification sur les serveurs distants.

Il ne peut que lancer des commandes locales. Nous allons utiliser des agents de supervision
sur les éléments distants. Ce sont des démons qui écoutent les demandes d’informations de
Nagios et lui répondent. Nous allons voir ici les principaux agents utilisés.
2.4.1 NRPE :
NRPE est l’agent déployé classiquement sur les serveurs de type Unix. Il signifie « Nagios
Remote Process Executor » (exécuteur distant de processus Nagios). Il permet à Nagios
d’exécuter à distance des plug-ins déposés par l’administrateur.
Comme Nagios, NRPE ne sait lui-même rien faire. Les plug-ins déposés sont identiques à ceux
présents sur le serveur de supervision. NRPE sert d’intermédiaire entre Nagios et ces sondes.
Nagios lance comme plug-in, sur son serveur, l’exécutable check_nrpe. Celui-ci envoie une
requête de supervision à l’agent NRPE. Elle correspond à une entrée dans la configuration de
l’agent. Cette entrée contient un script à lancer, avec ses arguments. Le démon lance le plug-
in et retourne le résultat à check_nrpe. Ce résultat est composé du code retour du plug-in et
des lignes de sortie, comme n’importe quelle sonde Nagios. L’exécutable check_nrpe
transmet tout simplement ces informations à Nagios.
Nous pouvons également noter que la communication entre check_nrpe et le démon
NRPE se fait à travers un flux SSL. Il n’y a donc pas de risque qu’un pirate récupère des
données sensibles. Le diagramme suivant résume ce fonctionnement.
Fichier de configuration principal

Paramètres du démon
L’agent NRPE ne possède au départ qu’un seul fichier de configuration. Il se trouve, sur une
installation par défaut, dans /usr/local/nagios/etc. On peut utiliser les paramètres suivants :
• server_port : port TCP sur lequel le serveur écoute les requêtes de Nagios. Par défaut, sa
valeur est 5666 ;
• server_address : IP sur laquelle le démon écoute. Si non spécifiée, il écoute sur toutes les
adresses disponibles ;
• nrpe_user : utilisateur sous lequel le démon est exécuté. Tout comme pour Nagios, il n’est
ni possible, ni recommandé d’utiliser root ;
• allowed_hosts : liste des IP des serveurs pouvant effectuer des demandes au démon. On y
place logiquement l’adresse du serveur Nagios ;

• dont_blame_nrpe : autorise ou non l’utilisation d’arguments envoyés par le client au démon
NRPE ;
• command_timeout : temps en secondes laissé aux commandes lancées pour s’exécuter.
Si le temps imparti est écoulé, la commande est tuée.
Définition des commandes
On doit également configurer les commandes à lancer lors d’une interrogation. Cela se fait
grâce aux entrées du type suivant :
Définition d’une commande dans nrpe.cfg

command[nom]=chemin_du_plugin paramètres
Il faut attribuer à chaque commande à lancer un nom avec lequel check_nrpe va l’appeler.
On doit indiquer le chemin complet vers la sonde à lancer. En ce qui concerne les arguments,
on peut laisser l’utilisateur les spécifier lors de la demande. Cela n’est autorisé que si le
paramètre dont_blame_nrpe a la valeur 1. Tout comme dans la configuration de Nagios, les
arguments sont définis par $ARG1$, $ARG2$, etc.
Voici deux exemples de définition pour observer la charge des serveurs grâce à la commande
check_load. Celle-ci sera étudiée plus en détail au chapitre 14.
Définition standard
command[load]=/usr/local/nagios/libexec/check_load -w 1,1,1 -c 2,2,2
Voici la même commande, mais en utilisant des arguments variables :
Définition avec arguments

command[load]=/usr/local/nagios/libexec/check_load -w $ARG1$ -c $ARG2$
Gérer les exceptions de configuration
Dans le cas où l’on doit déployer un grand nombre d’agents sur ses serveurs, on utilise le
même fichier de configuration. Cependant, certains d’entre eux présentent des exceptions.
Par exemple, sur certains vieux systèmes, une information peut ne pas être disponible. Un
plug-in fonctionnant correctement sur le reste du parc n’y fonctionne alors pas. Si on laisse la
même commande d’appel, on risque de se retrouver avec une exécution systématiquement
en erreur. Les exceptions dans la configuration des agents NRPE doivent être possibles.
Si l’on n’utilise pas de moyen de gestion de configuration évolué sur ses serveurs, on doit
utiliser le paramètre include du fichier de configuration nrpe.cfg. Ce paramètre permet
d’appeler un autre fichier de configuration comme s’il était placé à la suite.
Pour gérer les exceptions, nous créons un fichier de configuration nommé specifique.cfg situé
à côté de nrpe.cfg. Nous y plaçons nos exceptions en redéfinissant les commandes que nous
souhaitons modifier.
Dans le fichier nrpe.cfg, le fichier est inclus en dernière ligne :

Inclusion du fichier spécifique au serveur
include=/usr/local/nagios/etc/specifique.cfg
Si une commande est présente deux fois dans le fichier de configuration, c’est sa dernière
occurrence qui est prise en compte. Dans notre cas, puisque l’on a appelé specifique.cfg à la
fin de nrpe.cfg, ce sont les valeurs spécifiques qui priment. On a tout loisir de redéfinir, si
besoin, des commandes ou d’en définir de nouvelles.
Une méthode de gestion de configuration consiste à avoir le même fichier nrpe.cfg pour tous
les hôtes. Seuls les fichiers specifique.cfg sont particuliers à chaque nœud. Lors de la mise à
jour du nrpe.cfg commun sur tous les serveurs, on ne craint plus de perdre de la
configuration spécifique à un nœud.
Lancement de l’agent
L’agent n’est en fait composé que d’un binaire nrpe, de son fichier de configuration et des
plug-ins qu’il lance. Il peut être lancé à travers xinetd, mais cette possibilité n’est pas étudiée
ici.
Dans le cas d’un lancement en mode standalone, il faut le lancer comme ceci :
Lancement de NRPE
/usr/local/nagios/bin/nrpe -d -c /usr/local/nagios/etc/nrpe.cfg
NRPE s’exécute sous l’identité de l’utilisateur spécifié dans son fichier de configuration, à
condition que celui-ci ne soit pas root. En effet, dans ce cas, il ne se lance pas.
On utilise généralement un compte non privilégié nommé nagios.
Exemple d’interrogation
Depuis le serveur Nagios, on lance la commande check_nrpe avec comme paramètres l’hôte
sur lequel est lancé NRPE, ainsi que la commande désirée (en l’occurrence, la commande
référencée par check_load). Plaçons-nous tout d’abord dans la situation où l’utilisateur ne
peut pas fournir d’arguments à la commande :
Interrogation de l’agent NRPE
check_nrpe -H srv-web1 -c load
OK - Charge moyenne: 0.51, 0.28, 0.28|load1=0.510;1.000;2.000;0;
load5=0.280;1.000;2.000;0; load15=0.280;1.000;2.000;0;
echo $?
0
Dans le cas où l’on peut fournir des arguments, nous avons :
Interrogation avec arguments
check_nrpe -H srv-web1 -c load -a 1,1,1 2,2,2
load5=0.360;1.000;2.000;0; load15=0.310;1.000;2.000;0;
echo $?
0

Dans les deux cas, du point de vue de Nagios, le résultat est le même que celui d’une
commande locale. Il en retire les mêmes informations, à savoir le code retour et les lignes de
données.
2.4.2 SSH :
Lancement de commandes à travers SSH
NRPE permet de lancer des commandes à distance, ce qui peut également être réalisé grâce
à SSH. Ce protocole permet de lancer une commande sur un serveur distant.
De plus, le code retour et les messages de sortie sont conservés à travers l’utilisation de SSH.
Si nous reprenons notre exemple précédent en utilisant SSH, nous obtenons :
Lancement d’une commande par SSH

ssh srv-web1 '/usr/local/nagios/libexec/check_load -w 1,1,1 -c 2,2,2'
Nous avons besoin d’un compte sur srv-web1. Nous utilisons le compte nagios que nous
aurions utilisé pour NRPE. La commande renvoie ce qui suit :
Résultat
load5=0.350;1.000;2.000;0; load15=0.350;1.000;2.000;0;
echo $?
0
Nous obtenons le même résultat que si nous l’avions lancé à travers NRPE.
Problème de l’authentification
Cette méthode présente un problème : le serveur distant demande une identification.
Lorsqu’on fait des des tests, on peut saisir un mot de passe ; ce n’est pas le cas si la commande
est lancée par Nagios. Là encore, le protocole SSH propose une solution.
Il est possible d’utiliser une méthode d’authentification par chiffrement asymétrique.
Sans entrer dans le détail, l’utilisateur crée deux clés liées :
• une publique, qu’il peut fournir à volonté ;
• une privée, qu’il doit garder jalousement.
La clé privée peut déchiffrer des messages codés avec la clé publique de l’utilisateur.
Si un serveur envoie un message aléatoire chiffré avec la clé publique d’un utilisateur, seul ce
dernier peut retrouver le message original grâce à sa clé privée. Cela permet d’authentifier
formellement un utilisateur.
Pour générer les clés, on utilise la commande ssh-keygen :
Génération de clés pour SSH
ssh-keygen -t rsa
Lorsque le programme demande une passphrase, il faut la laisser vide. Il s’agit d’un mot de
passe chiffrant la clé privée. Nous ne pouvons pas l’utiliser ici car il faudrait la saisir à chaque
fois que l’on utilise la clé, ce qui n’est pas possible au sein de Nagios.
Cette commande génère les deux clés. La clé privée est ~/.ssh/id_rsa, la publique
~/.ssh/id_rsa.pub.
Il faut déployer la clé publique sur le serveur distant. Nous utilisons pour cela le programme
ssh-copy-id qui facilite grandement la tâche :
Déploiement de clés sur un compte distant

ssh-copy-id -i ~/.ssh/id_rsa.pub nagios@srv-web1
Une fois la clé en place, l’utilisateur sur le serveur maître peut se connecter sans mot de passe
sur le serveur srv-web1. Il peut également y lancer des commandes.
Utilisation de SSH à la place de NRPE

L’utilisation de SSH en lieu et place de NRPE est possible, mais il faut en mesurer l’impact.
Avec SSH, nous ne pouvons pas utiliser les exceptions de configuration comme nous l’avons
fait avec le fichier specifique.cfg. De plus, la charge de calcul d’une requête SSH est plus
importante que celle d’une demande NRPE. Pour utiliser SSH, il faut que l’utilisateur nagios
du serveur Nagios ait un accès au shell sur les serveurs distants. Si des méthodes permettent
de limiter l’utilisation de ce shell, elles sont cependant lourdes à gérer.
SSH a pourtant un atout non négligeable : il est déjà présent sur la quasi-totalité des serveurs
Unix. Il évite d’avoir à déployer un nouvel agent. Il faut cependant que les plug-ins de
supervision soient présents.
Les administrateurs peuvent choisir entre ces deux solutions celle qu’ils préfèrent suivant
leurs facilités de déploiement d’un agent ou au vu des problématiques de charge sur le
serveur central.
2.4.3 SNMP :
Il est presque impossible de trouver un élément réseau sur lequel on peut installer les
applications que l’on souhaite. Ce sont de véritables boîtes noires. La mise en place de NRPE
étant impossible, voyons comment les superviser.
Le protocole SNMP et les OID

Pour obtenir des informations sur l’état d’un équipement réseau, il faut passer par un démon
qui est lui présent sur la quasi-totalité des équipements réseau : SNMP (Simple Network
Management Protocol, protocole simple de gestion réseau).
Ce protocole peut être découpé en deux fonctionnalités principales :
• un client obtient des informations en lançant une requête au serveur. On nomme cela le
poll SNMP ;
• l’élément réseau envoie une information sous la forme d’une alerte à un démon distant. Ce
sont les traps ou alertes SNMP. Ce mécanisme sera étudié dans un autre chapitre car il fait
partie des méthodes passives.
Les informations exportées par SNMP sont nombreuses et peuvent varier suivant le
constructeur. Elles sont indexées sur un arbre dont chaque entrée est un OID (Object unique
IDentifier). Elles sont regroupées dans des fichiers nommés MIB. Ils représentent la
cartographie des données de l’arbre. Chaque constructeur possède une branche. Il peut y
faire figurer les informations qu’il souhaite.
Certaines branches sont standardisées. On peut citer pour exemple la MIB HOSTRESOURCES.
C’est dans cette dernière que nous allons prendre la plupart de nos informations.
Dans les versions les plus répandues de SNMP, les versions 1 et 2c, la sécurité est basée sur
un mot de passe nommé communauté. La valeur par défaut de ce mot de passe est public. Il
est diffusé en clair sur le réseau.
La version 3, la plus récente, possède de véritables mécanismes de sécurité. Elle n’est
malheureusement pas encore largement déployée.
Exemple d’interrogation SNMP

Nous cherchons à obtenir l’utilisation CPU sur un routeur administrable à l’adresse
192.168.0.254. La communauté utilisée est public. Le plug-in récupère l’OID
.1.3.6.1.2.1.25.3.3.1.2 qui correspond à la charge CPU et compare la valeur aux deux seuils
que nous lui avons spécifiés.
Récupération de la charge CPU par SNMP

check_snmp_switch_cpu.pl -H 192.168.0.254 -C public -w 50 -c 60
SNMP_ENVIRONMENT OK : CpuUtil=10%|CpuUtil=10%
SNMP sur les serveurs
Les serveurs possèdent également des services SNMP. Ils exportent les valeurs de la MIB
HOST-RESOURCES. Celle-ci contient les valeurs classiques comme l’utilisation des
processeurs, de l’espace disque, de la mémoire ou du trafic réseau.
Si, dans les équipements réseau, l’utilisation du SNMP est imposée, ce n’est pas le cas dans
le cadre des systèmes d’exploitation. Les informations disponibles par ce biais sont limitées.
On y trouve des valeurs classiques qui suffisent dans une partie des cas.
Dans de nombreuses situations, elles ne sont pas suffisantes. Sur certains systèmes, la seule
information disponible à propos de la mémoire est l’utilisation de la mémoire virtuelle. Celle-

ci regroupe la mémoire physique et l’espace d’échange. Lorsque celui-ci est utilisé, il est bien
souvent trop tard. Un tel indicateur n’est pas suffisant.
Des plug-ins dédiés lancés par des agents sont plus appropriés.
2.4.4 NSClient++ :
Un client un peu particulier est disponible sur les environnements Windows. Il regroupe en
son sein un agent NRPE et des informations déjà exportées, comme le fait SNMP.
Il est basé sur des modules sous forme de DLL. L’un d’entre eux porte le nom NRPE. Il est
utilisé comme agent du même nom au sein de NSClient++. Tout comme pour son pendant
Unix, il ne dispose pas, par défaut, de sonde. L’administrateur doit lui en fournir.
D’autres modules exportent nativement des données. On peut dresser la liste des principales,
qui permettent de faire un rapide tour de l’état du système.
• espace disque ;
• utilisation des processeurs ;
• utilisation de la mémoire ;
• état des services.
Deux clients sont utilisés :
• check_nrpe pour les exécutables lancés par l’agent ;
• check_nt pour les interrogations des autres modules.
Mise en place
L’agent possède un exécutable d’installation. Il s’installe par défaut dans le répertoire
C:\Program Files\NSClient++. Pour ceux qui souhaitent automatiser l’installation, il suffit de
déposer les fichiers de l’agent dans un répertoire et de lancer la commande suivante :
Installation de NSClient++
NSClient++ /install
Pour le démarrer, il suffit de lancer le service du même nom.
Le module NRPE écoute sur le port classique 5666/TCP. Les autres modules sont sur le port
12489/TCP.

La configuration est également découpée en deux parties, une pour chaque élément de
l’application. Elle se trouve dans le fichier NSC.ini. La configuration et l’utilisation de l’agent
NRPE sont identiques à celles de la version UNIX, nous n’y reviendrons pas.
La configuration du reste de l’agent commence par la déclaration des modules utilisés.
On les place dans la partie [modules] du fichier de configuration. Voici un exemple de
configuration contenant les modules les plus classiques:
Configuration des modules

[modules]
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
CheckEventLog.dll
CheckWMI.dll
Vient ensuite la partie [Settings] où se trouvent les clients autorisés à dialoguer avec l’agent
et la définition d’un mot de passe si besoin. Voici un exemple pour un serveur Nagios dont
l’adresse est 192.168.0.2 :
Paramètres de sécurité
[Settings]
password=superpassword
allowed_hosts=192.168.0.2
use_file=1
Le paramètre use_file permet de signaler à NSClient++ de prendre ses paramètres dans le
fichier de configuration plutôt que dans la base de registre. Cette dernière utilisation est à
éviter, à la fois du point de vue de la facilité d’administration et pour unifier l’administration
des différents agents sous Windows et sous Unix.
2.5 Types d’état SOFT et HARD :

Nous venons de voir ce qu’il faut définir dans Nagios pour lui indiquer les éléments à
superviser, ainsi que les commandes utilisées pour surveiller tout ce petit monde.
Nous allons maintenant regarder plus en détail la logique de supervision de Nagios.
Nous avons très brièvement survolé ce sujet lors des explications sur les paramètres de retry
des hôtes et des services notamment.
Nous avons indiqué que les notifications sont envoyées uniquement si les états des hôtes et
services ont été validés. Ces états (UP, DOWN, UNREACHABLE pour les hôtes, OK, WARNING,
CRITICAL et UNKNOWN pour les services) peuvent être de deux types bien différents :
• SOFT : le problème vient juste d’être détecté et demande vérification ;
• HARD : le problème est confirmé.
Les états de bon fonctionnement (UP et OK) ne peuvent être que de type HARD : le type
SOFT n’a pas une grande signification pour eux, à une exception près que nous verrons par
la suite.
Les nœuds et les services possèdent un paramètre important dans ce contexte :
max_check_attempts. Il correspond au nombre de fois où une commande retourne un état
différent de UP ou OK avant de passer en type HARD. Il est important de noter qu’ici, le
premier test retournant l’erreur est pris en compte dans max_check_attempts. Si l’on
souhaite dès la première erreur passer en état HARD, il suffit donc de placer cette propriété
à 1.
Les intervalles de vérification ne sont pas les mêmes entre les états SOFT et HARD. Les
éléments (services et nœuds) ont les propriétés suivantes :
• check_interval : correspond à l’intervalle de vérification en état HARD ;
• retry_interval : correspond à l’intervalle de vérification en état SOFT.
Nous allons avoir deux intervalles de supervision : un quand l’information est sûre, un autre,
généralement inférieur, qui est utilisé uniquement pour clarifier une situation.
Exemple de changement de type d’état

Nous pouvons définir un service comme suit :
Exemple de paramétrage d’un service

max_check_attempts 4
check_interval 5
retry_interval 3
La vérification se fait en temps normal toutes les 5 minutes. Si un problème survient
(WARNING, CRITICAL ou UNKNOWN), alors on effectue 3 essais supplémentaires. On n’en
fait que 3, le passage en état HARD intervient au bout de 4 tests. On vient déjà d’en réaliser
un, celui qui a révélé l’anomalie. Nous nous retrouvons alors à ce moment en état de type
SOFT.

Les 3 autres vérifications sont réalisées avec un intervalle de temps de 3 minutes (paramètre
retry_interval). Si, au bout de ces tests, la situation n’est pas redevenue OK ou UP, alors le
dernier état passe en état de type HARD. Les tests sont alors conduits toutes les 5 minutes.
Lorsque la situation revient en état UP ou OK, l’état reste en HARD et on continue de vérifier
toutes les 5 minutes jusqu’à l’arrivée d’une nouvelle erreur.
Nous pouvons observer cela sur le diagramme de la figure précédente.
Un état SOFT un peu particulier : SOFT-RECOVERY

Il arrive que, lors des vérifications supplémentaires du type SOFT, le problème soit résolu et
que la commande renvoie un résultat UP ou OK. Dans ce cas, le type d’état ne va pas être
SOFT car il est réservé aux problèmes, ni HARD car l’état n’est pas vérifié, mais SOFT-
RECOVERY.
Ce type d’état se comporte comme un type SOFT classique, c’est-à-dire que les vérifications
rapprochées continuent. Le résultat du dernier test est retenu comme l’état HARD.
Voici un exemple d’une telle problématique. Ici, l’état OK est obtenu le temps d’une seule
vérification, qui n’est pas la dernière. C’est l’état CRITICAL qui est retenu comme état HARD.
Notifications de problèmes
Continuons notre étude avec les notifications.
Notifications : le but des types d’état SOFT et HARD

Nous pouvons légitimement nous demander à quoi servent les types SOFT et HARD. Ils sont
simplement utilisés dans le cadre de la notification des problèmes aux contacts.
Peu de situations justifient d’envoyer une alerte sur un élément si, quelques secondes après,
elle n’est plus valable. C’est le cas, par exemple, lors d’un problème réseau momentané. Pour
certains services ou hôtes, il peut être intéressant d’être averti du moindre souci ; toutefois,
dans une grande majorité des cas, il est préférable de vérifier l’information avant de l’envoyer
aux utilisateurs.

C’est à cela que servent les types SOFT et HARD : ils permettent de vérifier la pertinence d’une
alerte. Lors de la phase SOFT, Nagios tente de vérifier si l’erreur est effectivement toujours
présente. La vérification est répétée autant de fois que le souhaitent les utilisateurs, grâce
aux paramètres max_check_attempts et retry_interval.
Renvoi de notifications
Une fois que l’état est validé, en phase HARD, Nagios notifie les contacts s’ils le souhaitent.
Cette notification intervient dès le passage en état HARD. L’utilisateur peut, avec le paramètre
notification_interval, spécifier à Nagios l’intervalle de temps entre deux notifications. La
notification est relancée tant que l’état n’est pas redevenu UP ou OK.
Lorsque l’état revient à la normale et si l’utilisateur l’a décidé dans le paramètre
notification_options, Nagios envoie une alerte de recovery pour les services, d’UP pour les
hôtes. Ce paramètre doit être supérieur à la valeur check_interval. Si cette valeur était
inférieure, Nagios enverrait une notification alors qu’il n’a pas re-vérifié l’état de l’élément,
ce qui n’est pas logique. La seule exception est la valeur 0 : elle signifie de n’envoyer qu’une
seule notification pour le problème.
Exemple d’ordonnancement des notifications
Si nous positionnons les paramètres comme ceci, nous obtenons le comportement du
diagramme suivant.
notification_interval 8
notification_options w,c,r
Nous remarquons qu’à t = 19 min une notification d’alerte critique est envoyée. Elle
correspond au passage en état HARD. 8 minutes après, à t = 27 min, vu que le service est
toujours en état CRITICAL, une autre notification est levée. Pour finir, une dernière
notification est envoyée à t = 29 min. C’est une notification recovery de service.
Nous remarquons dans le paramètre notification_options le champ r : l’administrateur
souhaite donc qu’une telle notification soit envoyée.

Il est à noter que, pour qu’une notification soit levée, elle doit survenir durant la période
notification_period définie sur les services et les hôtes. Si cette condition n’est pas vérifiée,
la notification n’est pas envoyée.
Notifications : la configuration des contacts prime

Nous nous souvenons que les contacts possèdent les deux propriétés
service_notification_period et service_notification_options (il en va de même pour les hôtes).
Elles permettent de spécifier les notifications que le contact souhaite accepter.
Ces options agissent comme un filtre. Elles peuvent, par exemple, être définies sur l’hôte ou
le service, mais pas sur un contact. Dans ce cas, ce dernier n’est pas notifié du problème.
Si nous avons un service défini comme :

mais que le contact a seulement défini :
notification_options w,c
lors de la levée de la notification de recovery (option r), le contact ne reçoit pas l’information.
De même, si c’est l’inverse qui est configuré :
notification_options w,c
sur le service et :
sur le contact, la notification de recovery n’étant pas levée par le service, le contact ne la
reçoit pas.
2.6 Données à définir dans Nagios :

Les éléments distants à superviser devront être définis dans les fichiers de configuration de
Nagios. Ces fichiers sont généralement situés dans le répertoire etc de l’arborescence de
Nagios, par défaut /usr/local/nagios. Ils sont construits sur le modèle suivant :
Définition d’un objet type
define type{
parametre1 valeur1 ;commentaire
parametre2 valeur2
}

2.6.1 Arguments, macros et variables d’environnement :
Comme tout programme, les commandes ont des arguments et des environnements
particuliers.
Arguments des commandes :
Nous avons vu que nous pouvons passer des arguments aux commandes. Ces arguments
peuvent être utilisés avec les macros $ARGn$ définies dans les commandes, qu’il s’agisse de
commandes de vérification ou de notification. Si l’on souhaite utiliser des arguments, on doit
appeler la commande de la manière suivante :
Arguments d’une commande
check_command check_tcp!80!5
avec 80 pour $ARG1$, 5 pour $ARG2$, etc.
Il n’est cependant pas souhaitable de tout faire passer par des arguments. Si l’on souhaite
donner à la commande, par l’intermédiaire d’une variable, l’adresse réseau de l’élément
surveillé, il faut réécrire l’adresse de l’hôte à tester dans l’appel de la commande par le
service. C’est dommage car l’information est déjà définie dans l’élément host auquel on
rattache le service. Nagios permet à la commande de prendre directement l’information
qu’elle souhaite à la source.
Macros :
Nous avons vu plusieurs macros au cours de ce chapitre. Au lancement d’une commande,

Nagios en positionne un grand nombre qui changent de valeurs en fonction du contexte. La
macro correspondant à l’adresse de l’hôte sur lequel est lancée la vérification est tout
simplement $HOSTADDRESS$. Ceci permet de définir simplement notre test TCP :
Exemple d’utilisation d’une macro
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$
Nous remarquons que la macro $USER1$ est utilisée. Elle est définie dans le fichier
ressources.cfg. L’utilisateur peut définir 32 macros $USERn$. La plus commune est $USER1$,
qui représente en fait le répertoire dans lequel sont placés les scripts de supervision,
généralement /usr/local/nagios/libexec/. Ceci évite de saisir le répertoire à chaque définition
de commande.
À l’appel de la commande avec le paramètre !80, sur un hôte ayant comme adresse
192.168.0.1, Nagios lance en fait la commande :

/usr/local/nagios/libexec/check_tcp -H 192.168.0.1 -p 80
Il est possible – et fortement conseillé – de tester les commandes de vérification directement

depuis un shell sur le serveur de supervision.
Variables d’environnement :
Il y a une différence entre une commande lancée directement depuis un shell et la même
commande lancée depuis Nagios : l’environnement. Sur le serveur de supervision, Nagios est
exécuté par un utilisateur non privilégié, généralement nommé nagios. Lorsqu’il lance une
commande, Nagios retire les variables d’environnement de l’utilisateur et positionne les
siennes : les macros. Il n’est pas nécessaire de passer une macro en argument si le programme
lancé est capable de la récupérer dans ses variables d’environnement.
Il n’est pas conseillé de fonctionner de cette manière, ne serait-ce que par souci de lisibilité
des commandes lancées. De plus, ces commandes sont plus compliquées à tester
directement depuis un shell, car il faut positionner correctement les variables
d’environnement avant de les lancer.
La variable PATH du shell n’est pas positionnée. Les sondes doivent utiliser des chemins
absolus si elles souhaitent lancer des programmes. Ceci est une cause fréquente de
problèmes lors des tests. Un programme de vérification peut très bien fonctionner en ligne
de commande et beaucoup moins bien dans Nagios, tout simplement car il souhaite utiliser
la variable PATH qui n’est pas positionnée.
2.6.2 Commande de vérification :

Nagios a besoin qu’on lui fournisse les commandes responsables des vérifications des
éléments distants. Ce sont ces commandes qui déterminent l’état des éléments distants et
donnent l’information à Nagios. Elles récupèrent également les données de performances.
Pour les définir, on doit instancier l’objet command. Ces instances figurent dans le fichier
commands.cfg.
Ces objets sont simples et ne comportent que deux propriétés :

• command_name : c’est le nom de la commande tel qu’on va pouvoir l’utiliser dans le reste
de la configuration Nagios ;
• command_line : c’est la commande que doit lancer Nagios. On remarque dans l’exemple ci-
dessous une valeur un peu particulière, $HOSTADDRESS$. C’est en fait une macro qui est
positionnée lors du lancement de la commande par Nagios. Elle peut changer de valeur
suivant le contexte. Ici, elle est égale à l’adresse réseau de l’élément que l’on veut surveiller.
Exemple de commande
define command{
command_name check_tcp

command_line /usr/local/nagios/libexec/check_tcp -H
$HOSTADDRESS$ -p $ARG1$
}
Les commandes peuvent prendre des arguments, comme c’est le cas dans notre exemple
check_tcp ci-dessus. Les arguments sont de la forme $ARGn$, n pouvant aller de 1 à 32. Ils
peuvent être donnés lors de l’appel de la commande, par un hôte ou par un service. Ceci
permet, entre autres, d’avoir une seule définition de commande pour vérifier un port TCP et
de spécifier, par exemple dans le service, le numéro de port que l’on souhaite surveiller.
2.6.3 Commande de notification :

Les commandes de notification sont des commandes comme les autres. Elles utilisent des
macros relatives aux éléments supervisés, à leur état et aux contacts à prévenir. Les macros
sont étudiées un peu plus loin dans ce chapitre. Les commandes de notification figurent dans
le fichier commands.cfg aux côtés des commandes de vérifications.
Par exemple, pour envoyer un e-mail relatif à un événement sur un hôte, nous avons la
définition suivante :
Commande d’envoi d’e-mail

define command{
command_name host-notify-by-email
command_line /bin/echo "Host $HOSTNAME$ is $HOSTSTATE$" |
/bin/mail $CONTACTEMAIL$
}
2.6.4 Hôtes :
Également nommés hosts, nœuds ou ressources, ce sont les éléments que Nagios supervise.
Dans le cadre de la supervision système, c’est le serveur à surveiller ; pour la supervision
réseau, il peut s’agir d’un switch. En cas de problème, il alerte un ou plusieurs contacts. Ces
derniers seront étudiés un peu plus loin dans ce chapitre.
Cet élément est la base de la supervision dans Nagios.
États d’un nœud

Un hôte peut avoir trois états :
• UP : il est en état de répondre ;
• DOWN : il est indisponible ;
• UNREACHABLE : l’état n’est pas connu car il est situé, en termes de réseau, derrière un
élément qui est tombé.
Ces objets figurent dans le fichier hosts.cfg. L’ensemble des propriétés indispensables sont
les suivantes :

• host_name : nom de l’hôte tel qu’il sera utilisé dans le reste de la configuration ;
• alias : nom qui est affiché aux utilisateurs ;
• address : adresse réseau de l’hôte ;
• max_check_attempts : nombre de vérifications que Nagios doit tenter avant de le
déclarer réellement DOWN ;
• check_period : période de temps pendant laquelle le nœud est supervisé ;
• contacts : contacts à prévenir en cas de souci ;
• contact_groups : groupes de contacts à prévenir en cas de souci ;
• notification_interval : intervalle de temps, en minutes, entre les notifications d’erreur ;
si cette valeur est à zéro, il ne sera envoyé qu’une seule
notification ;
• notification_period : période de temps appliquée aux notifications des contacts.
Deux autres propriétés sont facultatives mais fortement conseillées :

• check_command : commande qui vérifie l’état de l’hôte. Elle est optionnelle car, dans
certains cas particuliers comme la supervision passive, elle n’est
pas nécessaire.
• notification_options : ce sont les états des hôtes qui doivent faire l’objet d’une
notification. Si l’option n’est pas spécifiée, Nagios considère que tous les états doivent être
remontés. Les états possibles sont :
– d : lorsqu’un hôte passe en état DOWN ;
– u : lorsqu’un hôte passe en état UNREACHABLE ;
– r : lorsqu’un hôte revient en état UP ;
– f : lorsqu’un hôte commence à faire le « yoyo » (flapping) ; ceci sera étudié plus en
détail dans un autre chapitre ;
– s : lorsqu’un hôte arrive dans une période de maintenance définie par un
administrateur;
– n : est utilisé si un contact ne veut recevoir aucune notification.
2.6.5 Les services :

Les services sont les points supervisés sur les hôtes. Dans le cas d’un serveur, il s’agira, par
exemple, de s’assurer du bon fonctionnement d’une application particulière, ou bien de
vérifier si la charge du serveur est acceptable. Les hôtes et les contacts à alerter sont
indispensables dans la définition des services.
Un service peut avoir plusieurs états :
• OK : tout va bien pour l’élément surveillé.
• WARNING : quelque chose commence à aller mal comme, par exemple, un
disque qui est presque rempli.
• CRITICAL : la situation est très grave et demande une intervention immédiate.
C’est le cas, par exemple, d’un disque plein.
• UNKNOWN : la commande de vérification n’a pas pu obtenir les informations
souhaitées.
Par exemple, les arguments fournis à la commande ne sont pas bons.
Tout comme les autres objets, les services possèdent des propriétés indispensables :
• service_description : nom du service ;
• host_name : nom de l’hôte sur lequel se trouve le point à surveiller ;
• check_command : commande de vérification pour obtenir l’information
souhaitée ; on peut lui fournir des arguments en les
séparant par le caractère ! ;
• max_check_attempts : nombre de tentatives au bout desquelles la situation est
considérée comme sûre ;
• check_interval : période entre deux tests en temps normal ;
• retry_interval : période entre deux tests lorsqu’il y a un souci ;
• check_period : période de temps durant laquelle le service est supervisé ;
• notification_interval : intervalle de temps entre deux notifications. Tout comme
pour les nœuds, si cette valeur est à zéro, une seule
notification est envoyée ;
• notification_period : période de temps durant laquelle les notifications sont
envoyées ;
• contacts : contacts à prévenir ;
• contact_groups : groupes de contacts à prévenir.
Une autre propriété est importante mais facultative :
• notification_options : ce sont les états qui, pour un service, doivent faire l’objet
d’une notification. Comme pour les hôtes, si ce paramètre n’est pas positionné, tous
les états sont pris en compte. Ces états sont :
–w: lorsqu’un service passe en état WARNING ;
–u: lorsqu’un service passe en état UNKNOWN ;
–c: lorsqu’un service passe en état CRITICAL ;
– r,f,s,n : mêmes options que pour les hôtes, mais appliquées aux services.
2.6.6 Les contacts :

Les contacts sont les personnes qui reçoivent les notifications d’alertes de Nagios.
Les hôtes et les services se voient accrocher des contacts. Nous avons vu qu’il ne faut prévenir
les utilisateurs que pour des incidents qui les concernent. Nagios doit savoir qui prévenir
lorsqu’un problème surgit.
Nous allons avoir un contact par utilisateur de Nagios.
Les contacts doivent avoir des périodes de notification. Certains souhaitent recevoir les
alertes uniquement sur certaines plages horaires. Ceci est tout particulièrement vrai
lorsqu’on évoque les envois de SMS. Il est inutile que ces messages partent en pleine journée.
Certains autres ne veulent recevoir que les alertes critiques et pas les simples avertissements.
Tout ceci est possible avec Nagios.
Les objets contenant les contacts sont tout simplement contact. Ils sont définis dans le fichier
contacts.cfg et possèdent les propriétés suivantes :
• contact_name : c’est le nom du contact tel qu’il sera utilisé dans le reste de la
configuration.
• host_notifications_enabled : accepte ou non les notifications concernant les hôtes.
• service_notifications_enabled : accepte ou non les notifications concernant les
services.
• host_notification_period : période de temps où les notifications d’erreurs sur les
hôtes sont acceptées.
• service_notification_period : période de temps où les notifications d’erreurs sur les
services sont acceptées.
• host_notification_options : états qui, sur les hôtes, doivent faire l’objet d’une
notification. Les valeurs possibles sont les mêmes que pour le paramètre
notification_options des hôtes. Ces états sont :
– d : lorsqu’un hôte passe en état DOWN ;
– u : lorsqu’un hôte passe en état UNREACHABLE ;
– r : lorsqu’un hôte revient en état UP ;
– f : lorsqu’un hôte commence à faire le « yoyo » (flapping) ;
– s : lorsqu’un hôte arrive dans une période de maintenance définies par un
administrateur;
– n : est utilisé si un contact ne veut recevoir aucune notification.
• service_notification_options : états qui, sur les services, doivent faire l’objet d’une
notification. Les valeurs possibles sont les mêmes que pour le paramètre
notification_options des services. Ces états sont :
– w : lorsqu’un service passe en état WARNING ;
– u : lorsqu’un service passe en état UNKNOWN ;
– c : lorsqu’un service passe en état CRITICAL ;
– r,f,s,n : mêmes options que pour les hôtes, mais appliquées aux services.
• host_notification_commands : commande de notification qui est utilisée pour avertir
d’un évènement sur un hôte.
• service_notification_commands : commande de notification qui est utilisée pour
avertir d’un évènement sur un service.
Les états des éléments seront étudiés un peu plus loin dans ce chapitre.
Un autre paramètre important, quoi que facultatif, est :
• email : l’adresse e-mail du contact.
Nous remarquons que service_notification_commands et host_notification_commands sont
au pluriel, ceci n’est pas anodin. Un contact peut être averti de plusieurs manières à la fois.
On peut l’alerter par e-mail et par SMS en même temps.
La définition, dans ce cas, est très simple : il suffit de définir les commandes séparées par des
virgules :

Définition de plusieurs commandes de notification
service_notification_commands notify-by-email,notify-by-sms
host_notification_commands host-notify-by-email,host-notify-by-sms
Avec une telle définition, à chaque envoi de courriel va correspondre un envoi de SMS. Dans
ce cadre, il n’est pas possible d’envoyer les SMS à certaines heures de la nuit seulement, sauf
si la commande qui envoie les SMS gère les horaires elle-même.
Le plus simple, dans ce genre de cas, consiste à dupliquer la définition du contact : l’une des
copies définit l’envoi d’e-mail sur une période 24x7 et l’autre gère l’envoi de SMS sur une
période en heures non ouvrées.
2.6.7 Groupe de contacts :

Il est rare qu’un administrateur soit seul à devoir recevoir une alerte. On peut créer un groupe
de contacts dans lequel sont placés plusieurs contacts devant recevoir les mêmes alertes. Il
est possible de définir ce groupe à notifier. L’information sera alors redirigée
automatiquement vers les membres du groupe.
La définition est très simple. L’objet associé est contactgroup et se trouve dans le fichier
contacts.cfg aux côtés des contacts. Il ne possède que quatre propriétés :
• contactgroup_name : nom du groupe tel qu’il sera utilisé dans le reste de la
configuration;
• alias : nom d’affichage pour ce groupe ;
• members : liste des contacts du groupe, séparés par des virgules ;
• contactgroup_members : liste des groupes de contacts faisant parti du groupe.
2.6.8 Durée et fréquence des checks :

Description :
Une période de temps est une liste de plages horaires comprises sur plusieurs jours qui sont
considérées comme valides pour les notifications et les contrôles de services. Cela consiste
en plages horaires définies pour chaque jour de la semaine qui tournent une fois la semaine
finie. Différents types d'exceptions aux heures normales de la semaine sont supportées : jours
de la semaine en particulier, jours de mois généraux à tous les mois, jours de certains mois et
dates de calendrier.
Format de la définition :
define timeperiod{
timeperiod_name timeperiod_name
alias alias
[weekday] timeranges
[exception] timeranges
exclusion [timeperiod1,timeperiod2,…,timeperiodn]

}
Exemples de définitions :
define timeperiod {
timeperiod_name nonworkhours
alias Non-Work Hours
sunday 00:00-24:00 ; Every Sunday of every week
monday 00:00-09:00,17:00-24:00 ; Every Monday of every week
tuesday 00:00-09:00,17:00-24:00 ; Every Tuesday of every week
wednesday 00:00-09:00,17:00-24:00 ; Every Wednesday of every week
thursday 00:00-09:00,17:00-24:00 ; Every Thursday of every week
friday 00:00-09:00,17:00-24:00 ; Every Friday of every week
saturday 00:00-24:00 ; Every Saturday of every week
}
define timeperiod {
timeperiod_name misc-single-days
alias Misc Single Days
1999-01-28 00:00-24:00 ; January 28th, 1999
monday 3 00:00-24:00 ; 3rd Monday of every month
day 2 00:00-24:00 ; 2nd day of every month
february 10 00:00-24:00 ; February 10th of every year
february -1 00:00-24:00 ; Last day in February of every year
friday -2 00:00-24:00 ; 2nd to last Friday of every month
thursday -1 november 00:00-24:00 ; Last Thursday in November of every year
}
define timeperiod {
timeperiod_name misc-date-ranges
alias Misc Date Ranges
2007-01-01 - 2008-02-01 00:00-24:00 ; January 1st, 2007 to February 1st, 2008
monday 3 - thursday 4 00:00-24:00 ; 3rd Monday to 4th Thursday of every month
day 1 - 15 00:00-24:00 ; 1st to 15th day of every month
day 20 - -1 00:00-24:00 ; 20th to the last day of every month
july 10 - 15 00:00-24:00 ; July 10th to July 15th of every year
april 10 - may 15 00:00-24:00 ; April 10th to May 15th of every year
tuesday 1 april - friday 2 may 00:00-24:00 ; 1st Tuesday in April to 2nd Friday in -
May of every year
}
define timeperiod {
timeperiod_name misc-skip-ranges

alias Misc Skip Ranges
2007-01-01 - 2008-02-01 / 3 00:00-24:00 ; Every 3 days from January 1st, 2007 to
-February 1st, 2008
2008-04-01 / 7 00:00-24:00 ; Every 7 days from April 1st, 2008 ( -
continuing forever)
monday 3 - thursday 4 / 2 00:00-24:00 ; Every other day from 3rd Monday to
4th -Thursday of every month
day 1 - 15 / 5 00:00-24:00 ; Every 5 days from the 1st to the 15th
day -of every month
july 10 - 15 / 2 00:00-24:00 ; Every other day from July 10th to July
15 -th of every year
tuesday 1 april - friday 2 may / 6 00:00-24:00 ; Every 6 days from the 1st Tuesday in -
April to the 2nd Friday in May of every year
}
Description des variables :

timeperiod_name
Cette variable est un nom court utilisé pour identifier la période de temps.
alias
Cette variable est utilisée pour définir un nom long ou une description identifiant la
période de temps.
[weekday]
Les variables de jours de la semaine (sunday à saturday) sont des listes séparées par
des virgules de périodes de temps valides pour un jour particulier de la semaine.
Notez qu'il y a sept jours différents pour lesquels vous pouvez définir des périodes
de temps (dimanche à lundi). Chaque période de temps est sous la forme HH :MM-
HH:MM, où les heures sont indiquées sur 24 heures. Par exemple, 00 :15-24:00
indique 12 :15am le matin pour ce jour jusqu'à 12 :00am minuit (une période de
temps total de 23 heures 45 minutes). Si vous souhaitez exclure un jour entier de la
période de temps, il suffit simplement de ne pas l'inclure dans la définition de la
période de temps.
[exception]
Vous pouvez préciser plusieurs types différents d'exceptions au planning habituel de
rotation des semaines. Les exceptions peuvent prendre différentes formes comme
un seul jour d'un mois particulier ou de tous les mois, une seule semaine d'un mois
ou des dates de calendrier. Vous pouvez aussi préciser une plage de jours/dates et
même préciser de sauter des intervalles pour obtenir un fonctionnement du type
tous les trois jours entre ces dates. Plutôt que de lister tous les formats possibles
pour les exceptions, je vais vous laisser regarder les quelques exemples de définitions
de périodes de temps ci-dessus pour voir ce qui est possible. ;-) Les jours de la

semaine et d'autres types d'exceptions ont tous des niveaux différents de
précédence, aussi est-il important de comprendre comment ils interagissent les uns
les autres. Plus d'informations sur ceci peuvent être trouvées dans la documentation
sur les périodes de temps.
exclusion
Cette variable est utilisée pour préciser les noms courts de d'autres périodes de
temps dont les plages horaires doivent être exclues de cette période de temps.
Plusieurs périodes de temps peuvent être précisées en les séparant par des virgules.
2.6.9 Relation parent/enfant :

Pour que Nagios puisse faire la distinction entre les états DOWN et UNREACHABLE des hôtes
supervisés, vous devez lui préciser la façon dont sont connectés les hôtes les uns aux autres
; en vous plaçant du point de vue du démon Nagios. Pour cela, tracer le chemin que devrait
prendre un paquet de données pour aller du démon Nagios à chaque hôte supervisé. Chaque
switch, routeur, et serveur que le paquet doit traverser est considéré comme une étape et
requiert que vous définissiez une relation parent/enfant dans Nagios.
Relation à parent unique :
Exemple de configuration :
define host {
host_name Imprimante
parents Switch
}
define host {
host_name Switch
parents Routeur
}
define host {
host_name Routeur
parents Serveur Nagios
}
Relation à plusieurs parents :

Exemple de configuration :
define host {
host_name Serveur DNS
parents Routeur 2, Routeur 3
}
define host {
host_name Serveur HTTP
parents Routeur 2, Routeur 3
}
define host {
host_name Routeur 2
parents Routeur 1
}
Exemples de réseaux :

Réseau 1 :
define host {
host_name Nagios ; <-- The local host has no parent - it is the topmost host
}
define host {
host_name Switch1
parents Nagios
}
define host {
host_name Web
parents Switch1
}
define host {
host_name FTP
parents Switch1
}
define host {
host_name Router1
parents Switch1
}
define host {
host_name Switch2
parents Router1

}
define host {
host_name Wkstn1
parents Switch2
}
define host {
host_name HPLJ2605
parents Switch2
}
define host {
host_name Router2
parents Router1
}
define host {
host_name somewebsite.com
parents Router2
}
Réseau 2 :
2.7 Les périodes de temps :

Les paramètres concernant les périodes de temps vous permettent de maîtriser le
fonctionnement logique des différents aspects de la supervision et de la notification. Par
exemple, vous pouvez restreindre :
– Quand les contrôles d'hôtes et de services planifiés peuvent être effectués
– Quand les notifications peuvent être envoyées
– Quand les escalades de notification peuvent être utilisées
– Quand les dépendances sont valides
Les priorités dans les périodes de temps :

Les définitions de périodes de temps peuvent contenir différents types de paramètres,
incluant les jours de la semaine, certains jours dans le mois, et des dates précises du
calendrier. Les différents types de paramètres ont des priorités différentes et peuvent passer
outre les autres définitions de périodes. L'ordre des priorités pour les différents types de
directives (dans l'ordre décroissant) est le suivant :
– Une date précise dans le calendrier (03/04/2016)
– Une date spécifique dans un mois quelconque (1er Janvier)
– Une date générique mensuelle (tous les 15 du mois)
– Un jour d'un mois spécifique (le 2ème Mardi de Décembre)
– Un jour spécifique mensuel (3ème Lundi de chaque mois)
– Un jour dans la semaine (le Mardi)
Comment les périodes de temps fonctionnent avec les contrôles des hôtes et des services :
Les définitions des hôtes et des services ont un paramètre optionnel check_period qui vous
permet de spécifier la période qui sera utilisée pour restreindre les moments où les contrôles
actifs des hôtes ou des services devront être effectués.
Si vous n'utilisez pas le paramètre check_period pour spécifier une période, Nagios sera
capable de planifier les contrôles actifs des hôtes et services aussi souvent qu'il en aura
besoin. Il s'agit essentiellement d'une période de surveillance de type 24x7.
Spécifier une plage horaire dans le paramètre check_period vous permet de restreindre
Nagios à planifier les contrôles actifs réguliers des hôtes ou des services. Quand Nagios va
tenter de replanifier un contrôle d'hôte ou de service, il va s'assurer que le prochain contrôle
tombe bien dans la plage horaire définie. Si ce n'est pas le cas, Nagios va ajuster l'heure du
prochain contrôle pour qu'elle coïncide avec la prochaine heure valide dans la plage horaire
spécifiée. Ce qui signifie que l'hôte ou le service ne sera contrôlé à nouveau que dans
plusieurs heures, jours, semaines, etc.
Note
Les contrôles à la demande et les contrôles passifs ne sont pas restreints par la plage horaire
spécifiée dans le paramètre check_period. Seuls des contrôles réguliers actifs sont
concernés.
Sauf si vous avez une bonne raison de ne pas le faire, je vous conseille de surveiller tous les
hôtes et les services en utilisant des plages horaires qui couvrent une période de temps 24x7.
Si vous ne le faites pas, vous pouvez rencontrer certains problèmes au cours de ces périodes
de non-contrôle (lorsque l'on ne se trouve pas dans la plage horaire définie) :
1. Le statut de l'hôte ou du service apparaîtra inchangé tout au long de la période de non-
contrôle.
2. Les contacts ne seront pas re-notifiés des problèmes avec un hôte ou un service durant
une période de non-contrôle.
3. Si un hôte ou un service redevient OK pendant une période de non-contrôle, les contacts
ne seront pas immédiatement notifiés du retour à normale.
Comment fonctionnent les périodes de temps avec les contacts de notifications

En spécifiant une période au paramètre notification_period d'une définition d'un hôte ou
d'un service, vous pouvez contrôler quand Nagios est autorisé à envoyer des notifications
concernant des problèmes ou des retours à la normale pour cet hôte ou ce service.
Lorsqu'une notification pour un hôte doit être envoyée, Nagios s'assure que l'heure actuelle
est bien comprise dans la plage horaire notification_period valide. Si c'est une heure valide,
alors Nagios essayera de notifier chaque contact du problème ou du retour à la normale.
Vous pouvez aussi utiliser les périodes pour contrôler quand seront envoyées les
notifications individuellement à chaque contact. En utilisant les paramètres
service_notification_period and host_notification_period dans la définition d'un contact,
vous serez en mesure de définir une plage horaire sur mesure pour chaque contact. Les
contacts recevront les notifications pour les hôtes et les services seulement pendant la plage
horaire que vous leur aurez spécifié.
Comment fonctionnent les périodes de temps avec les escalades de notification
Les escalades de notification des hôtes et services ont un paramètre optionnel nommé
escalation_period qui vous permet de spécifier une plage horaire où l'escalade sera valide et
pourra être utilisée.
Si vous n'utilisez pas le paramètre escalation_period dans la définition de l'escalalde,
l'escalade sera considérée comme valide tout le temps. Si vous spécifiez une plage horaire
pour le paramètre escalation_period, Nagios utilisera définition de l'escalade seulement
pendant cette plage horaire.
Comment fonctionnent les périodes de temps avec les dépendances
Les dépendances d'hôtes et de services ont un paramètre optionnel nommé

dependency_period qui vous permet de spécifier une plage horaire où la dépendance sera
valide et pourra être utilisée. Si vous n'utilisez pas le paramètre dependency_period dans la
définition de la dépendance, la dépendance pourra être utilisée n'importe quand. Si vous
spécifiez une plage horaire pour le paramètre dependency_period, Nagios utilisera la
définition de la dépendance seulement pendant cette plage horaire.
2.8 NSClient++
NSClient++ est un service pour toutes versions de Windows (NT, 2000, 2003, XP et Vista) qui
combine les fonctionnalités d’un agent de supervision dédié à l’environnement Windows
ainsi que les fonctions de transport NRPE et NSCA pour cet environnement. Il est disponible
en version 32 et 64 bits. Du fait de ces triples fonctions, le fichier de configuration de
NSClient++ est assez long mais également assez simple. Il est aujourd’hui considéré comme
l’agent de supervision standard Nagios pour plateformes Windows.
L’installation de NSClient++ ne pose pas de problème grâce au format d’installation .msi
fourni. Il suffit de valider par le bouton next chacun des écrans présentés. Le logiciel est
installé par défaut dans le répertoire C:\Program Files\NSClient++. Il contient le fichier
exécutable de service nsclient++, le répertoire modules contenant les extensions de
NSClient++ et le fichier de configuration NSC.ini. Une entrée dans le menu Démarrer est

également créée, permettant de stopper et démarrer le service. Pour voir les compteurs
disponibles sur l’hôte supervisé, il est possible d’utiliser la commande suivante dans une
fenêtre DOS.
NSClient++ CheckSystem listpdh
Il faut impérativement modifier le fichier de configuration fourni pour que NSClient++ puisse
fonctionner. Le fichier est fourni entièrement commenté. Il est constitué d’une section
générale et de sections spécifiques à chaque mode de fonctionnement de NSClient++.
[modules]
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
SysTray.dll
CheckEventLog.dll
CheckHelpers.dll
CheckWMI.dll
NSCAAgent.dll
LUAScript.dll
CheckExternalScripts.dll
NRPEClient.dll
Ce premier bloc de configuration permet d’activer et de désactiver les modules/extensions
de NSClient++. Il faut bien sûr en activer au minimum quelques-uns pour pouvoir interroger
la machine.
 FileLogger: permet de journaliser les événements NSClient++ ; il est conseillé de
l’activer,
 CheckSystem: permet les contrôles de CPU, RAM et charge,
 CheckDisk: permet les contrôles d’espace libre sur les disques durs,
 NSClientListener: permet le mode de fonctionnement nsclient,
 NRPEListener: permet le mode de fonctionnement NRPE,
 SysTray: est une extension à la barre des tâches Windows qui permet de stopper,
démarrer le service directement depuis celle-ci,
 CheckEventLog: permet l’interrogation des fichiers journaux Windows,
 CheckHelpers: ne produit aucun contrôle par lui-même mais permet de manipuler les
sorties des autres de plusieurs façons,
 CheckWMI: permet les interrogations de type WMI,
 NSCAAgent: permet le mode fonctionnement NSCA,
 LUAScript: permet d’exécuter des scripts en langage Lua (http://www.lua.org/),
 CheckExternalScripts: permet d’exécuter toutes sortes de scripts externes,
 NRPEClient: permet un mode de fonctionnement proxy NRPE.

[Settings]
obfuscated_password=Jw0KAUUdXlAAUwASDAAB
password=secret-password
allowed_hosts=127.0.0.1/32,192.168.44.0/24,10.1.2.25

use_file=1
[log]
debug=1
file=NSC.log
date_mask=%Y-%m-%d %H:%M:%S
Ces deux nouveaux blocs de configuration contiennent les directives de fonctionnement
général de NSClient++. Celles-ci sont faciles à comprendre. Deux directives pour un mot de
passe qui devra être fourni à chaque interrogation distante de la machine, l’une en clair et
l’autre masquée.
 allowed_hosts: contient la liste séparée par des virgules des hôtes ou sous-réseaux
autorisés à se connecter sur la machine.
 use_file: indique si il faut utiliser le fichier de configuration ou plutôt des règles
stockées dans le registre de Windows.
 debug: permet de préciser si NSClient++ doit journaliser un maximum d’informations.
 file: le nom et éventuellement le chemin d’accès du fichier journal.
 date_mask: est le format de date à utiliser dans ce journal.
NSClient++ en mode nsclient :

Le premier mode de fonctionnement de NSClient++ est un mode compatibilité destiné à
honorer les développements faits sur cette plateforme dans le temps. Il existait, à l’époque
où Nagios s’appellait encore NetSaint, un agent dédié Window nsclient interrogeable via le
plugin standard check_nt. Ce mode possède son bloc de configuration distinct dans le fichier
de configuration.
[NSClient]
allowed_hosts=
port=12489
bind_to_address=
socket_timeout=30
 allowed_hosts: est la même directive que celle trouvée dans la section Settings. Il est
possible de préciser de nouvelles adresses ou de laisser la directive vide pour utiliser
la liste déclarée dans la section Settings.
 port: indique le port d’écoute entrant du mode nsclient fixé par NSClient++ à 12489.
Dans la version historique de nsclient, ce port d’écoute était le 1248 par défaut.
 bind_to_address: permet de n’écouter que sur une interface réseau dans le cas où la
machine en possède plusieurs. Il faut laisser cette directive vide pour écouter sur
toutes les interfaces réseau de la machine.
 socket_timeout: est le temps maximum autorisé pour une interrogation avant de
couper la connexion.
À ce stade, le fichier de configuration est suffisamment renseigné pour fonctionner en mode
nsclient. Depuis le serveur Nagios, il faut utiliser le plugin standard check_nt pour interroger
le démon distant NSCLient++ en mode nsclient. Ce plugin possède de nombreuses options.
-H, –hostname=HOST
Nom ou adresse IP de l’hôte à interroger.
-p, –port=INTEGER

Port de connexion (défaut 1248). Du fait que c’est NSClient++ qui est le démon
distant, cette option est à préciser systématiquement avec la valeur 12489. Si
vous conservez sa valeur par défaut.
-s <password>
Mot de passe nécessaire à la connexion.
-w, –warning=INTEGER
Seuil d’avertissement.
-c, –critical=INTEGER
Seuil critique.
-v, –variable=STRING
Variable à interroger.
Les variables possibles sont les suivantes :

CLIENTVERSION
retourne la version de l’agent nsclient. Renvoie un état d’avertissement si cette
valeur diffère de celle précisée avec l’option -l <version>.
CPULOAD
charge moyenne système durant les x dernières minutes. Requiert le paramètre
l avec la syntaxe suivante
-l <intervalle minutes>,<seuil d’avertissement>,<seuil critique>.
<intervall minutes> doit être inférieur à 24*60. Les seuils sont exprimés en
pourcentage et jusqu’à dix requêtes peuvent être faites en un seul passage.
Exemple -l 60,90,95,120,90,95
UPTIME
Durée écoulée depuis le dernier démarrage de la machine.
USEDDISKSPACE
Taille totale et pourcentage de disque dur utilisé. Requiert un paramètre l
contenant la lettre du lecteur à interroger. Il est possible de passer des seuils
avec les options -w et -c.
MEMUSE
Mémoire utilisée. Il est possible de passer des seuils avec les options -w et -c.
SERVICESTATE
Vérifier l’état (démarré ou arrêté) d’un ou de plusieurs services Windows.
Requiert un paramètre l avec la syntaxe suivante
-l <service1>,<service2>,<service3>,…
Il est possible de préciser -d SHOWALL pour avoir la liste des services démarrés
dans le message retour.
PROCSTATE
Vérifier si un ou plusieurs processus sont démarrés. La syntaxe est identique à
celle de SERVICESTATE.
COUNTER
Permet d’interroger n’importe quel compteur de performance sur Windows
NT/2000. Requiert le paramètre l avec la syntaxe suivante
-l ”<objet performance>counter”,”<description>.

Le paramètre <description> est optionnel. Si le paramètre <description> ne
contient pas les signes ”%%”, il est utilisé comme label. Vu le nombre de
possibilités offertes, il est donc tout à fait envisageable de superviser un hôte
Windows de façon active uniquement avec ce mode.
/usr/local/nagios/libexec$ ./check_nt -H 192.168.10.100 -p 12489 -s giosna -v
CLIENTVERSION NSClient++ 0.3.2.9 2008-05-17
Ce même appel qui vérifie en plus que la version installée correspond bien à
celle souhaitée.
CLIENTVERSION -l "NSClient++ 0.3.2.9 2008-05-17"
NSClient++ 0.3.2.9 2008-05-17
La logique d’utilisation est toujours la même avec l’utilisation du paramètre -l qui permet de
préciser les valeurs à interroger. Voici quelques exemples permettant de contrôler les
aspects système habituels d’une machine Windows.
Contrôle de l’espace disque restant sur C

USEDDISKSPACE -l C -w 10 -c 5
C:\ - total: 9,99 Gb - used: 1,81 Gb (18%) - free 8,17 Gb (82%) | ’C:\ Used
Space’=1,81Gb;0,00;0,00;0.00;9,99
Contrôle de la mémoire utilisée

usr/local/nagios/libexec$ ./check_nt -H 192.168.10.100 -p 12489 -s giosna -v MEMUSE
-w 10 -c 5
Memory usage: total:922,18 Mb - used: 100,87 Mb (11%) - free: 821,31 Mb (89%) | ’Memory
usage’=100,87Mb;92,22;46,11;0.00;922,18
Contrôle de la durée écoulée depuis le dernier démarrage de la machine
/usr/local/nagios/libexec$ ./check_nt -H 192.168.10.100 -p 12489 -s giosna -v UPTIME
System Uptime - 0 day(s) 1 hour(s) 16 minute(s)
Contrôle de la charge machine

Avec une interrogation qui permet un mode de calcul assez proche de celui observé sur
machine Linux/Unix, soit une moyenne sur la dernière minute, les 5 et les 15 dernières
minutes. Les seuils d’avertissement (90) et critique (95) sont précisés pour chacune des
valeurs interrogées.
CPULOAD -l 1,90,95,5,90,95,15,90,95
CPU Load 0% (1 min average) 0% (5 min average) 0% (15 min average) | ’1 min avg
Load’=0%;90;95;0;100 ’5 min avg Load’=0%;90;95;0;100 ’15 min avg Load’=0%;90;95;0;100
Contrôle de l’état de services
Le nom des services interrogés apparaît dans le message retour parce que l’option -d
SHOWALL est précisée.
SERVICESTATE -d SHOWALL -l W32Time,"Services IPSec",NSClientpp
W32Time: Started - Services IPSec: Started - NSClientpp: Started

Le même contrôle sans l’option -d SHOWALL donne :
SERVICESTATE -l W32Time,"Services IPSec",NSClientpp
OK: All services are running.
Pour contrôler des processus, la syntaxe est la même que SERVICESTATE vu précédemment
y compris pour l’utilisation de -d SHOWALL. Le plugin ne permet pas de connaître le nombre
d’occurrence du même processus. Il contrôle qu’au moins un est présent en mémoire.
PROCSTATE -d SHOWALL -l svchost.exe,nsclient++.exe
svchost.exe: Running - nsclient++.exe: Running
Pour transformer ces appels en commandes et services Nagios, il est soit possible de définir
une commande Nagios générique au check_nt, soit de spécialiser la commande en fonction
du contrôle qui est à effectuer pour avoir moins de paramètres à préciser dans le service
correspondant.
define command{
command_name check_nt
command_line $USER1$/check_nt -H $HOSTADDRESS$ -s giosna -p 12489 -v $ARG1$
$ARG2$
}
Cette commande est générique puisqu’elle permet d’appeler tout type de contrôle check_nt
avec l’inconvénient de devoir préciser l’argument -l et -d SHOWALL au niveau du service
comme ceci.
define service{
use generic-service
host_name winserver
service_description CPU Load
check_command check_nt!CPULOAD!-l 1,90,95,5,90,95,15,90,95
}
En spécialisant la commande comme ceci,
define command{
command_name check_nt_load
command_line $USER1$/check_nt -H $HOSTADDRESS$ -s giosna -p 12489 -v CPULOAD
-l 1,$ARG1$,5,$ARG1$,15,$ARG1$
}
Alors la définition de service devient plus évidente.
define service{
use generic-service
host_name winserver
service_description CPU Load
check_command check_nt_load!90,95
}

À chacun de voir suivant ses besoins et ses goûts le mode de configuration pour Nagios le
plus approprié, mais la spécialisation des commandes permet vraiment de pouvoir avoir des
services plus lisibles.
NSClient++ en mode NRPE

Après le mode de compatibilité que nous venons de voir, nous allons voir comment
NSClient++ peut jouer le rôle d’un agent NRPE; à savoir un moyen de transport pour des
contrôle effectués localement. Par rapport au mode de fonctionnement précédent, ce mode
a l’avantage de pouvoir utiliser tous scripts Visual Basic, Perl ou DOS présents sur la machine
et de ne pas se cantonner aux interrogations prévues par un agent spécialisé. Ce mode
permet en plus d’encrypter les données pendant le transport, ce qui n’est pas le cas du
premier mode vu. La particularité du mode NRPE de NSClient++ par rapport au démon
équivalent Linux/Unix, c’est qu’il n’y a pas obligatoirement besoin de scripts externes
puisqu’il est possible par ce moyen d’interroger les différents modules de NSClient++. Cette
double possibilité se retrouve au niveau des blocs de configuration de NRPE pour NSClient++.
La section NRPE contient les directives habituelles de réglages de démon comme la liste des
hôtes autorisés à se connecter ou la possibilité de soumettre des arguments aux
commandes. Ces directives sont les mêmes que celles du démon sur plateforme Linux/Unix,
nous n’y revenons donc pas.
[NRPE]
port=5666
command_timeout=60
allow_arguments=0
allow_nasty_meta_chars=0
use_ssl=1
bind_to_address=
allowed_hosts=
socket_timeout=30
Plus intéressante est la section Check System. Elle permet de fixer la taille du tampon utilisé
pour le contrôle de la CPU et la fréquence de celui-ci avec les directives CPUBufferSize et
CheckResolution. Il est conseillé d’utiliser un tampon bien dimensionné par rapport aux
valeurs souhaitées. Ainsi, pour nos exemples, nous avons utilisé les compteurs 1,5 et 15
minutes. Une valeur de 20m est donc largement suffisante. La résolution est exprimée en
dixième de sonde, une valeur de 10 prélève donc une valeur toutes les secondes. Les cinq
lignes suivantes servent à régler le comportement du contrôle de service quand l’option
ShowAll est précisée. C’est le cas de la commande alias_service qui est décrite dans la section
External Alias du fichier de configuration.
[Check System]
CPUBufferSize=20m
CheckResolution=10
check_all_services[SERVICE_BOOT_START]=ignored
check_all_services[SERVICE_SYSTEM_START]=ignored
check_all_services[SERVICE_AUTO_START]=started

check_all_services[SERVICE_DEMAND_START]=ignored
check_all_services[SERVICE_DISABLED]=stopped
Le bloc External Script règle le comportement de NSClient++ quand il s’agit d’exécuter des
scripts extérieurs à celui-ci.Il faut que le module CheckExternalScripts soit activé en début de
fichier de configuration pour que ce bloc et le bloc External Alias soient fonctionnels. Les
options sont les mêmes que le bloc NRPE.
[External Script]
command_timeout=60
allow_arguments=0
allow_nasty_meta_chars=0
script_dir=c:\my\script\dir
Le bloc External Scripts permet de spécifier le couple nom de commande NRPE et script à
exécuter.
[External Scripts]
check_es_ok=scripts\ok.bat
check_vbs_sample=cscript.exe //T:30 //NoLogo scripts\check_vb.vbs
Le bloc External Alias permet de définir des commandes accessibles via les modules
internes de NSClient++ sous forme nom de commande NRPE et injection Nclient++.
[External Alias]
alias_cpu=checkCPU warn=90 crit=95 time=1m time=5m time=15m
alias_disk=CheckDriveSize MinWarn=10% MinCrit=5% CheckAll
FilterType=FIXED
alias_service=checkServiceState CheckAll
alias_mem=checkMem MaxWarn=80% MaxCrit=90% ShowAll type=physical
Le bloc includes permet comme son nom l’indique d’inclure des fichiers de configuration
secondaires à celui-ci. Ces directives sont intéressantes quand il existe beaucoup de
définitions de commandes NRPE. Elles sont alors déportées dans l’un de ces fichiers de
configuration secondaires afin d’alléger la lecture du fichier principal.
[includes]
myotherfile.ini
real.ini
Le bloc NRPE Handlers est une reprise des blocs External Scripts et External Alias mais au
format traditionnel NRPE. L’écriture peut être faite dans le format tel que connu sur
Linux/Unix ou sous forme simplifiée propre à NSClient++. Les deux premières définitions sont
ainsi identiques.

[NRPE Handlers]
command[check_cpu]=inject checkCPU warn=90 crit=95 time=1m time=5m
time=15m
check_cpu=inject checkCPU warn=90 crit=95 time=1m time=5m time=15m
check_disk=inject CheckDriveSize MinWarn=10% MinCrit=5% CheckAll
FilterType=FIXED
check_service=inject checkServiceState CheckAll
check_mem=inject checkMem MaxWarn=80% MaxCrit=90% ShowAll
type=physical
check_ok=scripts\ok.bat
check_vbs=cscript.exe //T:30 //NoLogo scripts\check_vb.vbs
Il est évident en voyant ce foisonnement de possibilités que certaines d’entre elles se

recoupent. Cela est dû à la nature particulière de NSClient++ qui essaie à la fois de reprendre
les protocoles « standards » de Nagios comme NRPE tout en développant de nouvelles
directions propres aux systèmes Windows. De ce fait, la section NRPE Handlers reprend les
mêmes contrôles que ceux exprimés dans les sections External Scripts et External Alias. Il est
souvent judicieux de choisir parmi ces méthodes plutôt que de toutes les utiliser pour
clarifier l’organisation des commandes de contrôle. Nous allons maintenant reprendre les
principaux contrôles vus avec le mode nsclient mais cette fois-ci en mode NRPE. Les
définitions à déclarer dans le fichier de configuration de NSClient++ sont données plus haut
dans les blocs correspondant de l’explication du fichier de configuration.
Contrôle de la charge système

/usr/local/nagios/libexec$ ./check_nrpe -H 192.168.10.100 -c alias_cpu
OK CPU Load ok.|’1m’=3;90;95; ’5m’=0;90;95; ’15m’=0;90;95;
Contrôle de l’espace libre sur le disque dur
/usr/local/nagios/libexec$ ./check_nrpe -H 192.168.44.200 -c alias_disk
OK: All drives within bounds.|’C:\’=82%;10;5;
Contrôle de la mémoire
/usr/local/nagios/libexec$ ./check_nrpe -H 192.168.44.200 -c alias_mem
OK: physical memory: 141M|’physical memory’=36%;80;90;
Contrôle de l’état des services
/usr/local/nagios/libexec$ ./check_nrpe -H 192.168.44.200 -c alias_service
OK: All services are running.
Côté serveur Nagios, la configuration de la commande Nagios étant déjà faite, il ne reste qu’à
créer des services sur le modèle d’un service check_nrpe.
NSClient++ en mode NSCA

Le troisième mode à voir avec NSClient++ est le dernier introduit dans le logiciel. Il permet
d’interroger localement la machine et de soumettre ses résultats à intervalles réguliers à
Nagios via le protocole NSCA. Il en implémente la partie send_nsca. C’est donc tout
naturellement que le fichier de configuration de NSClient++ contient un bloc spécifique à ce
mode de fonctionnement. Le bloc NSCA Agent fixe le comportement de NSClient++ en mode
NSCA. La directive de configuration avec une valeur à 300 signifie que les résultats sont
envoyés toutes les 300 secondes, soit 5 minutes au serveur Nagios. La directive hostname

permet de préciser un nom de machine plutôt que celui récupéré par la variable
d’environnement Windows %COMPUTERNAME%. Les autres directives ont déjà été vues lors
de la présentation de NSCA et send_nsca.
[NSCA Agent]
interval=300
encryption_method=14
password=
bind_to_address=
hostname=
nsca_host=192.168.0.1
nsca_port=5667
Le deuxième bloc de configuration concerne les déclarations de contrôle à faire dans ce

mode. À chaque fois, il faut préciser le nom du service qui est à impacter dans Nagios et la
commande NSClient++ à exécuter pour le contrôle.
[NSCA Commands]
my_cpu_check=checkCPU warn=80 crit=90 time=20m time=10s time=4
my_mem_check=checkMem MaxWarn=80% MaxCrit=90% ShowAll type=page
my_svc_check=checkServiceState CheckAll exclude=wampmysqld
exclude=MpfService
host_check=check_ok
Le principal intérêt de ce mode est bien évidemment la réduction de la bande passante

réseau consommée qu’il occasionne. Si les contrôles fournis en standard par NSClient++ ne
suffisent plus, il est possible d’écrire ses propres contrôles soit par des commandes
appropriées pour dialoguer avec les modules de NSClient++ soit d’écrire ses propres scripts
dans un langage supporté par la plateforme. Microsoft fournit gratuitement un outil précieux
pour la réalisation de ces objectifs avec Scriptomatic
(http://www.microsoft.com/technet/scriptcenter/tools/scripto2.mspx), qui permet de
générer automatiquement des scripts d’interrogation WMI. WMI fournit normalement tous
les compteurs possibles et imaginables pour la supervision, c’est donc un mode de collecte
à privilégier.

3 Nagios : Configuration
3.1 Installation :
Configuration requise :
apt-get update
apt-get upgrade
//Installation des prérequis :

apt-get install build-essential libgd2-xpm-dev openssl libssl-dev xinetd apache2-utils
apache2 unzip php5
//Ajout de l’utilisateur et du groupe nagios et affectation des droits :

useradd nagios
mkdir /home/nagios
chown nagios:nagios /home/nagios
groupadd nagcmd
usermod -a -G nagcmd nagios
Installation Nagios :
//Récupération des sources et compilation:
cd /opt/
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.1.1.tar.gz
tar xzvf nagios-4.1.1.tar.gz
cd nagios-4.1.1
./configure --with-nagios-group=nagios --with-command-group=nagcmd --with-httpd-
conf=/etc/apache2/conf-available
make all
make install
make install-commandmode
make install-init
make install-config
/usr/bin/install -c -m 644 sample-config/httpd.conf /etc/apache2/sites-
available/nagios.conf
usermod -G nagcmd www-data
ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios
//Nagios est installé dans /usr/local/nagios/
//Installation des plugins

cd ..
wget http://nagios-plugins.org/download/nagios-plugins-2.0.3.tar.gz
tar xvf nagios-plugins-2.0.3.tar.gz
cd nagios-plugins-2.0.3
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
make install
//Configuration Apache2
//Il faut activer le module rewrite et cgi d’apache2
a2enmod rewrite
a2enmod cgi
//On crée un fichier password pour l’accès à Nagios

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
----- Entrer le mot de passe --------
//On active le site Nagios

a2ensite nagios
//On lance les deux services, s’ils ne le sont pas.

service nagios start
service apache2 reload
Nagios est accessible sur http://Votre.Adresse.I.P/nagios
3.2 Les fichiers de configuration :
3.2.1 Configuration de Nagios: nagios.cfg

Ce fichier défini comment Nagios doit fonctionner. Il dispose de nombreuses options. Je vous
conseille donc de partir du fichier fourni en standard et de modifier les sections suivantes.
Modifier le fichier ou les logs du processus Nagios seront écrits (vous pouvez laisser la valeur
par défaut).
log_file=/var/log/nagios.log
Attention, ce fichier doit être en lecture/écriture l'utilisateur avec lequel le daemon Nagios
est lancé (user nagios par défaut).
La deuxième chose à faire est de définir l'arborescence des fichiers de configuration. Dans
notre cas, cela donne:

cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/hostclients.cfg
cfg_file=/usr/local/nagios/etc/objects/hostservers.cfg
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/network.cfg
Les options suivantes permettent de configurer l'utilisateur et le groupe système utilisés
pour lancer Nagios. Je vous conseille de laisser les valeurs par défaut (sinon il faut créer les
utilisateurs).
nagios_user=nagios
nagios_group=nagios
3.2.2 Configuration des CGI: cgi.cfg

Comme vous le savez, Nagios se base sur une interface Web pour générer ses rapports. Cette
interface Web est générée dynamiquement par des scripts CGI. Le fichier cgi.cfg à pour but
de configurer ces CGI selon votre configuration. Là encore, je vous conseille de partir du
fichier fourni par défaut.
On commence par définir l'emplacement du fichier nagios.cfg. En effet ce dernier doit être
lisible par les CGI.
main_config_file=/usr/local/nagios/etc/nagios.cfg
On peut ensuite configurer l'URL avec laquelle on va accéder au serveur Web de Nagios. Si
par exempel vous voulez y accéder par l'adresse http://monboserveurnagios.com/nagios, il
faut éditer l'option: url_html_path=/nagios
Enfin, il est fortement conseiller d'utiliser une authentification (même si c'est une basique
authentification HTTP) pour accéder à Nagios:
use_authentication=1
authorized_for_system_information=admin
3.2.3 Ressources :
Configuration des ressources externes: resource.cfg
Nagios utilise un système de plugins. Le fichier resources.cfg est là pour définir où sont ces
plugins.
Le fichier fourni en standard défini un moyen pour accéder aux plugins standards:
$USER1$=/usr/local/nagios/libexec
Libre à vous d'ajouter d'autres répertoires de plugins.

3.2.4 Commandes :
check_disk
This plugin checks the amount of used disk space on a mounted file system and generates an
alert if free space is less than one of the threshold values
Usage:
check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x device} [-C] [-E] [-e] [-f] [-g group]
[-k] [-l] [-M] [-m] [-R path ] [-r path ] [-t timeout] [-u unit] [-v] [-X type] [-N type] [-n]
Options:
-h, --help
Print detailed help screen
-V, --version
Print version information
--extra-opts=[section][@file]
Read options from an ini file. See https://www.nagios-plugins.org/doc/extra-opts.html
for usage and examples.
-w, --warning=INTEGER
Exit with WARNING status if less than INTEGER units of disk are free
-w, --warning=PERCENT%
Exit with WARNING status if less than PERCENT of disk space is free
-c, --critical=INTEGER
Exit with CRITICAL status if less than INTEGER units of disk are free
-c, --critical=PERCENT%
Exit with CRITICAL status if less than PERCENT of disk space is free
-W, --iwarning=PERCENT%
Exit with WARNING status if less than PERCENT of inode space is free
-K, --icritical=PERCENT%
Exit with CRITICAL status if less than PERCENT of inode space is free
-p, --path=PATH, --partition=PARTITION
Mount point or block device as emitted by the mount(8) command (may be repeated)
-x, --exclude_device=PATH <STRING>
Ignore device (only works if -p unspecified)
-C, --clear
Clear thresholds
-E, --exact-match
For paths or partitions specified with -p, only check for exact paths
-e, --errors-only
Display only devices/mountpoints with errors
-f, --freespace-ignore-reserved
Don't account root-reserved blocks into freespace in perfdata
-g, --group=NAME
Group paths. Thresholds apply to (free-) space of all partitions together
-k, --kilobytes
Same as '--units kB'
-l, --local
Only check local filesystems
-L, --stat-remote-fs
Only check local filesystems against thresholds. Yet call stat on remote filesystems
to test if they are accessible (e.g. to detect Stale NFS Handles)
-M, --mountpoint
Display the mountpoint instead of the partition
-m, --megabytes
Same as '--units MB'
-A, --all
Explicitly select all paths. This is equivalent to -R '.*'
-R, --eregi-path=PATH, --eregi-partition=PARTITION
Case insensitive regular expression for path/partition (may be repeated)
-r, --ereg-path=PATH, --ereg-partition=PARTITION
Regular expression for path or partition (may be repeated)
-I, --ignore-eregi-path=PATH, --ignore-eregi-partition=PARTITION
Regular expression to ignore selected path/partition (case insensitive) (may be repeated)

-i, --ignore-ereg-path=PATH, --ignore-ereg-partition=PARTITION
Regular expression to ignore selected path or partition (may be repeated)
-t, --timeout=INTEGER
Seconds before plugin times out (default: 10)
-u, --units=STRING
Choose bytes, kB, MB, GB, TB (default: MB)
-v, --verbose
Show details for command-line debugging (Nagios may truncate output)
-X, --exclude-type=TYPE
Ignore all filesystems of indicated type (may be repeated)
-N, --include-type=TYPE
Check only filesystems of indicated type (may be repeated)
-n, --newlines
Multi-line output of each disk's status information on a new line
Examples:
check_disk -w 10% -c 5% -p /tmp -p /var -C -w 100000 -c 50000 -p Checks /tmp and /var at
10% and 5%, and / at 100MB and 50MB
check_disk -w 100 -c 50 -C -w 1000 -c 500 -g sidDATA -r '^/oracle/SID/data.*$'
Checks all filesystems not matching -r at 100M and 50M. The fs matching the -r regex
are grouped which means the freespace thresholds are applied to all disks together
check_disk -w 100 -c 50 -C -w 1000 -c 500 -p /foo -C -w 5% -c 3% -p /bar
Checks /foo for 1000M/500M and /bar for 5/3%. All remaining volumes use
100M/50M

check_disk_smb
Usage: check_disk_smb -H <host> -s <share> -u <user> -p <password> -w <warn> -c <crit> [-

W <workgroup>] [-P <port>] [-a <IP>]
-H, --hostname=HOST
NetBIOS name of the server
-s, --share=STRING
Share name to be tested
-W, --workgroup=STRING
Workgroup or Domain used (Defaults to "WORKGROUP")
-a, --address=IP
IP-address of HOST (only necessary if HOST is in another network)
-u, --user=STRING
Username to log in to server. (Defaults to "guest")
-p, --password=STRING
Password to log in to server. (Defaults to an empty password)
-w, --warning=INTEGER or INTEGER[kMG]
Percent of used space at which a warning will be generated (Default: 85%)
-c, --critical=INTEGER or INTEGER[kMG]
Percent of used space at which a critical will be generated (Defaults: 95%)
-P, --port=INTEGER
Port to be used to connect to. Some Windows boxes use 139, others 445 (Defaults to
smbclient default)
If thresholds are followed by either a k, M, or G then check to see if that much disk space is
available (kilobytes, Megabytes, Gigabytes)
Warning percentage should be less than critical

Warning (remaining) disk space should be greater than critical.
check_dns
This plugin uses the nslookup program to obtain the IP address for the given host/domain
query.
An optional DNS server to use may be specified.
If no DNS server is specified, the default server(s) specified in /etc/resolv.conf will be used.
Usage:
check_dns -H host [-s server] [-q type ] [-a expected-address] [-A] [-n] [-t timeout] [-
w warn] [-c crit]
Options:

-h, --help
-V, --version
-H, --hostname=HOST
The name or address you want to query
-s, --server=HOST
Optional DNS server you want to use for the lookup
-q, --querytype=TYPE
Optional DNS record query type where TYPE =(A, AAAA, SRV, TXT, MX, ANY)
The default query type is 'A' (IPv4 host entry)
-a, --expected-address=IP-ADDRESS|HOST
Optional IP-ADDRESS you expect the DNS server to return. HOST must end with a
dot(.). This option can be repeated multiple times (Returns OK if any value match). If
multiple addresses are returned at once, you have to match the whole string of
addresses separated with commas (sorted alphabetically).
If you would like to test for the presence of a cname, combine with -n param.
-A, --expect-authority
Optionally expect the DNS server to be authoritative for the lookup
-n, --accept-cname
Optionally accept cname responses as a valid result to a query. The default is to ignore
cname responses as part of the result
-w, --warning=seconds
Return warning if elapsed time exceeds value. Default off
-c, --critical=seconds
Return critical if elapsed time exceeds value. Default off
Seconds before connection times out (default: 10)
check_ftp
This plugin tests FTP connections with the specified host (or unix socket).
Usage:
check_ftp -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>]
[-e <expect string>] [-q <quit string>][-m <maximum bytes>] [-d <delay>]
[-t <timeout seconds>] [-r <refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j]
[-D <warn days cert expire>[,<crit days cert expire>]] [-S <use SSL>] [-E]
Options:

-h, --help
-V, --version
-H, --hostname=ADDRESS
Host name, IP Address, or unix socket (must be an absolute path)
-p, --port=INTEGER
Port number (default: none)
-4, --use-ipv4
Use IPv4 connection
-6, --use-ipv6
Use IPv6 connection
-E, --escape
Can use \n, \r, \t or \ in send or quit string. Must come before send or quit option
Default: nothing added to send, \r\n added to end of quit
-s, --send=STRING
String to send to the server
-e, --expect=STRING
String to expect in server response (may be repeated)
-A, --all
All expect strings need to occur in server response. Default is any
-q, --quit=STRING
String to send server to initiate a clean close of the connection
-r, --refuse=ok|warn|crit
Accept TCP refusals with states ok, warn, crit (default: crit)
-M, --mismatch=ok|warn|crit
Accept expected string mismatches with states ok, warn, crit (default: warn)
-j, --jail
Hide output from TCP socket
-m, --maxbytes=INTEGER
Close connection once more than this number of bytes are received
-d, --delay=INTEGER
Seconds to wait between sending string and polling for response
-D, --certificate=INTEGER[,INTEGER]
Minimum number of days a certificate has to be valid.
1st is #days for warning, 2nd is critical (if not specified - 0).
-S, --ssl
Use SSL for the connection.
-w, --warning=DOUBLE
Response time to result in warning status (seconds)
-c, --critical=DOUBLE
Response time to result in critical status (seconds)

-v, --verbose
check_http
This plugin tests the HTTP service on the specified host. It can test normal (http) and secure
(https) servers, follow redirects, search for strings and regular expressions, check connection
times, and report on certificate expiration times.
Usage:
check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>] [-J <client certificate file>] [-
K <private key>] [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-E] [-a auth] [-
b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>] [-e <expect>] [-
d string] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>] [-P string] [-
m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>] [-A string] [-k string] [-
S <version>] [--sni] [-C <warn_age>[,<crit_age>]] [-T <content-type>] [-j method]
NOTE: One or both of -H and -I must be specified
Options:
-h, --help
-V, --version
Read options from an ini file. See
https://www.nagios-plugins.org/doc/extra-opts.html
Host name argument for servers using host headers (virtual host)
Append a port to include it in the header (eg: example.com:5000)
-I, --IP-address=ADDRESS
IP address or name (use numeric address if possible to bypass DNS lookup).
-p, --port=INTEGER
Port number (default: 80)
-4, --use-ipv4
Use IPv4 connection
-6, --use-ipv6
Use IPv6 connection
-S, --ssl=VERSION
Connect via SSL. Port defaults to 443. VERSION is optional, and prevents auto-
negotiation (1 = TLSv1, 2 = SSLv2, 3 = SSLv3).
--sni
Enable SSL/TLS hostname extension support (SNI)
-C, --certificate=INTEGER[,INTEGER]

Minimum number of days a certificate has to be valid. Port defaults to 443
(when this option is used the URL is not checked.)
-J, --client-cert=FILE
Name of file that contains the client certificate (PEM format) to be used in establishing
the SSL session
-K, --private-key=FILE
Name of file containing the private key (PEM format) matching the client certificate
-e, --expect=STRING
Comma-delimited list of strings, at least one of them is expected in the first (status)
line of the server response (default: HTTP/1.)
If specified skips all other status line logic (ex: 3xx, 4xx, 5xx processing)
-d, --header-string=STRING
String to expect in the response headers
-s, --string=STRING
String to expect in the content
-u, --url=PATH
URL to GET or POST (default: /)
-P, --post=STRING
URL encoded http POST data
-j, --method=STRING (for example: HEAD, OPTIONS, TRACE, PUT, DELETE)
Set HTTP method.
-N, --no-body
Don't wait for document body: stop reading after headers.
(Note that this still does an HTTP GET or POST, not a HEAD.)
-M, --max-age=SECONDS
Warn if document is more than SECONDS old. the number can also be of the form
"10m" for minutes, "10h" for hours, or "10d" for days.
-T, --content-type=STRING
specify Content-Type header media type when POSTing
-l, --linespan
Allow regex to span newlines (must precede -r or -R)
-r, --regex, --ereg=STRING
Search page for regex STRING
-R, --eregi=STRING
Search page for case-insensitive regex STRING
--invert-regex
Return CRITICAL if found, OK if not
-a, --authorization=AUTH_PAIR
Username:password on sites with basic authentication
-b, --proxy-authorization=AUTH_PAIR
Username:password on proxy-servers with basic authentication
-A, --useragent=STRING
String to be sent in http header as "User Agent"
-k, --header=STRING
Any other tags to be sent in http header. Use multiple times for additional headers

-E, --extended-perfdata
Print additional performance data
-L, --link
Wrap output in HTML link (obsoleted by urlize)
-f, --onredirect=<ok|warning|critical|follow|sticky|stickyport>
How to handle redirected pages. sticky is like follow but stick to the specified IP
address. stickyport also ensures port stays the same.
-m, --pagesize=INTEGER<:INTEGER>
Minimum page size required (bytes) : Maximum page size required (bytes)
-v, --verbose
Notes:
This plugin will attempt to open an HTTP connection with the host.
Successful connects return STATE_OK, refusals and timeouts return STATE_CRITICAL other
errors return STATE_UNKNOWN. Successful connects, but incorrect reponse messages
from the host result in STATE_WARNING return values. If you are checking a virtual server
that uses 'host headers' you must supply the FQDN (fully qualified domain name) as the
[host_name] argument.
This plugin can also check whether an SSL enabled web server is able to serve content
(optionally within a specified time) or whether the X509 certificate is still valid for the
specified number of days.
Please note that this plugin does not check if the presented server certificate matches the
hostname of the server, or if the certificate has a valid chain of trust to one of the locally
installed CAs.
Examples:
CHECK CONTENT: check_http -w 5 -c 10 --ssl -H www.verisign.com
When the 'www.verisign.com' server returns its content within 5 seconds, a STATE_OK will
be returned. When the server returns its content but exceeds the 5-second threshold, a
STATE_WARNING will be returned. When an error occurs, a STATE_CRITICAL will be
returned.
CHECK CERTIFICATE: check_http -H www.verisign.com -C 14

When the certificate of 'www.verisign.com' is valid for more than 14 days, a STATE_OK is
returned. When the certificate is still valid, but for less than 14 days, a STATE_WARNING
is returned. A STATE_CRITICAL will be returned when the certificate is expired.
CHECK CERTIFICATE: check_http -H www.verisign.com -C 30,14
When the certificate of 'www.verisign.com' is valid for more than 30 days, a STATE_OK is
returned. When the certificate is still valid, but for less than 30 days, but more than 14
days, a STATE_WARNING is returned.
A STATE_CRITICAL will be returned when certificate expires in less than 14 days
check_load
This plugin tests the current system load average.
Usage:
check_load [-r] -w WLOAD1,WLOAD5,WLOAD15 -c CLOAD1,CLOAD5,CLOAD15
Options:
-h, --help
-V, --version
-w, --warning=WLOAD1,WLOAD5,WLOAD15
Exit with WARNING status if load average exceeds WLOADn
-c, --critical=CLOAD1,CLOAD5,CLOAD15
Exit with CRITICAL status if load average exceed CLOADn the load average format is the
same used by "uptime" and "w"
-r, --percpu
Divide the load averages by the number of CPUs (when possible)
check_nagios
This plugin checks the status of the Nagios process on the local machine
The plugin will check to make sure the Nagios status log is no older than the number of
minutes specified by the expires option.
It also checks the process table for a process matching the command argument.
Usage:
check_nagios -F <status log file> -t <timeout_seconds> -e <expire_minutes> -
C<process_string>
Options:
-h, --help

-V, --version
-F, --filename=FILE
Name of the log file to check
-e, --expires=INTEGER
Minutes aging after which logfile is considered stale
-C, --command=STRING
Substring to search for in process arguments
Timeout for the plugin in seconds
-v, --verbose
Examples:
check_nagios -t 20 -e 5 -F /usr/local/nagios/var/status.log -C /usr/local/nagios/bin/nagios
check_nt
This plugin collects data from the NSClient service running on a Windows NT/2000/XP/2003
server.
Usage:
check_nt -H host -v variable [-p port] [-w warning] [-c critical] [-l params] [-d SHOWALL] [-
u] [-t timeout]
Options:
-h, --help
-V, --version
Options:
-H, --hostname=HOST
Name of the host to check
-p, --port=INTEGER
Optional port number (default: 1248)
-s, --secret=<password>
Password needed for the request
Threshold which will result in a warning status

Threshold which will result in a critical status
Seconds before connection attempt times out (default: -l, --params=<parameters>
Parameters passed to specified check (see below) -d, --display={SHOWALL}
Display options (currently only SHOWALL works) -u, --unknown-timeout
Return UNKNOWN on timeouts10)
-h, --help
Print this help screen
-V, --version
-v, --variable=STRING
Variable to check
Valid variables are :
CLIENTVERSION = Get the NSClient version

If -l <version> is specified, will return warning if versions differ.
CPULOAD = Average CPU load on last x minutes.
Request a -l parameter with the following syntax:
-l <minutes range>,<warning threshold>,<critical threshold>.
<minute range> should be less than 24*60.
Thresholds are percentage and up to 10 requests can be done in one shot.
ie: -l 60,90,95,120,90,95
UPTIME = Get the uptime of the machine.
-l <unit>
<unit> = seconds, minutes, hours, or days. (default: minutes)
Thresholds will use the unit specified above.
USEDDISKSPACE = Size and percentage of disk use.
Request a -l parameter containing the drive letter only.
Warning and critical thresholds can be specified with -w and -c.
MEMUSE = Memory use.
Warning and critical thresholds can be specified with -w and -c.
SERVICESTATE = Check the state of one or several services.
Request a -l parameters with the following syntax:
-l <service1>,<service2>,<service3>,...
You can specify -d SHOWALL in case you want to see working services in the returned
string.
PROCSTATE = Check if one or several process are running.
Same syntax as SERVICESTATE.
COUNTER = Check any performance counter of Windows NT/2000.
Request a -l parameters with the following syntax:
-l "\\<performance object>\\counter","<description>
The <description> parameter is optional and is given to a printf output command which
requires a float parameter.
If <description> does not include "%%", it is used as a label.

Some examples:
"Paging file usage is %%.2f %%%%"
"%%.f %%%% paging file used."
INSTANCES = Check any performance counter object of Windows NT/2000.

Syntax: check_nt -H <hostname> -p <port> -v INSTANCES -l <counter object>
<counter object> is a Windows Perfmon Counter object (eg. Process), if it is two words,
it should be enclosed in quotes
The returned results will be a comma-separated list of instances on the selected
computer for that object.
The purpose of this is to be run from command line to determine what instances are
available for monitoring without having to log onto the Windows server to run
Perfmon directly.
It can also be used in scripts that automatically create Nagios service configuration
files.
Some examples:
check_nt -H 192.168.1.1 -p 1248 -v INSTANCES -l Process
Notes:
- The NSClient service should be running on the server to get any information
(http://nsclient.ready2run.nl).
- Critical thresholds should be lower than warning thresholds
- Default port 1248 is sometimes in use by other services. The error output when this
happens contains "Cannot map xxxxx to protocol number".
One fix for this is to change the port to something else on check_nt and on the client service
it's connecting to.
check_ping
Use ping to check connection statistics for a remote host.
Usage:
check_ping -H <host_address> -w <wrta>,<wpl>% -c <crta>,<cpl>% [-p packets] [-
t timeout] [-4|-6]
Options:
-h, --help
-V, --version
-4, --use-ipv4
Use IPv4 connection

-6, --use-ipv6
Use IPv6 connection
-H, --hostname=HOST
host to ping
-w, --warning=THRESHOLD
warning threshold pair
-c, --critical=THRESHOLD
critical threshold pair
-p, --packets=INTEGER
number of ICMP ECHO packets to send (Default: 5)
-L, --link
show HTML in the plugin output (obsoleted by urlize)
THRESHOLD is <rta>,<pl>% where <rta> is the round trip average travel time (ms) which
triggers a WARNING or CRITICAL state, and <pl> is the percentage of packet loss to trigger
an alarm state.
This plugin uses the ping command to probe the specified host for packet loss
(percentage) and round trip average (milliseconds). It can produce HTML output linking to
a traceroute CGI contributed by Ian Cass. The CGI can be found in the contrib area of the
downloads section at http://www.nagios.org/
check_procs
Checks all processes and generates WARNING or CRITICAL states if the specified metric is
outside the required threshold ranges. The metric defaults to number of processes. Search
filters can be applied to limit the processes to check.
Usage:
check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid] [-u user] [-r rss] [-z vsz]
[-P %cpu] [-a argument-array] [-C command] [-k] [-t timeout] [-v]
Options:
-h, --help
-V, --version
-w, --warning=RANGE
Generate warning state if metric is outside this range
-c, --critical=RANGE

Generate critical state if metric is outside this range
-m, --metric=TYPE
Check thresholds against metric. Valid types:
PROCS - number of processes (default)
VSZ - virtual memory size
RSS - resident set memory size
CPU - percentage CPU
ELAPSED - time elapsed in seconds
Seconds before plugin times out (default: 10)
-v, --verbose
Extra information. Up to 3 verbosity levels
-T, --traditional
Filter own process the traditional way by PID instead of /proc/pid/exe
Filters:
-s, --state=STATUSFLAGS
Only scan for processes that have, in the output of `ps`, one or more of the status flags
you specify (for example R, Z, S, RS, RSZDT, plus others based on the output of your 'ps'
command).
-p, --ppid=PPID
Only scan for children of the parent process ID indicated.
-z, --vsz=VSZ
Only scan for processes with VSZ higher than indicated.
-r, --rss=RSS
Only scan for processes with RSS higher than indicated.
-P, --pcpu=PCPU
Only scan for processes with PCPU higher than indicated.
-u, --user=USER
Only scan for processes with user name or ID indicated.
-a, --argument-array=STRING
Only scan for processes with args that contain STRING.
--ereg-argument-array=STRING
Only scan for processes with args that contain the regex STRING.
-C, --command=COMMAND
Only scan for exact matches of COMMAND (without path).
-k, --no-kthreads
Only scan for non kernel threads (works on Linux only).
RANGEs are specified 'min:max' or 'min:' or ':max' (or 'max'). If specified 'max:min', a
warning status will be generated if the count is inside the specified range
This plugin checks the number of currently running processes and generates WARNING or
CRITICAL states if the process count is outside the specified threshold ranges. The process
count can be filtered by process owner, parent process PID, current state (e.g., 'Z'), or may
be the total number of running processes

Examples:
check_procs -w 2:2 -c 2:1024 -C portsentry Warning if not two processes with
command name portsentry.
Critical if < 2 or > 1024 processes
check_procs -w 10 -a '/usr/local/bin/perl' -u root Warning alert if > 10 processes with

command arguments containing '/usr/local/bin/perl' and owned by root
check_procs -w 50000 -c 100000 --metric=VSZ Alert if VSZ of any processes over 50K
or 100K
check_procs -w 10 -c 20 --metric=CPU Alert if CPU of any processes over 10%% or

20%%
check_ssh
Try to connect to an SSH server at specified server and port
Usage:
check_ssh [-4|-6] [-t <timeout>] [-r <remote version>] [-p <port>] <host>
Options:
-h, --help
-V, --version
-p, --port=INTEGER
Port number (default: 22)
-4, --use-ipv4
Use IPv4 connection
-6, --use-ipv6
Use IPv6 connection
-r, --remote-version=STRING
Warn if string doesn't match expected server version (ex: OpenSSH_3.9p1)
-P, --remote-protocol=STRING
Warn if protocol doesn't match expected protocol version (ex: 2.0)
-v, --verbose

check_tcp
This plugin tests TCP connections with the specified host (or unix socket).
Usage:
check_tcp -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>]
[-e <expect string>] [-q <quit string>][-m <maximum bytes>] [-d <delay>]
[-t <timeout seconds>] [-r <refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j]
[-D <warn days cert expire>[,<crit days cert expire>]] [-S <use SSL>] [-E]
Options:
-h, --help
-V, --version
-p, --port=INTEGER
Port number (default: none)
-4, --use-ipv4
Use IPv4 connection
-6, --use-ipv6
Use IPv6 connection
-E, --escape
Can use \n, \r, \t or \ in send or quit string. Must come before send or quit option
Default: nothing added to send, \r\n added to end of quit
-s, --send=STRING
String to send to the server
-e, --expect=STRING
String to expect in server response (may be repeated)
-A, --all
All expect strings need to occur in server response. Default is any
-q, --quit=STRING
String to send server to initiate a clean close of the connection
-r, --refuse=ok|warn|crit
Accept TCP refusals with states ok, warn, crit (default: crit)
-M, --mismatch=ok|warn|crit
Accept expected string mismatches with states ok, warn, crit (default: warn)
-j, --jail
Hide output from TCP socket
-m, --maxbytes=INTEGER
Close connection once more than this number of bytes are received

-d, --delay=INTEGER
Seconds to wait between sending string and polling for response
-D, --certificate=INTEGER[,INTEGER]
Minimum number of days a certificate has to be valid.
1st is #days for warning, 2nd is critical (if not specified - 0).
-S, --ssl
Use SSL for the connection.
-v, --verbose
check_users
This plugin checks the number of users currently logged in on the local system and
generates an error if the number exceeds the thresholds specified.
Usage:
check_users -w <users> -c <users>
Options:
-h, --help
-V, --version
Set WARNING status if more than INTEGER users are logged in
Set CRITICAL status if more than INTEGER users are logged in
check_dhcp
This plugin tests the availability of DHCP servers on a network.
Usage:
check_dhcp [-v] [-u] [-s serverip] [-r requestedip] [-t timeout] [-i interface] [-m mac]
Options:
-h, --help

-V, --version
-v, --verbose
-s, --serverip=IPADDRESS
IP address of DHCP server that we must hear from
-r, --requestedip=IPADDRESS
IP address that should be offered by at least one DHCP server
Seconds to wait for DHCPOFFER before timeout occurs
-i, --interface=STRING
Interface to to use for listening (i.e. eth0)
-m, --mac=STRING
MAC address to use in the DHCP request
-u, --unicast
Unicast testing: mimic a DHCP relay, requires -s
3.2.5 Hôtes :
Définissons un hôte représentant un serveur nommé srv-web1. Il est vérifié avec la
commande check-host-alive qui envoie simplement un ping vers l’adresse du serveur. Ce test
est effectué toutes les 5 minutes. En cas de problème, ce test est réitéré deux autres fois : la
propriété max_check_attempts = 3 = 2 + (1 test déjà effectué), sera approfondie dans la suite
du chapitre. Si le problème persiste, une notification est envoyée au groupe web-admins. Si
le problème n’est pas résolu 30 minutes après, une autre notification est envoyée, et ainsi de
suite. Lorsque le problème est résolu, le compteur repasse à zéro.
Définition d’un hôte

define host{
host_name srv-web1
alias Serveur Web 1
address 192.168.0.1
check_command check-host-alive
check_interval 5
retry_interval 1
check_period 24x7
contact_groups web-admins

notification_period 24x7
notification_options d,u,r
}
3.2.6 Services :
Définissons un service Http vérifiant que le port 80 (HTTP) est bien ouvert sur le serveur srv-
web1. Le numéro de port est ici passé en argument numéro 1 à la commande check_tcp
définie précédemment. Si la commande avait eu besoin d’un second argument, on l’aurait
ajouté à la suite, en mettant un autre ! entre les arguments. Par exemple check_tcp!80!5, 80
étant $ARG1$ dans la commande et 5, $ARG2$.
Il est à noter que ceci vaut pour tous les appels de check_command et donc pour les hôtes
également.
Les paramètres contacts et contact_groups n’ont pas besoin d’être présents tous les deux. Si
un seul est positionné, la définition est valide.
Cette vérification est faite toutes les 5 minutes. En cas de problème, un test supplémentaire
est effectué (max_check_attempts = 3 = 2 + 1 test déjà effectué) au bout de 3 minutes. Si le
problème est toujours présent, une notification est envoyée aux admins-web. Au bout de 30
minutes, si le problème n’est toujours pas résolu, une autre notification est envoyée et ainsi
de suite.
Définition d’un service

define service{
host_name srv-web1
service_description Http
check_command check_tcp!80
check_interval 5
retry_interval 3
check_period 24x7
contact_groups admins-web
}

3.2.7 Contacts :
Voici une définition de contact. Il se nomme Amine Bakri. Il souhaite être averti tout le temps
et ce, par e-mail.
Définition du contact abakri

define contact{
contact_name abakri
alias Amine Bakri
host_notifications_enabled 1
service_notifications_enabled 1
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email abakri@insim.dz
}
3.2.8 Groupe de contacts :

Voici un exemple de définition d’un groupe de contacts regroupant les administrateurs
abakri et ksnoussi et incluant également les membres du groupe admins-linux.
Définition d’un groupe de contacts

define contactgroup{
contactgroup_name admins-web
alias Administrateurs web
members abakri,ksnoussi
contactgroup_members admins-linux
}

3.3 Diagramme des objets Nagios :

4 Étude de cas :
Schéma physique :
Notre architecture de test se compose :
 D’un Serveur Nagios (Linux : DEBIAN),
 D’un Serveur Web (Linux : DEBIAN),
 D’un Serveur DNS (Linux : DEBIAN),
 D’une Machine Cliente (Windows Seven),
 De deux Switchs,
 D’un Routeur

 Installation de Nagios
 Configuration des équipements & machines
 Fichiers de configuration de Nagios :
o La première étape de configuration est de définir l’arborescence dans le fichier
« /usr/local/nagios/etc/nagios.cfg ».
# LOG FILE
# This is the main log file where service and host events are logged
# for historical purposes. This should be the first option specified
# in the config file!!!
log_file=/usr/local/nagios/var/nagios.log
# OBJECT CONFIGURATION FILE(S)

# These are the object configuration files in which you define hosts,
# host groups, contacts, contact groups, services, etc.
# You can split your object definitions across several config files
# if you wish (as shown below), or keep them all in a single config file.
# You can specify individual object config files as shown below:
cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg
# Definitions for monitoring the local (Linux) host
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
# Definitions for monitoring a Linux server web
cfg_file=/usr/local/nagios/etc/objects/web.cfg
# Definitions for monitoring a Windows
cfg_file=/usr/local/nagios/etc/objects/windows.cfg
# Definitions for monitoring a Linux server dns
cfg_file=/usr/local/nagios/etc/objects/dns.cfg
# Definitions for monitoring a switch 1
cfg_file=/usr/local/nagios/etc/objects/switch1.cfg
# Definitions for monitoring a router
cfg_file=/usr/local/nagios/etc/objects/routeur.cfg
# Definitions for monitoring a switch 2
#cfg_file=/usr/local/nagios/etc/objects/switch2.cfg
# Definitions des groupes
cfg_file=/usr/local/nagios/etc/objects/groupe.cfg

# Definitions des dépendances
cfg_file=/usr/local/nagios/etc/objects/dependence.cfg
o Par la suite, il faut créer les contacts qui recevront les différentes alertes, pour cela
il faut créer le fichier « /usr/local/nagios/etc/objects/conctact.cfg » :
o Nous pouvons maintenant commencer à définir les différents hôtes qui composent
notre architecture : ces fichiers seront créés sous le répertoire
«/usr/local/nagios/etc/objects/» :
localhost.cfg
# HOST DEFINITION
# Define a host for the local machine
define host{
use linux-server ; Name of host template to use ; This host definition
will inherit all variables that are defined ; in (or inherited by) the
linux-server host template definition.
host_name Serveur_Nagios
alias localhost
address 127.0.0.1
}
# SERVICE DEFINITIONS
# Define a service to "ping" the local machine
define service{
use local-service ; Name of service template to use
service_description PING
check_command check_ping!100.0,20%!500.0,60%
check_period 24x7
}
# Define a service to check HTTP on the local machine.

# Disable notifications for this service by default, as not all users may have HTTP
enabled.
define service{
use local-service ; Name of service template to use
service_description HTTP
check_command check_http
notifications_enabled 0
check_period 24x7
}

routeur.cfg :
# HOST DEFINITION
define host{
host_name Routeur
alias routeur
address 10.3.2.26
parents Switch1
first_notification_delay 0
contact_groups admins
notification_options d,r
}
# Define a service to "ping" the host
define service{
host_name Routeur
retry_interval 1
normal_check_interval 2
check_period 24x7
}
switch1.cfg :
# HOST DEFINITION
define host{
host_name Switch1
alias switch nagios
address 10.3.2.1
parents Serveur_Nagios
}

define service{
host_name Switch1
retry_interval 1
check_period 24x7
}
web.cfg :
# HOST DEFINITION
define host{
host_name Serveur_HTTP
alias serveur-pc-romain
address 10.7.10.2
parents Routeur
}
# Define a service to check HTTP on the local machine.
# Disable notifications for this service by default, as not all users may have
# HTTP enabled.
define service {
retry_check_interval 1
check_period 24x7
}

define service{
retry_interval 1
check_period 24x7
}
dns.cfg :
# HOST DEFINITION
define host{
host_name Serveur_DNS
alias serveur-pc-picard
address 10.7.10.3
parents Routeur
}
# Define a service to check DNS on the local machine.
define service {
service_description DNS
retry_check_interval 1
check_period 24x7
}

define service{
retry_interval 1
check_period 24x7
}
windows.cfg :
#
# HOST DEFINITION
#
define host{
host_name Windows
alias poste_client
address 10.3.2.3
parents Switch1
}
#
#
define service{
host_name Windows
retry_interval 1
check_period 24x7
}

groupe.cfg :
#
# HOSTGROUPS DEFINITIONS
#
define hostgroup{
hostgroup_name sous linux ; The name of the hostgroup
alias Serveur ; Long name of the group
members Serveur_Nagios, Serveur_DNS, Serveur_HTTP
}
define hostgroup{
hostgroup_name switch/routeur ; The name of the hostgroup
alias Equipements reseaux ; Long name of the
group
members Routeur, Switch1
}
dependence.cfg :
#
# DEPENDENCIES DEFINITIONS
#
define servicedependency{
service_description DNS
dependent_host_name Serveur_HTTP
dependent_service_description HTTP
dependency_period 24x7
execution_failure_criteria o
notification_failure_criteria n
}

5 Nagios : Les notions avancées
5.1 Les dépendances d’hôtes et de services

Les dépendances d'hôtes et de services sont une fonctionnalité avancée qui vous permet de
contrôler le comportement des hôtes et des services selon l'état d'un ou plusieurs autres hôtes
ou services. Je vais expliquer comment les dépendances fonctionnent, ainsi que les différences
entre les dépendances d'hôtes ou de services.
Aperçu des dépendances de services
Il y a quelques points qu'il faut savoir concernant les dépendances de services:
 Un service peut être dépendant d'un ou plusieurs autres services

 Un service peut être dépendant de services qui ne sont pas associés au même hôte
 Les dépendances de services ne se sont pas héritées (à moins que ce ne soit
explicitement spécifié)
 Les dépendances de services permettent de supprimer l'exécution de services et de
notifications de service selon différents critères (états OK, WARNING, UNKNOWN,
et/ou CRITICAL)
 Les dépendances d'un service ne sont seulement valables durant la période de temps
spécifiée
Définition de dépendances de services
Tout d'abord, les bases. Vous créez des dépendances de service en ajoutant des définitions
de dépendance de service dans votre (vos) fichier(s) de configuration des objets .Dans
chaque définition, vous spécifiez le service dépendant, le service dont il dépend, et la
condition (s'il y a lieu) qui provoque l'échec des dépendances d'exécution et de notification
(ces notions sont décrites plus loin).
Vous pouvez créer plusieurs dépendances pour un même service, mais il vous faut une
définition de dépendance de service séparée pour chaque dépendance créée.
Exemple de dépendances de services
L'image suivante nous montre un exemple d'une trame typique de notification de service et
d'exécution de ses dépendances. Différents services dépendent d'autres services pour que
l'exécution des checks et des notifications se réalise.

Dans l'exemple ci-dessus, les définitions de dépendance du Service F sur l'hôte C seraient
écrites comme ceci :
define servicedependency {
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
notification_failure_criteria w,u
}
host_name Host B
service_description Service E
execution_failure_criteria n
notification_failure_criteria w,u,c
}
host_name Host B
service_description Service C
execution_failure_criteria w
notification_failure_criteria c
}
Les autres définitions de dépendances décrites dans l'image précédente s'écriraient comme
suit :
host_name Host A
service_description Service A
dependent_host_name Host B

dependent_service_description Service D
execution_failure_criteria u
}
host_name Host A
service_description Service B
dependent_service_description Service E
execution_failure_criteria w,u
notification_failure_criteria c
}
host_name Host B
service_description Service C
dependent_service_description Service E
execution_failure_criteria n
notification_failure_criteria w,u,c
}
Comment les dépendances d'un service sont testées
Avant que Nagios n'exécute un contrôle de service ou n'envoie des notifications concernant
un service, il vérifiera si le service comporte des dépendances. Si ce n'est pas le cas, le
contrôle est exécuté ou la notification est envoyée comme en temps normal. Si le service a
bien une ou plusieurs dépendances, Nagios vérifiera chacune de la manière suivante :
Nagios récupère l'état courant* du service dont il dépend.
Nagios compare l'état courant du service dont il dépend aux options d'échec soit d'exécution
soit de notification dans la définition de dépendance (selon ce qui adapté).
Si l'état courant du service dont il dépend correspond à une des options d'échec, la
dépendance est réputée avoir échoué et Nagios sortira de la boucle de vérification des
dépendances.
Si l'état courant du service dont il dépend ne correspond à aucune des options d'échec de la
dépendance, la dépendance est réputée avoir réussi et Nagios continuera avec la prochaine
dépendance.
Ce cycle continue jusqu'à ce que toutes les dépendances du service aient été vérifiées, ou
jusqu'à ce qu'une dépendance échoue.
*Il est important de noter que par défaut, Nagios utilisera l'état hard courant du (des) service(s)
dont il dépend lors de ses vérifications de dépendance. Si vous voulez que Nagios utilise l'état

le plus récent des services (que ce soit un état soft ou hard), activez l'option
soft_state_dependencies .
Dépendances d'exécution
Les dépendances d'exécution permettent de limiter les vérifications de service actives .Les
vérifications de service passives ne sont pas affectées par les dépendances d'exécution.
Si tous les tests de dépendance d'exécution du service réussissent, Nagios exécute le contrôle
du service comme à l'accoutumée. Si ne serait-ce qu'une dépendance d'exécution du service
échoue, Nagios arrêtera temporairement l'exécution des contrôles pour ce service
(dépendant). Par la suite, les tests des dépendances d'exécution du service vont réussir.
Alors, Nagios recommencera les contrôles de ce service de manière normale. Pour plus
d'informations sur l'algorithme d'ordonnancement des contrôles , lisez ceci.
Dans l'exemple ci-dessus, les dépendances d'exécution du Service E échoueraient si le Service

B est dans un état WARNING ou UNKNOWN. Si c'était le cas, le contrôle de service ne serait
pas réalisé et serait ordonnancé pour une future exécution (potentielle).
Dépendances de notification
Si tous les tests de dépendance de notification du service réussissent, Nagios enverra les
notifications pour ce service comme à l'accoutumée. Si, ne serait-ce qu'une dépendance de
notification du service échoue, Nagios arrêtera temporairement l'émission de notifications
pour ce service (dépendant). Plus tard, les tests des dépendances de notifications du service
vont réussir. Alors, Nagios recommencera à envoyer des notifications pour ce service de
manière normale. Pour plus d'informations sur l'algorithme de notification, lisez ceci.
Dans l'exemple ci-dessus, les dépendances de notification du Service F échoueraient si le

Service C est dans un état CRITICAL, et/ou si le Service D est dans un état WARNING ou
UNKNOWN, et/ou si le Service E est dans un état WARNING, UNKNOWN, ou CRITICAL. Si
c'était le cas, les notifications pour ce service ne seraient pas envoyées.
Héritage de dépendance
Comme je l'ai déjà dit, par défaut les dépendances de service ne sont pas héritées. Dans
l'exemple ci-dessus, vous pouvez voir que le Service F est dépendant du Service E. Toutefois,
il n'hérite pas automatiquement des dépendances du Service E sur le Service B et le Service C.
Pour rendre le Service F dépendant du Service C, nous avons dû ajouter une autre définition
de dépendance. Il n'y a pas de définition de dépendance pour le Service B, donc le Service F
n'est pas dépendant du Service B.
Si vous voulez rendre les dépendances de service héritables, utilisez le paramètre

inherits_parent dans la définition de la dépendance du service .Quand ce paramètre est
activé, il indique que la dépendance hérite des dépendances du service dont elle dépend
(également appelé le service maître). En d'autres termes, si le service maître dépend d'autres
services et qu'une de ces dépendances est en échec, la dépendance sera aussi en échec.

Dans l'exemple ci-dessus, imaginez que vous vouliez ajouter une nouvelle dépendance au
service F qui le rende dépendant du service A. Vous pourriez créer une nouvelle définition de
dépendance qui indique le service F comme le service dépendant et le service A comme le
service maître (c'est-à-dire le service dont il est dépendant). Vous pourriez également modifier
la définition de dépendance des services D et F de la manière suivante :
host_name Host B
service_description Service D
inherits_parent 1
}
Comme le paramètre inherits_parent est activé, la dépendance entre les services A et D sera
testée quand la dépendance entre les services F et D le sera.
Les dépendances peuvent avoir de multiples niveaux d'héritage. Si la définition de

dépendance entre A et D avait le paramètre inherits_parent activé, et que le service A était
dépendant d'un autre service (appelons-le service G), le service F serait dépendant des
services D, A, et G (et le serait potentiellement avec chacun selon des critères différents).
Dépendances d'hôtes
Comme vous vous y attendez probablement, les dépendances d'hôtes fonctionnent d'une
manière similaire à celles de services. La principale différence est que ce sont des hôtes et
pas des services. Une autre différence est que la dépendance d'hôte ne sert qu'à supprimer
des notifications d'hôtes et non pas des controles d'hôtes.
ATTENTION ! Ne confondez pas les dépendance d'hôtes avec les relations parent/enfant.
Vous utiliserez les relations parent/enfant (définies avec le paramètre parents dans la
définition d'hôte) dans la plupart des cas, plutôt que des dépendances d'hôtes.
Les bases de ce qu'il faut savoir sur les dépendances d'hôtes:
Un hôte peut dépendre d'un ou pusieurs hôtes
Les dépendances d'hôtes ne se sont pas héritées (à moins que ce ne soit explicitement
spécifié)
Les dépendances d'hôtes peuvent désactiver l'éxécution des vérifications et notifications

dans certains circonstances (état UP, DOWN, et/ou UNREACHABLE)
Les dépendances d'un hôte ne sont seulement valable durant la période de temps spécifiée
Exemple de dépendances d'hôtes

L'image suivante nous montre une trame de l'acheminement logique des dépendances de
notifications d'hôtes.
Dans l'image ci-dessus, les définitions de dépendances pour l'hôte C devraient être définies
ainsi:
define hostdependency {
host_name Host A
notification_failure_criteria d
}
define hostdependency {
host_name Host B
notification_failure_criteria d,u
}
Comme pour les dépendances de services, les dépendances d'hôtes ne sont pas héritées.
Dans l'exemple de cette image, vous pouvez voir que l'hôte C n'hérite pas des dépendances
de l'hôte B. Pour que C soit dépendant de A, une autre définition d'hôte doit être précisée.
Les dépendances de notifications d'hôtes marchent d'une manière similaire à celles de

services. Si toutes les notifications de dépendance d'un hôte réussissent, Nagios enverra les
notifications comme à l'accoutumée. Si ne serait-ce qu'une de ces dépendances échoue,
Nagios supprimera temporairement toutes les notifications pour cet hôte (dépendant). Par la
suite, les dépendances réussiront à nouveau. Nagios recommencera alors à envoyer les
notifications de manière habituelle. Vous trouverez ici plus d'informations sur la l'algorithme
de notification.
5.2 Les escalades des notifications

Nagios supporte l'escalade optionelle des notifications envoyées aux contacts pour des
services ou hôtes. Je vais en expliquer rapidement le fonctionnement, bien que cela se
comprenne facilement… L'escalade pour les notifications d'hôtes et de services est possible

par la création de définition d'escalations d'hôtes et de d'escalations de services dans votre
Object Configuration Overview .
Les exemples que je fournis ci-dessous utilisent tous les définitions d'escalades, mais les
escalades d'hôtes fonctionnent sous le même principe. Excepté, bien sûr, qu'il faut remplacer
services par hosts.
Quand y a-t-il escalade des notifications?
Les notifications sont échelonnées si et seulement si une ou plusieurs définitions d'escalade
correspondent à la notification actuelle qui est envoyée. Si la notification de service ou d'un
hôte n'a pas de définitions d'escalade valides qui s'y applique, le(s) groupe(s) de contact
spécifié dans le groupe d'hôte ou dans la définition de service sera appliqué par défaut.
Regardons l'exemple ci-dessous:
define serviceescalation{
host_name webserver
first_notification 3
last_notification 5
contact_groups nt-admins,managers
}
host_name webserver
last_notification 10
contact_groups nt-admins,managers,everyone
}
Remarquez qu'il y a des trous dans les définitions d'escalade de notification. En particulier,
les notifications 1 et 2 ne sont pas prises en compte par les escalades, ni celles au-delà de 10.
Pour la première et la seconde notification, de même que pour celles au-delà de la dixième,
le groupe de contacts par défaut précisé dans la définition de service est utilisé. Dans tous les
exemples que j'utiliserai, je considèrerai que le groupe de contacts par défaut des définitions
de service s'appelle nt-admins.
Contact Groups
En définissant des escalades de notification, il est important d'être conscient que n'importe
quels groupes de contact qui étaient des membres de plus bas niveaux d'escalades (c'est-à-
dire ceux avec les nombres de notification plus basses) devraient aussi être inclus dans les
niveaux plus haut des définitions d'escalade. Cela devrait être fait pour garantir que
quelqu'un qui est notifié d'un problème continue à suivre ce problème jusqu'à sa résolution.
Exemple :
define serviceescalation {
host_name webserver

last_notification 5
}
host_name webserver
last_notification 0
}
Le premier (ou plus bas) niveau d'escalade comprend à la fois les groupes de contact nt-
admins et managers. Le dernier (ou plus haut) niveau d'escalade comprend les groupes de
contact nt-admins, managers, et everyone. Remarquez que le groupe de contact nt-admins
fait partie des deux définitions d'escalade. C'est pour qu'il continue à être prévenu s'il reste
des problèmes après que les deux premières notifications de service aient été envoyées. Le
groupe de contact managers apparaît d'abord dans la définition d'escalade la plus basse - il
reçoit sa première notification lorsque la troisième notification de problème est envoyée.
Nous voulons que le groupe managers continue de recevoir des notifications si le problème
persiste après cinq notifications, il fait donc partie de la plus haute définition d'escalade.
Recoupement des portées des escalades
Les définitions d'escalade de notification peuvent avoir des portées qui se recoupent.
Prenons l'exemple suivant :
host_name webserver
last_notification 5
}
host_name webserver
last_notification 0
contact_groups on-call-support
}
Dans l'exemple ci-dessus:

Les groupes de contact nt-admins et managers reçoivent la troisième notification
Les trois groupes de contact reçoivent les quatrième et cinquième notifications
Seul le groupe de contact on-call-support reçoit les notifications à partir de la sixième
notification
Notifications de reprise d'activité
Les notifications de reprise d'activité sont légèrement différentes des notifications de
problème lorsqu'il s'agit d'escalade. Prenons l'exemple suivant :
host_name webserver
last_notification 5
}
host_name webserver
last_notification 0
contact_groups on-call-support
}
Si, après trois notifications de problème, une notification de reprise d'activité est envoyée au
service, qui reçoit la notification ? La reprise d'activité est la quatrième notification envoyée.
Cependant, le code d'escalade est suffisamment bien fait pour que seules les personnes qui
ont reçu la troisième notification reçoivent celle de reprise d'activité. Dans ce cas, les groupes
de contact nt-admins et managers recevront la notification de reprise d'activité.
Intervalles de notification
Vous pouvez modifier la fréquence à laquelle les notifications escaladées sont émises pour un
hôte ou un service particulier en utilisant le paramètre notification_interval de la définition
d'escalade de groupe d'hôtes ou de service. Par exemple :
host_name webserver
last_notification 5
}
host_name webserver
last_notification 0
}
Dans cet exemple nous voyons que l'intervalle de notification par défaut pour les services est
de 240 minutes (c'est la valeur donnée dans la définition du service). Quand la notification de
ce service est escaladée lors des 3ème, 4ème, et 5ème notifications, un intervalle de 45
minutes sera utilisé entre les notifications. Lors de la 6ème notification et des suivantes,
l'intervalle de notification sera de 60 minutes, comme il est spécifié dans la seconde
définition d'escalade.
Comme il est possible d'avoir des définitions d'escalade qui se chevauchent pour un groupe
d'hôtes ou un service donné, et comme un hôte peut être membre de plusieurs groupes
d'hôtes, Nagios doit décider quel intervalle de notification utiliser quand des définitions
d'escalade se chevauchent. Dans tous les cas de chevauchement, Nagios choisira l'intervalle
de notification le plus court. Prenez l'exemple suvant :
host_name webserver
last_notification 5
}
host_name webserver
last_notification 0
}
Nous voyons que les deux définitions d'escalade se chevauchent sur les 4ème et 5ème
notifications. Pour ces notifications, Nagios utilisera un intervalle de notification de 45
minutes, car c'est le plus petit intervalle présent dans les définitions d'escalade valides de ces
notifications.
Une dernière remarque à propos des intervalles de notification concerne les intervalles de 0.
Un intervalle de 0 signifie que Nagios ne doit émettre une notification que pour la première
notification valide durant cette définition d'escalade. Toutes les notifications suivantes pour
le groupe d'hôte ou le service seront supprimées. Prenez cet exemple :
host_name webserver

last_notification 5
}
host_name webserver
last_notification 5
}
host_name webserver
last_notification 0
}
Dans l'exemple ci-dessus, il y aurait au maximum 4 notifications de problème envoyées à

propos du service. Ceci est dû au fait que l'intervalle de notification de 0 dans la seconde
définition d'escalade indique qu'une seule notification doit être émise (à partir de et en
incluant la 4ème notification) et que toutes les notifications suivantes doivent être
supprimées. A cause de cela, la troisième définition d'escalade du service est sans effet, car il
n'y aura jamais plus de quatre notifications.
Restrictions de période de temps
Dans des circonstances normales, les escalades peuvent servir aux heures où une notification
pourrait normalement être envoyée pour le service. Cette fenêtre d'heures de notification est
déterminée par le paramètre notification_period de la définition de service. Notez que la
notification est toujours soumise aux restrictions d'heure normales imposées par le
paramètre notification_period de l'escalade de service, et donc que la période de temps que
vous spécifiez dans l'escalade doit être comprise dans une plus grande fenêtre d'heures de
notification.
Vous pouvez optionnellement restreindre l'escalade pour qu'elle ne soit prise ne compte
pendant une période de temps spécifique en utilisant le paramètre escalation_period dans la
définition de l'escalade de service. Si vous utilisez le paramètre escalation_period pour
spécifier une Time Period Definition pendant laquelle utiliser l'escalade, l'escalade sera prise
en compte uniquement pendant ces heures. Si vous ne spécifiez aucun paramètre
escalation_period, l'escalade peut être prise en compte à n'importe quelle heure pendant la
fenêtre d'heures de notification pour le service.

Les escalades de notifications sont toujours soumises aux restrictions de temps normales
imposées par le paramètre notification_period dans une défintion d'hôte ou de service, donc
le timeperiod que vous spécifiez dans une définition d'escalade correspond à une sorte de
sous-ensemble de ce qu'on appelerait la fenêtre de temps de notification.
Restrictions d'état
Si vous voulez restreindre la définition d'escalade pour qu'elle soit prise en compte
uniquement quand le service est dans un état donné, vous pouvez utiliser le paramètre
escalation_options dans la définition de l'escalade de service. Si vous n'utilisez pas le
paramètre escalation_options, l'escalade peut être prise en compte quel que soit l'état du
service.
5.3 Supervision redondante
Cette section décrit quelques scénarii d'implémentation de systèmes de supervision

redondante ainsi que plusieurs topologies réseau. Avec la redondance des systèmes, vous
pouvez maintenir la possibilité de surveiller votre réseau alors que le premier système sur
lequel tourne Nagios pose problème ou lorsque des parties du réseau deviennent
injoignables.
Si vous apprenez à utiliser Nagios, je suggère de ne pas essayer d'implémenter la redondance

tant que vous n'êtes pas habitué aux pré-requis déjà présentés. La redondance est un sujet
relativement complexe, et il est encore plus difficile de l'implémenter correctement.
Pré-requis
Avant de penser pouvoir implémenter la redondance avec Nagios, vous devez être familier
avec ce qui suit…
Implémenter les Gestionnaires d'événements pour les hôtes et services
Présenter une commande externe à Nagios via des scripts shell
Exécuter des plugins sur des hôtes distants en utilisant soit NRPE, soit d'autres méthodes
Vérifier l'état du processus Nagios avec le plugin check_nagios
Exemples de scripts
Tous les exemples que j'utilise dans cette documentation se trouvent dans le répertoire
eventhandlers/ de la distribution Nagios. Vous devrez probablement les modifier pour les
faire fonctionner sur votre système…
Scénario 1 - Supervision Redondante

Introduction
Buts
Diagramme de topologie réseau
Réglages initiaux du programme
Configuration Initiale
Définition de commandes de Gestion d'Evènements
Scripts de Gestion d'Evènements
Que fait ce script pour nous ?
Délais
Cas spéciaux
Introduction
Ceci est une méthode facile (et naïve) pour implémenter le monitoring redondant d'hôtes sur
votre réseau, qui protègera seulement contre un nombre limité de problèmes. Des réglages
plus complexes sont nécessaires pour fournir une redondance plus pratique, une meilleure
redondance à travers des segments réseau, etc.
Buts
Le but de ce type d'implémentation de redondance est simple. Les hôtes maître et esclave
surveillent les mêmes systèmes et services sur le réseau. Dans des circonstances normales, le
système maître prendra en charge l'envoi des notifications aux contacts concernant les
problèmes détectés. Nous voulons que système esclave fasse fonctionner Nagios et prenne
en charge la notification des problèmes si:
Soit le système Maître faisant fonctionner Nagios ne répond plus
Soit le processus Nagios sur le système Maître arrête de fonctionner.
Diagramme de topologie réseau
Le diagramme ci-dessous montre une configuration réseau très simple. Pour ce scénario, je
vais supposer que les systèmes A et E font tourner tous deux Nagios et surveillent tous les
systèmes que l'on y voit. Le système A sera considéré comme étant le système maître et le
système E sera considéré comme étant l'esclave.

Le système esclave (système E) a son paramètre initial de notification enable_notifications

désactivé, afin de lui éviter d'envoyer des notifications autant pour les hôtes que pour les
services. Il faut aussi s'assurer que le système esclave a son paramètre
check_external_commands activée. C'est plutôt simple…
Configuration Initiale
Il faudra ensuite considérer les changements entre le(s) fichier(s) de configuration des
objets sur les systèmes maître et esclave…
Je vais supposer que le système maître (système A) est configuré pour surveiller des
services sur tous les systèmes montrés dans le diagramme ci-dessus. Le système esclave
(système E) doit être configuré pour surveiller les mêmes systèmes et services, avec les
ajouts suivants aux fichiers de configuration…
La définition du système A (dans le fichier de configuration du système E) devrait avoir un

gestionnaire d'événement défini. Supposons que le nom du gestionnaire d'événement pour
le système s'appelle handle-master-host-event.
Le fichier de configuration sur le système E devrait avoir un service défini pour surveiller
l'état du processus Nagios sur le système A. Supposons que vous ayez défini cette
vérification de service pour lancer le plugin check_nagios sur le système A.
La définition du service pour la surveillance du processus Nagios sur le système A devrait

être un gestionnaire d'événement. Supposons que ce service gestionnaire d'événement soit
handle-master-proc-event.
Il est important de noter que le système A (le système maître) ne sait rien du système E (le
système esclave). Dans ce scénario, il n'en a simplement pas besoin. Bien évidemment, vous
pouvez surveiller les services du système E depuis le système A, mais cela n'a rien à voir
avec l'implémentation de la redondance…
Définition de commandes de Gestion d'Evènements

Faisons une petite pause, et décrivons les définitions de commandes de gestion
d'événement sur l'esclave. Voici un exemple…
define command {
command_name handle-master-host-event
command_line /usr/local/nagios/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$
}
define command {
command_name handle-master-proc-event
command_line /usr/local/nagios/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$
}
Cela implique que vous ayez placé les scripts de gestion d'événements dans le répertoire
/usr/local/nagios/libexec/eventhandlers. Vous pouvez les placer ailleurs, mais vous devrez
modifier les exemples que j'ai donnés ici.
Scripts de Gestion d'Evènements
Ok, regardons à quoi ressemble ce script…
Gestionnaire d'Evènement de système (handle-master-host-event):
#!/bin/sh
# Only take action on hard host states…
case "$2" in
HARD)
case "$1" in
DOWN)
# The master host has gone down!
# We should now become the master host and take
# over the responsibilities of monitoring the
# network, so enable notifications…
/usr/local/nagios/libexec/eventhandlers/enable_notifications
;;
UP)
# The master host has recovered!
# We should go back to being the slave host and
# let the master host do the monitoring, so
# disable notifications…
/usr/local/nagios/libexec/eventhandlers/disable_notifications
;;
esac
;;
esac
exit 0
Gestionnaire d'Evènements de Service (handle-master-proc-event):

#!/bin/sh
# Only take action on hard service states…
case "$2" in
HARD)
case "$1" in
CRITICAL)
# The master Nagios process is not running!
# We should now become the master host and
# take over the responsibility of monitoring
# the network, so enable notifications…
/usr/local/nagios/libexec/eventhandlers/enable_notifications
;;
WARNING)
UNKNOWN)
# The master Nagios process may or may not
# be running.. We won't do anything here, but
# to be on the safe side you may decide you
# want the slave host to become the master in
# these situations…
;;
OK)
# The master Nagios process running again!
# We should go back to being the slave host,
# so disable notifications…
/usr/local/nagios/libexec/eventhandlers/disable_notifications
;;
esac
;;
esac
exit 0
Que fait ce script pour nous ?
La notification sur le système esclave (système E) est désactivée, donc il n'enverra pas de
notifications pour les systèmes autant que pour les services tant que le processus Nagios
fonctionne sur le système maître (système A).
Le processus Nagios sur le système esclave (système E) devient maître quand…
Le système maître (système A) tombe et le gestionnaire d'événement de système handle-

master-host-event est exécuté.
Le processus Nagios sur le système maître (système A) s'arrête de fonctionner et le

gestionnaire d'événement du service handle-master-proc-event est exécuté.
Dès que le processus Nagios sur le système esclave (système E) a la notification activée, il
sera capable d'envoyer des notifications quant aux services ou problèmes système ou
encore les retours à la normale. A ce moment, le système E a effectivement pris la
responsabilité de notifier les contacts des problèmes de systèmes et services!

Le processus Nagios sur le système E retourne à son état d'esclave quand…
Le système A revient à la normale et le gestionnaire d'événement de système handle-

master-host-event est exécuté.
Le processus Nagios sur le système A revient à la normale et que le gestionnaire

d'événement de service handle-master-proc-event est exécuté.
Dès que le processus Nagios sur le système E est désactivé, il n'enverra plus de notification
concernant les problèmes liés aux services et aux systèmes ou encore les retours à la
normale. Dès ce moment, le système E a pris la responsabilité de notifier les contacts des
problèmes du processus Nagios sur le système A. Tout revient maintenant dans le même
état que lorsque l'on a démarré!
Délais
La redondance dans Nagios n'est en rien parfaite. Un des nombreux problèmes est le délai
entre le moment où le maître tombe et que l'esclave prend le relais. En voici les raisons…
L'intervalle entre la rupture du système maître et la première fois que le système esclave
détecte le problème.
Le temps qu'il faut pour vérifier que le système maître a réellement un problème (en
utilisant une nouvelle fois la commande 'check' d'un service ou d'un système sur le système
esclave)
Le temps entre l'exécution du gestionnaire d'événement et la fois suivante où Nagios va

vérifier la présence d'une commande externe
Vous pouvez minimiser ce délai en…
S'assurant que le processus Nagios sur le système E (re)vérifie un ou plusieurs services avec
une fréquence élevée. Ceci peut être fait en utilisant les arguments check_interval et
retry_interval dans chaque définition de service.
S'assurer que le nombre de re-vérifications de la présence du système A (sur le système E)

permette une détection des problèmes liés au système plus rapidement. Ceci peut être fait
en utilisant l'argument max_check_attempts dans la définition du système.
Augmenter la fréquence de vérification des commandes externes sur le système E. Ceci

peut être fait en modifiant l'option command_check_interval dans le fichier de
configuration principal.
Quand Nagios revient à la normale sur le système A, il y a aussi un délai avant que le
système E ne redevienne esclave. C'est du aux faits suivants…
Le temps entre le retour à la normale du système A la fois suivante où le processus Nagios

sur le système E détecte le retour à la normale.
L'intervalle entre l'exécution du gestionnaire d'événement sur le système E et la fois
suivante où le processus Nagios sur le système E vérifie la présence de commandes externes
Les intervalles exacts entre le transfert des responsabilités de supervision dépendent du

nombre de services définis, l'intervalle auquel les services sont vérifiés, et un peu de
chance. A tous niveaux, c'est mieux que rien.
Cas spéciaux
Il y a une chose à laquelle il faut être attentif… Si le système A tombe, le système de

notifications sur le système E sera activé et prendra la responsabilité de notifier les contacts
de problèmes. Lorsque le système A revient à la normale, le système E aura sa notification
désactivée. Si, quand le système A revient à la normale, le processus Nagios ne redémarre
pas correctement, il y aura une période de temps où aucun système ne notifiera les
contacts de problèmes! Heureusement on peut compter sur la logique de vérification de
services de Nagios. La fois suivante où le processus Nagios sur le système E vérifie l'état du
processus Nagios sur le système A, il verra qu'il ne fonctionne pas. Le système E aura donc
sa notification activée et prendra la responsabilité de notifier les contacts des problèmes.
Le temps où aucun système ne surveille est assez difficile à déterminer. Toutefois, cette
période peut être minimisée en augmentant la fréquence de vérification (sur le système E)
du processus Nagios sur le système A. Le reste est une question de chance, mais le temps de
blackout total ne devrait pas être trop mauvais.
Supervision en mode haute disponibilité
Introduction
Buts
Vérification du processus principal
Cas Supplémentaires
Introduction
La supervision avec gestion de panne est pratiquement identique. Il existe quand même des
différences avec le système précédent scénario 1).
Buts
Le but principal de la gestion de panne est d'avoir le processus Nagios sur le système
esclave en hibernation tant que le processus Nagios sur le système maitre fonctionne. Si le
processus sur le système maître arrête de fonctionner (ou si le système tombe), le
processus Nagios sur le système esclave commence à tout surveiller.

Bien que la méthode décrite dans la partie scénario 1 permette de continuer à recevoir la
notification si le système maitre tombe, il y a quelques pièges. Le plus gros problème est
que le système esclave surveille les mêmes systèmes que le maitre au même moment! Ceci
peut causer des problèmes de trafic excessif et charger les machines surveillées si vous avez
beaucoup de services définis. Voici une manière de contourner ce problème…
Désactiver la vérification active des services et la notification sur le système esclave en

utilisant les paramètres execute_service_checks et enable_notifications . Ceci évitera au
système esclave de surveiller les services et les systèmes et d'envoyer des notifications tant
que le processus Nagios sur le système maître fonctionne. Assurez-vous d'avoir le
paramètre check_external_commands activée sur le système esclave.
Vérification du processus principal
Créer un tâche programmée [cron job] sur le système esclave qui lance périodiquement un
script (disons toutes les minutes) qui vérifie l'état du processus Nagios sur le système maître
(en utilisant le plugin check_nrpe sur le système esclave et le démon NRPE sur le système
maître). Le script va vérifier le code de retour du plugin check_nrpe. S'il retourne un état
non-OK, le script va envoyer les commandes appropriées au fichier de commandes externes
pour activer la notification et la surveillance des services. Si le plugin retourne un état OK, le
script enverra les commandes pour désactiver la surveillance active des services et la
notification.
En procédant comme suit, vous n'utilisez qu'un processus de surveillance de système et de

service à la fois, ce qui est plus efficace que de surveiller en double.
Notez aussi que vous ne devez pas définir de gestionnaires d'événements comme défini
dans le scénario 1, car les contraintes sont surmontées de manière différente.
Cas Supplémentaires
Vous avez maintenant implémenté une gestion de panne de manière plutôt basique. Il y a
toutefois d'autres manières de procéder pour que cela fonctionne de manière plus douce.
Le gros problème avec cette technique est surtout le fait que l'esclave ne connait pas l'état
courant des services ou des systèmes au moment même où il prend à sa charge le travail de
surveillance. Une manière de solutionner ce problème est d'activer la commande ocsp sur le
système maître et de lui demander de rapporter les résultats des vérifications à l'esclave en
utilisant l'addon NSCA De cette manière, le système esclave possède un statut mis à jour
des informations de tous les services et des systèmes s'il venait à prendre en charge la
surveillance. Tant que les vérifications actives ne sont pas activées sur le système esclave, il
n'effectuera aucune vérification active. Malgré tout, il exécutera les vérifications si
nécessaire. Cela signifie qu'autant le maître que l'esclave exécuteront les vérifications de
système comme il le faut, ce qui n'est pas vraiment une bonne affaire puisque la majorité
des surveillances fonctionnent par rapport aux services.

Voilà à peu près tout ce qu'il y a à configurer.
5.4 Supervision distribuée
Nagios peut être configuré pour supporter la supervision distribuée des services et ressources du
réseau. Je vais essayer d'expliquer brièvement comment cela peut être fait…
Buts
Le but de l'environnement de supervision distribuéé que je vais décrire est de décharger l'excès de
charge induit par les contrôle de services (sur la CPU, etc.) du serveur central sur un ou plusieurs
serveurs distribués. La plupart des petites et moyennes entreprises n'auront pas réellement besoin de
mettre en œuvre cet environnement. Cependant, quand vous voulez superviser des centaines, voire des
milliers d'hôtes (et plusieurs fois cette valeur en termes de services) à l'aide de Nagios, cela commence
à devenir important.
Diagramme de référence
Le diagramme ci-dessous devrait vous aider à vous faire une idée du fonctionnement de la supervision
distribuée avec Nagios. Je ferai référence aux éléments du diagramme quand j'expliquerai les choses…
Serveur central ou serveurs distribués
Quand on installe l'environnement de supervision distribuée avec Nagios, il y a des

différences entre la configuration du serveur central et celle des serveurs distribués. Je vous

montrerai comment configurer ces deux types de serveurs et j'expliquerai les effets des
changements sur la supervision en général. A l'intention des débutants, décrivons d'abord
l'utilité des différents serveurs…
Le rôle d'un serveur distribué est de contrôler tous les services définis pour une grappe
[cluster] d'hôtes. J'utilise ce terme grappe de manière inappropriée : il désigne simplement
un groupe d'hôtes de votre réseau. Selon la topographie de votre réseau, vous pouvez avoir
plusieurs grappes en un seul lieu, ou chaque grappe peut être séparée par un WAN, un
pare-feu, etc. Il faut surtout se souvenir d'une chose, c'est que pour chaque groupe d'hôtes
(de quelque manière que vous le définissiez), il y a un serveur distribué sur lequel Nagios
tourne et qui supervise les services des hôtes du cluster. Un serveur réparti est
généralement une installation simplifiée de Nagios. Il n'est pas besoin d'installer l'interface
web, d'envoyer des notifications, de faire tourner les scripts de gestionnaires d'événements
ou de faire autre chose que l'exécution des contrôles de service si vous ne le souhaitez pas.
De plus amples explications relatives à la configuration du serveur distribué suivront…
Le but du serveur central est d'écouter simplement les résultats des contrôles de service
d'un ou de plusieurs serveurs distribués. Même si les services sont occasionnellement
contrôlés activement par le serveur central, les contrôles actifs sont seulement exécutés
dans des circonstances particulières ; disons donc pour l'instant que le serveur central
n'accepte que les contrôles passifs. Comme le serveur central obtient des résultats des
contrôles de services passifs d'un ou plusieurs serveurs répartis, il est utilisé comme point
central pour la logique de supervision (ex: il envoie des notifications, exécute les scripts de
gestionnaires d'événements, détermine l'état des hôtes, son interface web est installée,
etc.).
Obtention des informations de contrôle de service à partir de serveurs distribués
Avant de sauter à pieds joints dans les détails de la configuration, il faut savoir comment
envoyer les résultats des contrôles de service des serveurs distribués au serveur central. J'ai
déjà expliqué comment soumettre des résultats de contrôles passifs à Nagios à partir de la
machine même sur laquelle Nagios tourne (cf. documentation sur les contrôles passifs),
mais je n'ai pas fourni d'information sur la manière d'envoyer des résultats de contrôles de
service à partir d'autres hôtes.
Afin de faciliter l'envoi de résultats de contrôles passifs à un hôte distant, j'ai écrit le module
complémentaire NSCA . Il contient deux parties. La première est un programme client
(send_nsca) qui tourne sur un hôte distant et envoi les résultats de contrôles de service à un
autre serveur. La seconde est le démon NSCA (nsca) qui fonctionne, soit comme un démon
autonome, soit sous inetd, et écoute les connections des programmes du client. Après avoir
reçu l'information de contrôle de service de la part d'un client, le démon enverra
l'information de contrôle à Nagios (sur le serveur central) en insérant une commande
PROCESS_SVC_CHECK_RESULT dans le fichier de commande externe, avec les résultats du
contrôle. La prochaine fois que Nagios contrôlera les commandes externes, il trouvera
l'information de contrôle de service passif qui avait été envoyée par le serveur distribué et
la traitera. Facile, non ?

Configuration des serveurs distribués
Bon, comment Nagios est-il configuré sur un serveur distribué ? A la base, c'est juste une
simple installation. Il n'est pas nécessaire d'installer l'interface web ou de faire envoyer des
notifications par le serveur, comme c'est le cas pour le serveur central.
Changements principaux dans la configuration :
Seuls les services et les hôtes qui sont supervisés directement par le serveur distribué sont
définis dans le fichier de configuration d'hôte .
Le serveur distribué a son paramètre enable_notifications fixé à 0. Cela évitera d'envoyer

des notifications à partir du serveur.
Le serveur distribué est configuré avec l'option de remontée de contrôle de service activée.
Le serveur distribué a une commande ocsp définie (cf. ci-dessous).
Afin que tout fonctionne ensemble de manière correcte, nous voulons que le serveur
distribué renvoie les résultats de tous les contrôles de service à Nagios. Nous pourrions
utiliser les gestionnaires d'événements pour envoyer les changements de l'état d'un service,
mais cela ne fait pas l'affaire. Afin d'obliger le serveur distribué à envoyer tous les résultats
des contrôles de service, il faut autoriser l'option de remontée de contrôle de service dans
le fichier de configuration principal et permettre qu'une commande ocsp soit lancée après
chaque contrôle de service. Nous utiliserons cette commande ocsp pour envoyer les
résultats de tous les contrôles de service au serveur central, en utilisant le client send_nsca
et le démon nsca (comme décrit ci-dessus) pour gérer la transmission.
Pour mener tout cela à bien, il faut définir la commande ocsp de cette façon :
ocsp_command=submit_check_result
La définition de la commande submit_check_result ressemble à ceci :
define command {
command_name submit_check_result
command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result
$HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
}
Le script shell submit_check_result ressemble à cela (remplacez central_server par l'adresse

IP du serveur central) :
#!/bin/sh

# Arguments:
# $1 = host_name (Short name of host that the service is
# associated with)
# $2 = svc_description (Description of the service)
# $3 = state_string (A string representing the status of
# the given service - "OK", "WARNING", "CRITICAL"
# or "UNKNOWN")
# $4 = plugin_output (A text string that should be used
# as the plugin output for the service checks)
#
# Convert the state string to the corresponding return code

return_code=-1
case "$3" in
OK)
return_code=0
;;
WARNING)
return_code=1
;;
CRITICAL)
return_code=2
;;
UNKNOWN)
return_code=-1
;;
esac
# pipe the service check info into the send_nsca program, which
# in turn transmits the data to the nsca daemon on the central
# monitoring server
/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" |

/usr/local/nagios/bin/send_nsca -H central_server -c
/usr/local/nagios/etc/send_nsca.cfg

Le script ci-dessus suppose que vous avez le programme send_nsca et son fichier de
configuration (send_nsca.cfg) placés respectivement dans les répertoires
/usr/local/nagios/bin/ et /usr/local/nagios/etc/.
C'est tout ! Nous venons de configurer avec succès un hôte distant sur lequel tourne Nagios
pour agir comme un serveur de supervision distribué. Voyons maintenant ce qui se passe
exactement avec le serveur distribué et comment il envoie des résultats de contrôle de service à
Nagios (les étapes soulignées ci-dessous correspondent aux numéros du schéma de
référence ci-dessus) :
Après que le serveur distribué a terminé l'exécution d'un contrôle de service, il exécute la
commande définie par la variable ocsp_command . Dans notre exemple, c'est le script
/usr/local/nagios/libexec/eventhandlers/submit_check_result. Remarquez que la définition
de la commande submit_check_result a envoyé quatre éléments d'information au script : le
nom de l'hôte auquel le service est associé, la description du service, le code de retour du
contrôle de service, et la sortie du plugin de contrôle du service.
Le script submit_check_result envoie dans un tube [pipe] l'information du contrôle de

service (nom de l'hôte, description, code de retour et sortie) au programme client
send_nsca.
Le programme send_nsca transmet l'information de contrôle de service au démon nsca qui

se trouve sur le serveur de supervision central.
Le démon nsca du serveur central prend l'information de contrôle de service et l'écrit dans
le fichier de commande externe pour qu'elle soit reprise ultérieurement par Nagios.
Le processus Nagios du serveur central lit le fichier de commande externe et analyse

l'information de contrôle de service provenant du serveur de supervision distribué.
Configuration du serveur central
Nous avons vu comment les serveurs de supervision distribués doivent être configurés,
occupons nous maintenant du serveur central. Pour accomplir toutes ses missions, il est
configuré de la même manière que vous configureriez un serveur seul. Il est installé de la
manière suivante :
L'interface web du serveur central est installée (optionnel, mais recommandé)
Sur le serveur central, le paramètre enable_notifications est fixée à 1. Ceci activera les
notifications (optionnel, mais recommandé)
Les contrôles de service actifs sont désactivés sur le serveur central (optionnel, mais
recommandé - voir notes ci-dessous)
Les contrôles de commandes externes sont activés sur le serveur central (obligatoire)
Les contrôles de service passifs sont activés sur le serveur central (obligatoire)
Il y a trois autres éléments importants que vous devez conserver à l'esprit en configurant le
serveur central :
Tous les services qui sont supervisés par les serveurs distribués doivent comporter des
définitions de service sur le serveur central. Nagios ignorera les résultats des contrôles de
service passifs s'ils ne correspondent pas à un service qui a été défini.
Si vous n'utilisez le serveur central que pour traiter des services dont les résultats sont
fournis par des hôtes distribués, vous pouvez simplement désactiver tous les contrôles de
service de façon globale en mettant le paramètre execute_service_checks à 0. Si vous
utilisez le serveur central pour superviser activement quelques services par lui-même (sans
l'intervention des serveurs distribués), l'option enable_active_checks de chaque définition
de service pour les services dont les résultats sont fournis par les hôtes distribués doit être
positionnée à 0. Ceci empêchera Nagios de vérifier activement ces services.
Il est important que vous désactiviez soit tous les contrôles de service pour l'ensemble du
logiciel, soit l'option enable_active_checks dans la définition de tout service surveillé par un
serveur distribué. Cela assure que les contrôles de service actifs ne sont jamais exécutés en
temps normal. Les services continueront à être ordonnancés à leur intervalle de contrôle
normal (3 minutes, 5 minutes, etc…), mais ils ne seront jamais exécutés. Cette boucle de ré-
ordonnancement continuera aussi longtemps que Nagios tourne. Je vais expliquer bientôt
pourquoi ce type de fonctionnement…
Et voilà ! Facile, non ?
Problèmes avec les contrôles passifs
Pour toutes les utilisations intensives, nous pouvons dire que le serveur central s'appuie
uniquement sur les contrôles passifs pour la supervision. Faire totalement confiance aux
contrôles passifs pour superviser pose un problème majeur : Nagios doit se fier à quelque
chose d'autre pour fournir les données supervisées. Que se passe-t-il si l'hôte distant qui
envoie les résultats s'effondre ou devient injoignable ? Si Nagios ne contrôle pas activement
les services de cet hôte, comment saura-t-il qu'il y a un problème ?
Heureusement, il y a une façon de gérer ces types de problèmes…
Le contrôle de validité des données
Nagios offre une fonctionnalité qui teste la validité des résultats d'un test (freshness
checking). On peut trouver plus d'informations à ce sujet ici. Cette fonctionnalité apporte
une solution aux situations ou les hôtes distants peuvent arrêter d'envoyer le résultat des
tests passifs au serveur central. Elle (freshness) permet d'assurer que le test est soit fourni
passivement par les serveurs distribués, soit exécuté activement par le serveur central si
nécessaire. Si les résultats fournis par le test du service deviennent figés, Nagios peut être
configuré pour forcer un contrôle actif depuis le serveur central.

Comment fait-on cela ? Sur le serveur central, il faut configurer ainsi les services qui sont
surveillés par les serveurs distribués :
L'option check_freshness dans la définition des services doit être à 1. Ceci active le test de
validité (freshness checking)
L'option freshness_threshold dans la définition des services doit être positionné à une
valeur qui indique le niveau de validité ([NdT] : la traduction littérale est la fraîcheur, mais il
ne me semble pas adapté) des données (telles que fournies par les serveurs distribués).
L'option check_command dans la définition des services doit indiquer les commandes
valides qui seront employées pour tester activement les services depuis le serveur central.
Nagios teste régulièrement la validité des résultats pour lesquels cette option est activée.
L'option freshness_threshold dans chaque service détermine le niveau de validité pour
celui-ci. Par exemple, si sa valeur est 300 pour un de vos services, Nagios va considérer que
les résultats du service sont figés s'ils ont plus de 5 minutes (300 secondes). Si vous ne
spécifiez pas la valeur de freshness_threshold, Nagios calculera un seuil à partir de la valeur
des options normal_check_interval ou de retry_check_interval (en fonction de l'état du
service). Si les résultats sont figés, Nagios exécutera la commande spécifiée dans
check_command dans la définition du service, vérifiant ainsi activement ce service.
N'oubliez pas que vous devez définir l'option check_command dans la définition des
services, pour pouvoir tester activement l'état d'un service depuis le serveur central. Dans
des conditions normales, cette commande check_command ne sera pas exécutée (parce
que les test actifs auront été désactivés globalement au niveau du programme, ou pour des
services spécifiques). A partir du moment ou le contrôle de validité des données est activé,
Nagios exécutera cette commande, même si les tests actifs ont été désactivés globalement
au niveau du programme ou pour des services spécifiques.
Si nous n'arrivez pas à définir des commandes pour tester activement un service depuis le
serveur central (ou bien cela est un casse-tête douloureux), vous pouvez simplement définir
toutes les options check_command d'après un simple script qui retourne un état critique.
Voici un exemple : supposons que vous ayez défini une commande service-fige et utilisez
cette commande dans l'option check_command de vos services. Elle pourrait ressembler à
cela …..
define command {
command_name service-fige
command_line /usr/local/nagios/libexec/check_dummy 2 "CRITICAL: Service
results are stale"
}

Quand Nagios détecte que les résultats sont figés et lance la commande service_fige, le
plugin check_dummy est exécuté et le service passe dans un état critique. Ceci déclenchera
l'envoi de notifications, donc vous saurez finalement qu'il y a un problème.
Contrôles des hôtes
Maintenant, vous savez comment obtenir des résultats de contrôles passifs depuis des
serveurs distribués. Ceci signifie que le serveur central ne teste activement que ses propres
services. Mais qu'en est-il des hôtes ? Vous en avez toujours besoin, non ?
Comme les contrôles d'hôtes n'ont qu'un impact faible sur la surveillance (ils ne sont faits
que s'ils sont vraiment nécessaires), je vous recommanderais bien de faire ces contrôles de
manière active depuis le serveur central. Ceci signifie que vous définirez le contrôle des
hôtes sur le serveur central de la même manière que vous l'avez fait sur les serveurs
distribués (également de la même manière que sur un serveur normal, non distribué).
Les résultats de contrôle passifs des hôtes sont disponible (lisez ceci), donc vous pourriez les
utiliser dans votre architecture distribuée mais cette méthode comporte certains
problèmes. Le principal étant que Nagios ne traduit pas les états problèmes (arrêtés DOWN
ou injoignables UNREACHABLE) retournés par les vérifications passives des hôtes quand ils
sont traités. Par conséquent, si vos serveurs de supervision ont une structure différentes en
terme de parents ou enfants (et c'est ce qui se passe lorsque vos serveurs de supervisions
ne sont pas exactement au même endroit), le serveur central va avoir une vision incorrecte
des états des hôtes.
Si vous voulez vraiment envoyer des résultats passifs de contrôle d'hôte à un serveur de
supervision central, vérifiez que :
La réception passive de vérification d'hôte (requis) est activée sur le serveur central
Le serveur distribué est configuré avec l'option de remontée de contrôle d'hôte activée.
Le serveur distribué a une commande ochp définie.
La commande ochp utilisée pour le traitement des vérifications d'hôtes fonctionne de

manière similaire à la commande ocsp utilisée pour le traitement des vérification des
services (cf documentation ci-dessus). Pour être sûr que les vérifications passives d'hôtes
sont valides et à jour, il est nécessaire d'activer la validité des vérification pour les hôtes de
la même manière que pour les services.

Nagios

Transféré par

Droits d'auteur :

Formats disponibles

Nagios

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Nagios

Transféré par

Droits d'auteur :

Formats disponibles

v 1.

 BE Nagios : Etude de la logique de supervision dans Nagios 3. Juillet 2011

M. T. Ait Messaoud| Administration et supervision sous Nagios

M. T. Ait Messaoud| Administration et supervision sous Nagios

La supervision a deux objectifs principaux :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 1

La supervision est un vaste domaine de l'informatique qui inclut plusieurs activités:

Autour de la supervision, plusieurs modules coexistent:

 La supervision réseau s'occupe de composants matériel tels que serveur, imprimante,

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 2

o Les systèmes de management de réseaux :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 3

o Les commandes SNMP :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 4

 Définition des ressources à surveiller :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 5

Atouts de Nagios par rapport aux autres outils open source :

Zabbix : la supervision simplement

Cacti : la métrologie avec SNMP

Ganglia : la métrologie des clusters

Zenoss : très bonne supervision, mais pas complètement libre

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 7

 CGI (Common Gateway Interface) :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 8

2.3 Les modes de supervision :

2.3.1 Les contrôles actifs :

Obtention sans rebond

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 9

2.3.2 Les contrôles passifs :

2.4 Rôle des agents :

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 10

Fichier de configuration principal

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 11

Définition d’une commande dans nrpe.cfg

Voici la même commande, mais en utilisant des arguments variables :

Définition avec arguments

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 12

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 13

Lancement d’une commande par SSH

Déploiement de clés sur un compte distant

Utilisation de SSH à la place de NRPE

Le protocole SNMP et les OID

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 15

Exemple d’interrogation SNMP

Récupération de la charge CPU par SNMP

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 16

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 17

Configuration des modules

2.5 Types d’état SOFT et HARD :

Exemple de changement de type d’état

Exemple de paramétrage d’un service

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 19

Nous pouvons observer cela sur le diagramme de la figure précédente.

Un état SOFT un peu particulier : SOFT-RECOVERY

Notifications : le but des types d’état SOFT et HARD

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 20

M. T. Ait Messaoud| Administration et supervision sous Nagios Page 21

Notifications : la configuration des contacts prime

Si nous avons un service défini comme :

2.6 Données à définir dans Nagios :