Fichiers de Configuration Nagios Résumé

v 1.
3 Janvier 2017
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 : .................................................................................................................................................. 8
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 : ........................................................................................................................................... 11
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 : ......................................................................................................................... 19
2.6 Données à définir dans Nagios : .................................................................................................................... 23
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 : ......................................................................................................................................... 27
2.6.6 Les contacts : ......................................................................................................................................... 28
2.6.7 Groupe de contacts : ............................................................................................................................. 29
2.6.8 Durée et fréquence des checks : ........................................................................................................... 30
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
5 Nagios : Les notions avancées .............................................................................................................................. 79
5.1 Les escalades................................................................................................................................................. 79
5.2 Les performances (haute disponibilité, nagios distribué) ............................................................................. 79
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
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
for usage and examples.
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 Etude 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 {
service_description HTTP
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 escalades
5.2 Les performances (haute disponibilité, nagios distribué)

Fichiers de Configuration Nagios Résumé

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

Fichiers de Configuration Nagios Résumé

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,

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

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

OpenNMS : la supervision très 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 :

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

Obtention avec rebond

2.3.2 Les contrôles passifs :

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

Inclusion du fichier spécifique au serveur

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

Lancement d’une commande par SSH

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

Déploiement de clés sur un compte distant

Utilisation de SSH à la place de NRPE

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 17

Configuration des modules

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

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

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

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

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 :

lors de la levée de la notification de recovery (option r), le contact ne reçoit pas

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

Définition d’un objet type

2.6.1 Arguments, macros et variables d’environnement :