I. Introduction▲
Ce tutoriel n'a pas pour vocation de vous apprendre à installer Nagios. Pour cela, veuillez lire mon précédent article sur le sujet : Installation et configuration de Nagios pour débutants - Apprendre par l'exemple.
Superviser un parc informatique dans tous ses recoins est infini et je n'ai pas la prétention de vous montrer comment le faire. C'est juste un partage d'expérience qui vous permettra de gagner du temps par rapport aux différentes questions que l'on peut se poser et de pouvoir y répondre facilement.
II. Qu'est-ce qu'un service ?▲
Dans cet article, je ferai un abus de langage en utilisant le mot « service ». Surveiller un service revient à surveiller qu'une machine est joignable, vérifier depuis combien de temps elle est en fonctionnement, surveiller que notre DHCP ou DNS fonctionne, vérifier l'espace disque de nos serveurs, vérifier qu'ils sont à l'heure, vérifier la mémoire RAM…
Ce tutoriel contient une liste de services que nous surveillons (sur des machines Windows, Linux ou des Switches). Vous y trouverez le plugin utilisé pour ce faire et quelques explications.
Comme je vous l'ai dit ci-dessus, cette liste est non exhaustive et a pour but de vous montrer les services que j'avais besoin de surveiller en priorité. Si vous souhaitez faire des commentaires, propositions ou corrections, n'hésitez pas : 10 commentaires .
III. Prérequis▲
Afin de partir sur de bonnes bases, je vous recommande sur tous vos serveurs Windows, Linux et Mac d'installer les outils ci-dessous.
III-A. Perl▲
Les plugins par défaut de Nagios ne permettent pas de superviser tout ce que l'on veut. Nous serons amenés de ce fait à soit télécharger de nouveaux plugins, soit à en développer nous-mêmes.
Beaucoup de ces programmes sont développés en Perl. Il est donc nécessaire d'installer Perl et certains de ses modules dont nous pourrions avoir besoin, notamment les modules Monitoring::Plugin et Net::SNMP.
Sous Linux/Mac, Perl est déjà installé. Sous Windows, ce n'est pas le cas. Installez-le si besoin.
Sous Debian, il est possible de passer par les paquets de la distribution pour installer les modules :
apt-get install libnagios-plugin-perl libnet-snmp-perl
Pour les autres distributions, un autre moyen simple, si vous n'avez pas de paquets, c'est d'utiliser l'utilitaire cpan déjà présent en « root » ou « sudo » :
cpan -i Monitoring::Plugin Net::SNMP
Si vous rencontrez des soucis, voici une documentation pouvant vous aider : Installation des modules Perl CPAN. Et si cela ne suffit point, le forum Perl est à votre disposition.
III-B. SNMP▲
Pour obtenir certaines informations sur vos serveurs ou équipements réseau comme les switches, parfois, le seul moyen est d'utiliser SNMP. De ce fait, autant de suite l'installer ou l'activer sur le matériel à superviser.
En ce qui concerne les serveurs comme Debian, voici les paquets à installer :
apt-get install snmp snmpd snmp-mibs-downloader
Vous aurez ensuite besoin de configurer SNMP afin de permettre au serveur de supervision d'interroger votre serveur. Ouvrez le fichier « /etc/snmp/snmpd.conf ».
Voici quelques modifications à faire.
Le fichier de configuration a évolué avec les versions récentes de Debian.
Voici les changements avant et après la version 5 de Debian :
# sec.name source community
# com2sec paranoid default public
com2sec readonly default public
#com2sec readwrite default private
agentAddress udp:161
rocommunity public <IP ou NOM DNS serveur de supervision>
Vous pouvez bien sûr n'autoriser qu'une surveillance en local en mettant 127.0.0.1 ou localhost.
/etc/init.d/snmpd restart
Petit test local :
snmpwalk -c public -v 1 localhost | more
Pour approfondir vos connaissances sur SNMP, je vous conseille les deux articles suivants :
IV. Rappels Nagios▲
Nagios est un moniteur de supervision qui nous alerte de toutes pannes ou anomalies rencontrées sur les serveurs ou tous équipements réseau que nous surveillons. Cette surveillance se fait à l'aide d'agents installés sur ces équipements. Dans ce tutoriel, nous allons surveiller certains services et utiliser certains agents.
IV-A. Sous Windows▲
L'agent utilisé est l'un des plus répandus : « NSClient++ ».
Il est dédié à l'environnement Windows et joue trois rôles essentiels :
- agent de supervision ;
- fonction de transport NRPE ;
- fonction de transport NSCA.
Dans ce tutoriel, nous utiliserons deux modes de fonctionnement de NSClient sur les trois existant.
IV-A-1. Mode nsclient▲
Historiquement, c'est le premier mode de NSClient++ à sa création. En fait, il existait un agent nommé « nsclient » qui était interrogé via le plugin standard « check_nt » de Nagios(1). Pour configurer ce mode (comme les autres), tout se fait dans le fichier de configuration NSC.ini dans la section [NSClient] ou [Settings]. Pour en savoir plus, lisez la documentation d'installation de Nagios.
À travers ce mode et le plugin « check_nt », nous avons la possibilité de surveiller facilement plusieurs services sous Windows (Version NSClient++, CPU, Uptime, espace disque, mémoire, services Windows, nombre d'utilisateurs…). On l'utilise tout au long de cet article.
IV-A-2. Mode NRPE▲
Le mode NRPE a un très grand avantage, car il permet à l'administrateur de développer des plugins en divers langages (Visual Basics, Perl…) et de les déposer sur les machines à superviser. Ainsi, ils seront lancés par l'agent à travers ce mode après réception de la demande du serveur Nagios. Le mode NRPE de Nagios permet aussi d'interroger les différents modules de NSClient++ et d'encrypter les échanges.
Pour utiliser ce mode depuis le serveur Nagios, on utilise le plugin « check_nrpe ». On l'utilise dans ce tutoriel, surtout pour surveiller des machines Linux.
IV-A-3. Mode NSCA▲
Ce mode utilise le protocole NSCA que nous n'utiliserons pas dans ce tutoriel.
IV-B. Sous Linux▲
Nous utiliserons la plupart du temps le protocole NRPE pour échanger avec les serveurs surveillés et y lancer des programmes locaux via le plugin « check_nrpe ». Parfois, nous utiliserons SNMP soit via le plugin Nagios « check_snmp » ou via des plugins personnels SNMP.
IV-C. Équipements réseau (switches…)▲
Le seul moyen de superviser ces équipements est d'utiliser SNMP. Il faudra juste s'assurer qu'il est bien activé. Le plugin Nagios « check_snmp » ou des plugins personnels SNMP seront nécessaires.
IV-D. Généralité▲
Dans tous les cas, il sera nécessaire sur le serveur de supervision de modifier ou non le fichier « /usr/local/nagios/etc/objects/commande.cfg » afin de créer une nouvelle commande. C'est souvent le cas pour de nouveaux plugins utilisant SNMP.
Lorsque la communication se fait via NRPE, il est nécessaire de faire une modification dans le fichier « /usr/local/nagios/etc/nrpe.cfg » sur le serveur Linux à surveiller pour configurer la ligne de commande.
Une fois ces améliorations apportées, il ne reste plus qu'à définir ses services pour chaque serveur et matériel à superviser. Vous verrez dans les exemples ci-dessous différentes écritures pour faire passer les arguments. Soyez attentif !
Je vous recommande un peu de lecture pour en savoir plus sur Nagios, NSClient++…
V. Services à surveiller▲
V-A. Version NSCLIENT++▲
Nous supervisons des machines Windows et nous avons besoin d'être sûrs qu'elles utilisent toutes la même version de l'agent NSCLIENT++.
C'est un choix personnel d'uniformiser les versions d'agents utilisés au sein d'un même parc informatique. Cela permet de minimiser des erreurs d'incompatibilités ou des soucis de maintenance.
C'est assez simple à mettre en place, car par défaut, c'est dans la configuration de base de Nagios. Tout se fait via « check_nt ».
Dans le fichier de configuration du serveur (fichier .cfg), voici le service à déclarer :
# Version NSCLIENT
define service {
use generic-service
host-name SERVEURWINDOWS
service_description Version NSCLIENT++
check_command check_nt!CLIENTVERSION
}
Nagios affichera la version de votre client NSCLIENT++ du serveur Windows. Ce qui peut être intéressant, c'est de s'assurer que nos machines Windows ont la même version de l'agent. Pour cela, « check_nt » dispose d'une option « -l » pour sa variable CLIENTVERSION où l'on précise la version. Ainsi, si la requête n'a pas exactement la même réponse, vous aurez un warning dans Nagios.
# Version NSCLIENT
define service {
use generic-service
host-name SERVEURWINDOWS
service_description Version NSCLIENT++
check_command check_nt!CLIENTVERSION!-l "NSCLIENT++ 0.3.9.327 2011-08-16"
}
Sur la ligne check_command, on demande à Nagios d'utiliser le plugin « check_nt » avec deux arguments (« ! » est un séparateur d'arguments). Le premier argument est la variable et le deuxième la valeur à tester.
Maintenant, vous saurez si vos machines Windows ont cette version de NSCLIENT++ ou non.
Pour effectuer le test en ligne de commande,
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v CLIENTVERSION -s MOTDEPASSE -p 12489 -l "NSCLIENT++ 0.1.1"
Mauvaise version du client utilisée: NSCLIENT++ 0.3.9.327 2011-08-16, nécessaire: NSCLIENT++ 0.1.1
Vous voyez ci-dessus un exemple de résultat en cas de résultat négatif.
V-B. Espace disque▲
La surveillance de l'espace disque de vos serveurs est primordiale et Nagios a déjà tout prévu.
V-B-1. Windows▲
Nous utilisons « check_nt » avec la variable « USEDDISKSPACE ».
En ligne de commande, depuis votre serveur « supervision », voici la commande à lancer :
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v USEDDISKSPACE -s MOTDEPASSE -p 12489 -l C -w 80 -c 90 -u GB
C:\ - total: 30,01 Gb - utilisé: 19,75 Gb (66%) - libre 10,25 Gb (34%) | 'C:\ Espace Utilisé'=19,75Gb;24,00;27,01;0.00;30,01
Explication des options de la commande :
- -H : préciser le serveur Windows à superviser ;
- -v : variable pour « check_nt ». On utilise USEDDISKSPACE pour vérifier l'espace disque ;
- -s : mot de passe configuré dans NSCLIENT++ de la machine Windows ;
- -p : port par défaut ;
- -l : pour passer les arguments :
- C : lecteur disque à surveiller ;
- -w 80 : au-dessus de 80 % d'occupation, Nagios émet un Warning ;
- -c 90 : au-dessus de 90 % d'occupation, Nagios émet une alerte critique ;
- -u GB : permet juste de forcer un affichage avec la taille en GB.
Dans le fichier de configuration du serveur (fichier .cfg), voici le service à déclarer :
# Espace disque
define service{
use generic-service
host_name SERVEURWINDOWS
service_description C:\ Espace Disque
check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90 -u GB
}
Le mot de passe NSCLIENT++ n'est pas renseigné, car il l'est déjà dans le fichier « /usr/local/nagios/etc/objects/commands.cfg » comme expliqué dans la documentation d'installation de Nagios.
V-B-2. Linux▲
Nous utilisons « check_nrpe » et « check_disk ».
En ligne de commande, depuis votre serveur « supervision », voici la commande à lancer :
root@supervision:/usr/local/nagios/etc#/usr/local/nagios/libexec/check_nrpe -H SERVEURLINUX -c check_disk -a 20% 10% /
DISK OK - free space: / 38858 MB (84% inode=94%);| /=6993MB;38644;43474;0;48305
La partition « / » est vérifiée et si le pourcentage d'espace disque restant est inférieur à 20 %, on a un warning et une alerte critique si inférieur à 10 %. En ligne de commande, l'option « -c » permet de spécifier le programme distant à lancer. L'option « -a » permet de passer les arguments.
# Vérification de l'espace disque
define service{
use generic-service
host_name SERVEURLINUX
service_description Espace disque /
check_command check_nrpe!check_disk!20%!10%!/
}
« ! » est un séparateur d'arguments.
V-C. CPU▲
Il est possible de vérifier la charge moyenne système durant les x dernières minutes. Tout est déjà présent dans Nagios par défaut.
V-C-1. Windows▲
# Charge CPU
define service{
use generic-service
host_name SERVEURWINDOWS
service_description CPU Load
check_command check_nt!CPULOAD!-l 5,80,90
}
La vérification sera faite pour les cinq dernières minutes avec une limite entre 80 % et 90 % de charge CPU.
V-C-2. Linux▲
C'est un peu particulier. En fait, la charge CPU s'exprime normalement sans unité et correspond au nombre de processus en train d'utiliser le ou les processeurs de la machine.
Les utilitaires comme « uptime » ou « top » donnent cette information sous forme de trois valeurs inférieures à 1. Exemple : 0.15, 0.20 et 0.17.
Ces valeurs représentent la charge moyenne au cours de la dernière, des cinq et quinze dernières minutes.
Il faut considérer une machine chargée si la valeur est supérieure à « 1 » pour un serveur monoprocesseur ou « 2 » pour un biprocesseur…
# Vérification de la charge CPU
define service{
use generic-service
host_name SERVEURLINUX
service_description Charge CPU
check_command check_nrpe!check_load!0.7,0.6,0.5!0.9,0.8,0.7
}
Voici une explication de notre service : un warning est émis par Nagios si la charge CPU excède 70 %, 60 %, 50 % de charge CPU les 1, 5 et 15 dernières minutes. Puis, une alerte critique au-delà de 90 %, 80 % et 70 % les 1, 5 et 15 dernières minutes.
V-D. Mémoire RAM▲
V-D-1. Windows▲
La vérification de la mémoire RAM est possible depuis Nagios et le plugin de vérification est déjà présent pour la surveillance des machines sous Windows. Voici un exemple de ligne de commande à lancer depuis votre serveur « supervision » :
root@supervision:# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v MEMUSE -s MOTDEPASSE -p 12489 -w 80 -c 90
Mémoire utilisée: total:2168,51 Mb - utilisée: 466,13 Mb (21%) - libre: 1702,39 Mb (79%) | 'Mémoire utilisée'=466,13Mb;0,00;0,00;0.00;2168,51
Cette commande demande au serveur Windows à travers NSCLIENT++ de vérifier la consommation de la RAM (variable MEMUSE de check_nt), de retourner une alerte (warning) si l'utilisation dépasse 80 % ou une alerte critique si elle dépasse 90 %. Pour Nagios, voici la configuration du service :
# Mémoire RAM
define service{
use generic-service
host_name SERVEURWINDOWS
service_description Mémoire utilisée
check_command check_nt!MEMUSE!-w 80 -c 90
}
V-D-2. Linux▲
Il n'y a pas de plugin installé par défaut sur Nagios pour surveiller la mémoire RAM. Pour ce faire, il va falloir soit développer son propre plugin, soit en trouver un sur la toile comme expliqué iciRappels Nagios.
En ce qui me concerne, pour la gestion de la mémoire, j'ai créé mon propre plugin que j'ai nommé « check_memory.pl ». Ce dernier fonctionne sous Linux, Mac et sous Windows, mais je ne l'utilise que sous Linux :
Ce programme permet de vérifier la mémoire RAM ou la mémoire Swap. Il faut le déposer dans le répertoire « /usr/local/nagios/libexec/ » du serveur Linux à superviser. Rendez-le exécutable.
chmod +x check_memory.pl
Ce programme n'est fonctionnel que si les modules Perl suivants sont installés sur le serveur :
cpan -
i Monitoring::Plugin Sys::MemInfo
Vous pouvez tester le programme sur le serveur en ligne de commande :
# /usr/local/nagios/libexec/check_memory.pl -v -w 85 -c 95 -M mem
totalmem : 2124271616
freeswap : 2221649920
totalswap : 2222977024
freemem : 354693120
Check memory OK - Total Memory : 2025.86MB - Mem used : 83.30%
# /usr/local/nagios/libexec/check_memory.pl -w 10 -c 20 -M swap
Check memory OK - Total Memory Swap : 2120.00MB - Swap used : 0.06%
Il faut maintenant configurer NRPE du serveur à superviser pour que ce programme puisse être interrogé à distance.
# vi /usr/local/nagios/etc/nrpe.cfg
…
…
command[check_memory]=/usr/local/nagios/libexec/check_memory.pl -w $ARG1$ -c $ARG2$ -M $ARG3$
Les trois arguments sont obligatoires pour notre programme.
Faisons un test en ligne de commande pour utiliser NRPE en local sur le serveur à superviser et depuis le serveur Nagios.
# /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_memory -a 80 90 swap
Check memory OK - Total Memory Swap : 2120.00MB - Swap used : 0.06%
root@supervision:~# /usr/local/nagios/libexec/check_nrpe -H SERVEURLINUX -c check_memory -a 80 90 mem
Check memory WARNING - Total Memory : 2025.86MB - Mem used : 82.73%
Tout fonctionne correctement !
Créons donc le service sur le serveur « supervision » pour que Nagios puisse surveiller la mémoire comme un grand !
# Mémoire RAM
define service{
use generic-service
host_name SERVEURLINUX
service_description Mémoire RAM
check_command check_nrpe!check_memory!90!95!mem
}
# SWAP
define service{
use generic-service
host_name SERVEURLINUX
service_description Mémoire Swap
check_command check_nrpe!check_memory!10!20!swap
}
V-E. Uptime▲
Le terme « uptime » correspond au temps depuis lequel une machine est en fonctionnement. Le redémarrage de celle-ci réinitialise ce temps à zéro. De mon avis personnel, il peut être intéressant de savoir depuis combien de temps un serveur n'a pas été redémarré et de générer une alerte au bout d'un certain temps (un mois ou deux). Redémarrer un serveur peut permettre de vider la mémoire RAM, les caches, de faire une vérification de disques…
V-E-1. Windows▲
Via « check_nt » et « NSCLIENT++ », il est possible d'avoir l'uptime. Malheureusement, nous n'avons pas la possibilité d'obtenir une alerte à partir d'un seuil défini, car NSClient++ ne donne uniquement que cette durée et ne fait aucune comparaison, donc n'envoie aucune alerte de type warning ou critique à Nagios. Pourtant, nous souhaitons avoir une alerte en fonction du temps écoulé, ainsi, check_nt ne nous aide pas.
Il existe un plugin « CheckUpTime » déjà disponible dans NSCLIENT++ qu'il faudra interroger par « NRPE ». Mais, pour utiliser NRPE à travers NSCLIENT++, il faut l'activer. Sous le PC Windows, dans le fichier de configuration NSC.ini, dans la section [NRPE], il faudra décocher la ligne :
;allow_arguments=0
Nous devons avoir :
allow_arguments
=
1
Penser à redémarrer le service NSCLIENT++.
Maintenant, nous pouvons depuis notre serveur « supervision » lancer une requête.
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v UPTIME -p 12489 -s MOTDEPASSE
Système démarré - 9 jour(s) 5 heure(s) 10 minute(s)
Maintenant, utilisons « CheckUpTime » pour émettre un warning au-dessus de huit jours et critical au-dessus de dix jours :
root@supervision:~# /usr/local/nagios/libexec/check_nrpe -H SERVEURWINDOWS -c CheckUpTime -a MaxCrit=10d MaxWarn=8d
WARNING: uptime: 1w 2d 5:28 > warning|'uptime'=797289000;777600000;864000000
Le choix du seuil de huit à dix jours est personnel et à titre d'exemple pour ce tutoriel. Ce n'est en aucun cas une règle !
Tout fonctionne bien, configurons le service sous Nagios :
# Temps de fonctionnement du système
define service{
use generic-service
host_name SERVEURWINDOWS
service_description Vérification Uptime
check_command check_nrpe!CheckUpTime!MaxCrit=60d MaxWarn=30d
}
Pour en savoir plus sur toutes les options de « CheckUpTime », n'hésitez pas à consulter le site officiel de NSCLient++.
V-E-2. Linux▲
Il n'existe pas de plugin par défaut pour gérer l'uptime, il faut donc le concevoir soi-même ou en trouver un sur la toile.
Je vous propose un plugin que j'ai conçu dont le fonctionnement est le suivant : le programme installé sur le serveur client va récupérer l'uptime dans le fichier « /proc/uptime ». Ensuite, à partir du nombre de secondes, il va donner la possibilité de gérer les seuils d'alerte et de proposer un affichage personnalisé.
Nous aurions pu utiliser l'utilitaire « uptime » déjà présent sur le système puis parser son résultat, mais ce dernier formate déjà le temps, or nous avons besoin de gérer les seuils.
Voici le programme :
Ce programme doit être déposé dans le répertoire « /usr/local/nagios/libexec ». Rendez-le exécutable.
chmod +x check_uptime.pl
Ce programme ne sera fonctionnel que si le module Perl suivant est installé sur le serveur :
cpan -i Monitoring::Plugin
Vous pouvez tester le programme sur le serveur en ligne de commande :
root@SERVEURLINUX:~# /usr/local/nagios/libexec/check_uptime.pl -w 30 -c 60
Check uptime WARNING - Uptime - 1 month 11 days 5 hours 36 minutes 21 secondes
Il faut maintenant configurer NRPE sur le serveur à superviser pour que ce programme puisse être interrogé à distance.
# vi /usr/local/nagios/etc/nrpe.cfg
…
…
command[check_uptime]=/usr/local/nagios/libexec/check_uptime.pl -w $ARG1$ -c $ARG2$
Les deux arguments sont obligatoires pour notre programme.
Faisons un test en ligne de commande pour utiliser NRPE en local sur le serveur à superviser et depuis le serveur Nagios.
# /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_uptime -a 30 60
Check uptime WARNING - Uptime - 1 month 11 days 5 hours 45 minutes 59 secondes
root@supervision:~# /usr/local/nagios/libexec/check_nrpe -H SERVEURLINUX -c check_uptime -a 30 60
Check uptime WARNING - Uptime - 1 month 11 days 5 hours 47 minutes 34 secondes
Tout fonctionne correctement !
Créons le service sur le serveur « supervision » pour que Nagios puisse surveiller l'uptime !
# Vérification Uptime
define service{
use generic-service
host_name SERVEURLINUX
service_description Vérification Uptime
check_command check_nrpe!check_uptime!30!60
}
V-F. Vérifier des processus et services (Windows)▲
Sur certains serveurs, vous avez souvent des applications métier ou du moins des logiciels importants qui doivent absolument fonctionner. Le seul moyen est, bien souvent, de vérifier manuellement qu'un processus, qu'un service Windows est bien en fonctionnement (ps -aux sous Linux, services sous Windows). Avec Nagios, il est possible de s'en assurer de manière automatique.
V-F-1. Windows▲
Les variables PROCSTATE et SERVICESTATE nous permettent de vérifier qu'un processus et qu'un service Windows fonctionnent.
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489
Pas de service/processus spécifié
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l toto
toto: not running
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l explorer.exe
Explorer.EXE: Running
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -l explorer.exe
OK: All processes are running.
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -l toto
toto: not running
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -l explorer.exe,mysql.exe
mysql.exe: not running
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v PROCSTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l explorer.exe,mysql.exe
Explorer.EXE: Running - mysql.exe: not running
On comprend rapidement qu'il est simple de vérifier qu'un processus tourne ou non. L'option « -d SHOWALL » permet d'affiner l'affichage du résultat.
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v SERVICESTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l "wuauserv" wuauserv: Started
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v SERVICESTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l "OCS Inventory Service"
OCS Inventory Service: Started
root@supervision:~# /usr/local/nagios/libexec/check_nt -H SERVEURWINDOWS -v SERVICESTATE -s MOTDEPASSE -p 12489 -d SHOWALL -l "toto"
toto: Not found
De la même manière que PROCSTATE, la vérification est simple.
On renseigne le nom du service (nom logique) et non le « nom complet » du service (nom localisé(2)). Voici une image montrant la propriété du service de mises à jour de Windows. On distingue bien le « Nom du service » et le « Nom complet » de ce dernier.
Pour Nagios, voici la configuration du service :
define service{
use generic-service
host_name SERVEURWINDOWS
service_description Explorer
check_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe
}
define service{
use generic-service
host_name SERVEURWINDOWS
service_description MySQL
check_command check_nt!SERVICESTATE!-d SHOWALL -l "MySQL"
}
V-F-2. Linux▲
Il n'y a pas de plugin installé par défaut sur Nagios. Créons un nouveau plugin que voici :
Ce programme doit être déposé dans le répertoire « /usr/local/nagios/libexec ». Rendez-le exécutable.
chmod +x check_process.pl
Ce programme ne sera fonctionnel que si les modules Perl suivants sont installés sur le serveur :
cpan -i Monitoring::Plugin Proc::ProcessTable
Vous pouvez tester le programme sur le serveur en ligne de commande :
root@SERVEURLINUX:~# /usr/local/nagios/libexec/check_process.pl -n mysqld
Check process OK - Process mysqld (3159) state (sleep)
Il faut maintenant configurer NRPE sur le serveur Linux distant pour que ce programme puisse être interrogé à distance depuis « supervision ».
# vi /usr/local/nagios/etc/nrpe.cfg
…
…
command[check_process]=/usr/local/nagios/libexec/check_process.pl -n $ARG1$
L'argument « -n » est obligatoire pour notre programme. On ne tient pas compte de l'autre option.
Faisons un test en ligne de commande pour utiliser NRPE en local sur le serveur à superviser et depuis le serveur Nagios.
root@supervision:~# /usr/local/nagios/libexec/check_nrpe -H SERVERULINUX -c check_process -a mysqld
Check process OK - Process mysqld (3159) state (sleep)
Tout fonctionne correctement !
Créons donc le service sur le serveur « supervision » pour que Nagios puisse surveiller le service MySQL !
define service{
use generic-service
host_name SERVERULINUX
service_description Check MySQL
check_command check_nrpe!check_process_ah!mysqld
}
V-G. DHCP▲
Le plugin « check_dhcp » disponible par défaut dans Nagios nous permet de vérifier le bon fonctionnement du serveur DCHP de notre réseau. Le but est de fournir au plugin une adresse MAC et une adresse IP attendue par rapport à la configuration de votre DHCP.
Voici un exemple en ligne de commande :
root@supervision:~# /usr/local/nagios/libexec/check_dhcp -s SERVEURDNS -m 00:24:81:86:91:24 -r 192.168.200.86
OK: Reçu 2 DHCPOFFER(s), 1 de 1 serveurs ont répondu, l'adresse demandée (192.168.200.86) été offerte, bail maximum = 864000 sec.
root@supervision:~# /usr/local/nagios/libexec/check_dhcp -s SERVEURDNS -m 00:24:81:86:91:24 -r 192.168.200.100
WARNING: Reçu 2 DHCPOFFER(s), 1 de 1 serveurs ont répondu, l'adresse demandée (192.168.200.100) n'a pas été offerte, bail maximum = 864000 sec.
Créons notre service :
define service{
use generic-service
host_name supervision
service_description DHCP - primaire SERVEURDHCP
check_command check_dhcp!SERVEURDHCP!00-24-81-86-91-24!192.168.200.86
}
V-H. DNS▲
Les plugins « check_dns » et « check_dig » disponibles par défaut dans Nagios nous permettent de vérifier le bon fonctionnement du serveur DNS de notre réseau.
- « check_dns »
Il permet de vérifier la résolution de nom IP → Nom et inversement. Il s'appuie sur l'utilisation de « nslookup ».
Les commandes ci-dessus interrogent le serveur DNS de notre choix en lui soumettant un nom de serveur (serveur1, serveur2). L'option « -a » renseigne l'adresse IP attendue. Nous imposons un seuil de réponse entre une et deux secondes au-delà duquel, une alerte est envoyée.check_dnsSélectionnezroot@supervision:~# /usr/local/nagios/libexec/check_dns -s SERVEURDNS -H serveur1 -a 192.168.200.86 -w 1 -c 2 DNS CRITIQUE - j'attendais '192.168.200.86' mais j'ai reçu '192.168.200.40' root@supervision:~# /usr/local/nagios/libexec/check_dns -s SERVEURDNS -H serveur2 -a 192.168.200.86 -w 1 -c 2 DNS OK: 0,009 secondes de temps de réponse . do renvoie 192.168.200.86|time=0,009132s;;;0,000000 root@supervision:~# /usr/local/nagios/libexec/check_dns -s SERVEURDNSFAUX -H serveur2 -a 192.168.200.86 -w 1 -c 2 check_dns: Adresse/Nom invalide - SERVEURDNSFAUX
Service Nagios DNSSélectionnezdefine service{ use generic-service host_name supervision service_description DNS check_command check_dns!SERVEURDNS!SERVEURATESTER!IP-ATTENDUE }
- « check_dig »
Il permet de vérifier le comportement du serveur DNS en s'appuyant sur la commande « dig ». Dans notre cas, nous n'en avons pas besoin.
V-I. Date du serveur (NTP)▲
Il est important d'avoir sur son réseau un serveur NTP sur lequel vos serveurs critiques ou non se synchronisent. Par la suite, pour s'assurer qu'il n'y ait pas un décalage de temps entre vos serveurs et votre NTP ou un NTP extérieur, nous allons faire vérifier cela avec Nagios.
Sous Windows, je n'ai pas trouvé de plugin présent par défaut et sous Linux, il en existe un : « check_ntp_time ».
V-I-1. Windows▲
J'ai créé un plugin très simple en Perl qui permet de vérifier le décalage de temps existant entre l'horloge locale et le serveur de temps défini. La contrainte pour l'utiliser est qu'il faut installer Perl sur votre serveur Windows et ensuite les deux modules Perl : Monitoring::Plugin et Net::NTP.
cpan -
i Monitoring::Plugin Net::NTP
Voici le programme :
Ce programme est portable, ce qui veut dire qu'il fonctionne également sous les autres systèmes d'exploitation. Mais nous nous contentons de l'utiliser uniquement sous Windows étant donné qu'un plugin existe déjà sous Linux. Déposons ce programme dans le répertoire « C:\Program Files\NSCLIENT++\scripts » et testons-le en ligne de commande :
C:\Program Files\NSCLIENT++\scripts>perl check_ntp.pl -H SERVEURNTP -w 1 -c 2
Check NTP OK - Offset 0.570322 secs|offset=0.570322s;0.000000;0.000000;
Le but est maintenant de pouvoir interroger ce plugin depuis le serveur Nagios. Pour ce faire, il faut quelques modifications dans le fichier « NSC.ini » de NSCLIENT++.
Dans la section [modules], il faut décommenter les lignes :
NRPEListener.dll
CheckExternalScripts.dll
Dans les sections [NRPE] et [External Script], il nous faut cette ligne pour activer les arguments :
allow_arguments
=
1
Dans la section [External Scripts] (attention : Il y a un « s »), on définit la commande du plugin appelée via NRPE par Nagios :
check_ntp
=
C:\Perl\bin\perl.exe scripts\check_ntp.pl -H $ARG1$ -w $ARG2$ -c $ARG3$
Nous lançons notre plugin Perl en précisant le chemin de l'exécutable Perl (c'est obligatoire), puis en précisant que le plugin est dans le répertoire « scripts ». Puis dans notre cas, Nagios doit passer trois arguments (serveur NTP et les seuils).
Une fois cette configuration faite, vous relancez le service NCSClient++ et faites un test en ligne de commande depuis le serveur Nagios :
root@supervision:~# /usr/local/nagios/libexec/check_nrpe -H SERVEURWINDOWS -c check_ntp -a SERVEURNTP 1 2
Check NTP WARNING - Offset 1.693763 secs|offset=1.693763s;1.000000;2.000000;
Parfait, nous pouvons configurer le service Nagios.
# Verification NTP
define service{
use generic-service
host_name SERVEURWINDOWS
service_description Date du serveur
check_command check_nrpe!check_ntp!SERVEURNTP!1!2
}
V-I-2. Linux▲
Rien de bien compliqué. Comme nous l'avons fait pour les autres plugins, par défaut sous Nagios, il suffit d'utiliser « check_nrpe » et « check_ntp_time ». Voici le service à configurer :
# Verification NTP
define service{
use generic-service
host_name SERVEURLINUX
service_description Date du serveur
check_command check_nrpe!check_ntp_time!SERVEURNTP!1!2
}
V-J. Mise à jour d'une Debian▲
Si votre parc informatique contient plusieurs serveurs sous Linux, il est utile de s'assurer que ces derniers soient régulièrement à jour. Cela se fait via l'utilisation de l'utilitaire « apt-get ».
Il est donc recommandé de faire régulièrement un apt-get update, apt-get upgrade afin de voir les mises à jour disponibles (logiciels, systèmes…).
Nagios dispose d'un plugin par défaut installé : « check_apt ».
# /usr/local/nagios/libexec/check_apt
APT CRITICAL: 3 packages available for upgrade (3 critical updates). |available_upgrades=3;;;0 critical_updates=3;;;0
# /usr/local/nagios/libexec/check_apt -u
CRITICAL - Plugin timed out after 10 seconds
# /usr/local/nagios/libexec/check_apt -u -t 20
CRITICAL - Plugin timed out after 10 seconds
# /usr/local/nagios/libexec/check_apt -u -t 30
'/usr/bin/apt-get -q update' exited with non-zero status.
APT CRITICAL: 3 packages available for upgrade (3 critical updates). warnings detected, errors detected. run with -v for information.|available_upgrades=3;;;0 critical_updates=3;;;0
Nous voyons dans la première commande que le plugin nous signale qu'il y a dix mises à jour disponibles.
La seconde commande utilise l'option « -u » qui effectue en amont un « apt-get update ». Malheureusement, le timeout de 10 secondes par défaut a été atteint avant la fin, d'où le besoin de rallonger ce timeout avec l'option « -t ».
Il est possible de ne vérifier que les mises à jour de certains packages grâce à des expressions régulières et l'option « -i ».
root@supervision:/usr/local/nagios/libexec# apt-get dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
iceweasel iceweasel-l10n-fr libicu48 libmozjs17d libnss3 libnss3-1d xserver-common xserver-xephyr xserver-xorg-core xulrunner-17.0
10 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 25,4 Mo dans les archives.
Après cette opération, 65,5 ko d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? n
Annulation.
root@supervision:/usr/local/nagios/libexec# ./check_apt -i ice
APT CRITICAL: 2 packages available for upgrade (2 critical updates). |available_upgrades=2;;;0 critical_updates=2;;;0
En lançant apt-get upgrade, on a la liste des dix mises à jour proposées par Debian. Ensuite, nous lançons notre plugin en ciblant le mot « ice ». Le plugin nous ressort bien deux mises à jour, qui sont : « iceweasel » et « iceweasel-l10n ».
Ce plugin sera appelé sur les systèmes distants via « check_nrpe », il faut donc modifier le fichier « /usr/local/nagios/etc/nrpe.cfg » sur les serveurs Debian à superviser pour créer la commande.
# vi /usr/local/nagios/etc/nrpe.cfg
…
…
command[check_apt]=/usr/local/nagios/libexec/check_apt $ARG1$
Ensuite, sur le serveur Nagios, il ne reste plus qu'à configurer le service :
define service{
use generic-service
host_name SERVEURLINUX
service_description Mise à jour Debian
check_command check_nrpe!check_apt!-u
}
C'est simple et très pratique.
Il y a un besoin de privilèges « root » pour effectivement lancer la commande « apt-get update » sinon, le plugin ne fera pas l'update et retournera toujours une alerte. De plus, le nombre d'update qu'il retournera sera celui issu du dernier update lancé par l'administrateur.
Une solution consiste à lancer régulièrement dans crontab de root la commande « apt-get update » (une fois par jour par exemple), puis dans le fichier « /usr/local/nagios/etc/nrpe.cfg », enlever l'argument, ce qui donne : command[check_apt]=/usr/local/nagios/libexec/check_apt. L'option « -u » devient inutile dans le service : check_command check_nrpe!check_apt.
V-K. Switch manageable▲
V-K-1. Ping et paquets perdus et de la RTA ▲
Nous utilisons le plugin « check_ping » déjà installé par défaut, ainsi que le service déjà configuré qui est le suivant :
define service {
use generic-service
host_name switch ou IP
service_description PING
check_command check_ping!200.0,20%!600.0,60%
normal_check_interval 5
retry_check_interval 1
}
Ce service permet de dire à Nagios de superviser le switch toutes les cinq minutes en conditions normales et de refaire des contrôles toutes les minutes jusqu'à ce que son état final soit normal.
Une alerte critique sera émise si le temps moyen de réponse (RTA) est plus élevé que 600 millisecondes ou que le nombre de paquets perdus est supérieur ou égal à 60 %.
Une alerte warning sera émise pour un RTA inférieur à 200 ms et 20 % ou moins de paquets perdus.
V-K-2. Statut des ports▲
Ce tutoriel prend pour exemple un « Switch ProCurve Cisco ». Nous cherchons à savoir si nos ports sont actifs ou non. Pour cela, nous utiliserons SNMP afin de récupérer les informations du Switch. Normalement, SNMP est activé par défaut, si ce n'est pas le cas, activez-le.
Dans un premier temps, nous avons besoin de trouver les OID nous donnant le statut des ports. Pour cela, lançons depuis le serveur « supervision » la commande « snmpwalk ».
root@supervision:~# snmpwalk -v1 -c public switch2 | more
iso.3.6.1.2.1.1.1.0 = STRING: "ProCurve J9087A Switch 2610-24-PWR, revision R.11.60, ROM R.10.06 (/sw/code/build/nemo(R_ndx))"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.11.2.3.7.11.78
iso.3.6.1.2.1.1.3.0 = Timeticks: (3560265850) 412 days, 1:37:38.50
iso.3.6.1.2.1.1.4.0 = ""
iso.3.6.1.2.1.1.5.0 = STRING: "switch2"
iso.3.6.1.2.1.1.6.0 = STRING: "EtageLogement"
iso.3.6.1.2.1.1.7.0 = INTEGER: 78
iso.3.6.1.2.1.2.1.0 = INTEGER: 32
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
iso.3.6.1.2.1.2.2.1.1.4 = INTEGER: 4
iso.3.6.1.2.1.2.2.1.1.5 = INTEGER: 5
iso.3.6.1.2.1.2.2.1.1.6 = INTEGER: 6
iso.3.6.1.2.1.2.2.1.1.7 = INTEGER: 7
iso.3.6.1.2.1.2.2.1.1.8 = INTEGER: 8
iso.3.6.1.2.1.2.2.1.1.9 = INTEGER: 9
iso.3.6.1.2.1.2.2.1.1.10 = INTEGER: 10
iso.3.6.1.2.1.2.2.1.1.11 = INTEGER: 11
La liste est très longue d'où l'utilisation du pipe. Je vous donne la réponse.
Les OID donnant l'information sur le statut opérationnel du port sont :
.1.3.6.1.2.1.2.2.1.8.x
Avec x variant entre 1 et le nombre de ports disponibles. Dans mon cas, j'ai 32 ports :
root@supervision:~# snmpwalk -v1 -c public switch2 .1.3.6.1.2.1.2.2.1.8 | more
iso.3.6.1.2.1.2.2.1.8.1 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.2 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.3 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.4 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.5 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.6 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.7 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.8 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.9 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.10 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.11 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.12 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.13 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.14 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.15 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.16 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.17 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.18 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.19 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.20 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.21 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.22 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.23 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.24 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.25 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.26 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.27 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.28 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.101 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.106 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.107 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.4196 = INTEGER: 1
En fait, j'ai 28 ports, plus 4 ports pour mes fibres optiques. Nous remarquons que pour les ports 1, 3, 21, 22, 26, 27, nous avons INTEGER: 2. Le « 2 » signifie que le port est éteint.
Nous allons utiliser cette information via Nagios pour qu'il nous alerte si un port est en statut 2. Bien évidemment, il est inutile de faire ce genre d'alerte sur des ports où vous savez que rien n'est branché.
Commençons par effectuer un test en ligne de commande :
root@supervision:~# /usr/local/nagios/libexec/check_snmp -H switch2 -o .1.3.6.1.2.1.2.2.1.8.1 -r 1
SNMP CRITICAL - *2* | iso.3.6.1.2.1.2.2.1.8.1=2
Nous utilisons le plugin « check_snmp » (installé par défaut sur Nagios) avec les options :
- « -H » permet de préciser le nom ou l'IP du switch ;
- « -o » vous permet de spécifier l'OID ;
- « -r » vous permet dire à Nagios de retourner « OK » si la valeur de retour matche avec ce que vous avez mis. Dans notre cas, le retour est « 2 » au lieu de « 1 ». Donc Nagios retourne une alerte critique.
Voici maintenant un exemple de service pour le port « 1 » :
# Monitor Port 1 status via SNMP
define service{
use generic-service ; Inherit values from a template
host_name switch2
service_description Port 01 Link Status
check_command check_snmp!-C public -o .1.3.6.1.2.1.2.2.1.8.1 -r 1
}
V-K-3. Erreurs, bande passante, saturation…▲
Nous allons voir comment superviser un port de façon plus approfondie, notamment compter le nombre d'erreurs, calculer la saturation et calculer le taux d'occupation des ports.
Pour faire cela, il nous faut un plugin que nous allons concevoir et de plus, ce dernier utilisera SNMP pour récupérer les informations de nos switches.
Pour cet exemple, nous travaillons sur des switches HP Procurve. Avant de vous le montrer, voici quelques explications plus détaillées.
V-K-3-a. RX Errors▲
L'OID utilisé pour obtenir ces erreurs est le suivant : ifInErrors → .1.3.6.1.2.1.2.2.1.14.X(3) avec X correspondant au numéro du port. Dans le plugin, cette information est obtenue à un instant « t1 » et un autre instant « t2 ». Puis nous calculons la différence. Entre 0 et 5 erreurs, on émet une alerte warning et au-delà de 5, une alerte critique.
Pour information, la durée entre « t1 » et « t2 » est de cinq secondes.
Cet OID est défini dans la MIB RFC1213-MIB.
V-K-3-b. Saturation▲
L'OID utilisé pour obtenir ces erreurs est le suivant : .1.3.6.1.2.1.2.2.1.21.X (Gauge)(4) avec X correspondant au numéro du port. Dans le plugin, cette information est obtenue à un instant « t1 » et un autre instant « t2 ». Puis nous calculons la différence. Entre 0 et 5 erreurs, on émet une alerte warning et au-delà de 5, une alerte critique.
Pour information, la durée entre « t1 » et « t2 » est de cinq secondes.
Cet OID est défini dans la MIB RFC1213-MIB.
V-K-3-c. Bande passante et taux d'occupation▲
Pour calculer la bande passante et le taux d'occupation, nous avons besoin de récolter plusieurs informations :
- ifInOctets(5) : le nombre d'octets reçus : .1.3.6.1.2.1.2.2.1.10.X ;
- ifOutOctets(6) : le nombre d'octets transmis : .1.3.6.1.2.1.2.2.1.16.X ;
- ifSpeed(7) : la vitesse du port : .1.3.6.1.2.1.2.2.1.5.X.
Avec X correspondant au numéro du port.
Les nombres d'octets transmis et reçus sont obtenus à deux instants « t1 » et « t2 ». Puis on calcule la bande passante :
Bande passante = ( (ifInOctets2 - ifInOctets1) + (ifOutOctets2 - ifOutOctets1) ) / (t2 - t1)
À partir de cette bande passante, nous calculons le pourcentage d'occupation du port et une alerte est émise au-delà de 50 % (warning) et 90 % (critique).
Pourcentage d'occupation = ( (bande passante * 8) / Vitesse électronique) * 100
Ces OID sont définis dans la MIB RFC1213-MIB.
V-K-3-d. Plugin▲
Le programme est écrit en Perl et il se lancera sur notre serveur « supervision ». Perl est déjà installé et il faudra (si ce n'est pas le cas) installer les modules Perl Net::SNMP et Monitoring::Plugin.
cpan -i Monitoring::Plugin Net::SNMP
Voici le programme :
Ce programme se lance de la façon suivante :
perl check_switch.pl -
H HOSTNAME -
pn NUMERO-
PORT-
SWITCH
Pour avoir de l'aide, lancer le programme avec l'option -h.
Ce programme doit être mis dans le répertoire « /usr/local/nagios/libexec/ » et doit être rendu exécutable :
chmod +x check_switch.pl
V-K-3-e. Configuration Nagios▲
Nous devons maintenant configurer Nagios sur notre serveur supervision afin qu'il puisse lancer le plugin en local afin d'interroger les ports de nos switches.
Nous n'utilisons pas « check_nrpe » qui permet de lancer le plugin sur le serveur distant. Il s'agit d'interroger un matériel distant en exécutant un programme local qui se nomme « check_switch.pl ». Il faut configurer la commande et le service dans Nagios.
Dans le fichier « /usr/local/nagios/etc/objects/commands.cfg », configurons la commande que Nagios doit lancer si besoin :
# 'check_switch' command definition
define command{
command_name check_switch
command_line $USER1$/check_switch.pl -H $HOSTADDRESS$ $ARG1$
}
Le plugin sera appelé via le nom « check_switch » et Nagios lancera le programme « check_switch.pl » qui se trouve dans le répertoire des plugins. Il lancera automatiquement ce dernier avec l'option « -H » et le nom du switch qui sera dans la configuration du service.
« $ARG1$ » contiendra l'ensemble des arguments que nous souhaiterons passer au plugin.
Voici le service que nous configurons dans notre fichier switchX.cfg :
# Monitor Port 2 - vérification
define service{
use generic-service ; Inherit values from a template
host_name switch2
service_description Port 02 check
check_command check_switch!-C public --pn 2
}
Nous constatons que nous lançons bien le plugin « check_switch ». Ensuite, il y a le séparateur « ! » qui permet de distinguer les arguments. $ARG1$ ci-dessus correspond donc à « -C public --pn 2 ».
Il ne reste plus qu'à tester la configuration et redémarrer Nagios.
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios stop; pkill nagios; /etc/init.d/nagios start
Tout doit être OK sans erreur !
Le plugin suivant permet de faire une vérification nécessaire sur un port et cela dure environ cinq secondes (temps imposé). Sur un switch de 28 ports (ou sur plusieurs switches), vous comprendrez que ça prendra beaucoup plus de temps. C'est à vous de voir si c'est utile de tester tous les ports ou s'il faut améliorer le plugin. N'hésitez pas à me donner vos avis : 10 commentaires
VI. Remarques▲
VI-A. Plugins▲
Il arrive souvent que Nagios ne dispose pas de plugins par défaut pour surveiller les services de notre choix. De ce fait, la solution consiste à les développer nous-mêmes, ou bien à les trouver sur la toile.
Pour voir tous les plugins installés par défaut par Nagios, aller dans le répertoire « /usr/local/nagios/libexec/ ».
Sur le site de Nagios, vous avez également la liste et la documentation des plugins par défaut : Nagios-plugin
Il existe un site de référence pour trouver un plugin Nagios : Nagios Exchange. À chaque fois que vous cherchez un plugin, je vous recommande d'y jeter un coup d'œil. Soit vous trouvez le plugin de vos rêves, soit vous vous inspirez de certains pour faire le vôtre. Vous pouvez aussi proposer des améliorations sur le site afin d'en faire bénéficier tout le monde.
Tout plugin Nagios contient ou doit contenir une documentation. Pour la consulter, il suffit de lancer en ligne de commande le programme avec l'option « -h » :
plugin-nagios -h
plugin-nagios -help
Si vous avez besoin de le lancer dans un mode plus verbeux afin d'avoir un affichage plus détaillé en ligne de commande, tout bon plugin possède également une option « -v » qui active ce mode. N'hésitez pas à l'utiliser pour tester votre plugin.
Pensez toujours à rendre les plugins exécutables via un « chmod+x ». De plus, n'oubliez pas d'uniformiser les droits sur vos programmes.
VI-B. Erreur Perl▲
Lorsque vous installez des plugins Nagios trouvés sur la toile, il y a 80 % de chances qu'ils soient développés en Perl, car ce langage est très performant et pratique. Si vous obtenez ce genre de message :
Can't locate Nagios/Plugin.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .).
C'est tout simplement parce que ce programme utilise un module qui n'est pas installé sur votre serveur. Dans notre cas, il s'agit du module Monitoring::Plugin. Pour l'installer, la commande suivante (en root ou sudo) fera l'affaire :
cpan -i Monitoring::Plugin
Si vous rencontrez des soucis, voici une documentation pouvant vous aider : Installation des modules Perl CPAN. Et si cela ne suffit point, le forum Perl est à votre disposition.
VII. Conclusion▲
J'espère que ce tutoriel vous a aidé, vous a inspiré ou que vous avez tout simplement appris des choses. Dans tous les cas, si vous souhaitez laisser vos appréciations, remarques, proposer des corrections, des améliorations, n'hésitez pas. 10 commentaires .
VIII. Remerciement▲
Je tiens à remercier toutes les personnes m'ayant inspiré à l'écriture de ce tutoriel. Je remercie également ram-0000 et Torgar pour leur relecture technique et ClaudeLELOUP pour les corrections orthographiques.