IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Services à superviser avec Nagios

apprendre, aller plus loin avec les services

Afin de garantir le bon fonctionnement d'un parc informatique, il est nécessaire de le superviser et pour cela, nous choisissons Nagios. Mais une fois ce dernier installé, la question qui revient le plus souvent est : « que dois-je vraiment superviser ? ».
Dans ce tutoriel, nous listerons quelques services utiles à superviser et surtout, nous verrons comment le faire via la recherche ou le développement de plugins adéquats.
10 commentaires Donner une note à l´article (5)

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

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 Donner une note à l´article (5).

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 :

Installation modules Perl
Sélectionnez
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
Sélectionnez
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 :

Installation snmp
Sélectionnez
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 :

Debian 5 et moins
Sélectionnez
# sec.name  source community
# com2sec paranoid default public
com2sec readonly  default public
#com2sec readwrite default private
Debian 6, 7 et plus
Sélectionnez
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.

Redémarrer SNMP
Sélectionnez
/etc/init.d/snmpd restart

Petit test local :

test : snmpwalk
Sélectionnez
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++
Sélectionnez
# 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++
Sélectionnez
# 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,

Ligne de commande
Sélectionnez
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 :

Windows : Espace disque - ligne de commande
Sélectionnez
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 :

Service Windows
Sélectionnez
# 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 :

Linux : espace disque - ligne de commande
Sélectionnez
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.

Serveur Linux
Sélectionnez
# 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

Windows
Sélectionnez
# 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…

Linux
Sélectionnez
# 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 » :

Windows : MEMUSE
Sélectionnez
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 :

Windows : service MEMUSE
Sélectionnez
# 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 :

check_memory.pl
Cacher/Afficher le codeSélectionnez

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
Sélectionnez
chmod +x check_memory.pl

Ce programme n'est fonctionnel que si les modules Perl suivants sont installés sur le serveur :

Installation Modules Perl
Sélectionnez
cpan -i Monitoring::Plugin Sys::MemInfo

Vous pouvez tester le programme sur le serveur en ligne de commande :

 
Sélectionnez
# /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.

NRPE
Sélectionnez
# vi /usr/local/nagios/etc/nrpe.cfg
&#8230;
&#8230;
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.

Serveur Linux
Sélectionnez
# /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%
Serveur supervision Nagios
Sélectionnez
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 !

Service
Sélectionnez
# 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 :

NSC.ini
Sélectionnez
;allow_arguments=0

Nous devons avoir :

activer NRPE
Sélectionnez
allow_arguments=1

Penser à redémarrer le service NSCLIENT++.

Maintenant, nous pouvons depuis notre serveur « supervision » lancer une requête.

Check_nt : pas de seuil
Sélectionnez
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 :

CheckUpTime
Sélectionnez
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 :

Service
Sélectionnez
# 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 :

Plugin check_uptime pour Linux
Cacher/Afficher le codeSélectionnez

Ce programme doit être déposé dans le répertoire « /usr/local/nagios/libexec ». Rendez-le exécutable.

chmod
Sélectionnez
chmod +x check_uptime.pl

Ce programme ne sera fonctionnel que si le module Perl suivant est installé sur le serveur :

Instalation module Perl
Sélectionnez
cpan -i Monitoring::Plugin

Vous pouvez tester le programme sur le serveur en ligne de commande :

Commande
Sélectionnez
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.

NRPE serveur à superviser
Sélectionnez
# vi /usr/local/nagios/etc/nrpe.cfg
&#8230;
&#8230;
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.

NRPE check_uptime
Sélectionnez
# /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
Supervision depuis serveur Nagios
Sélectionnez
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 !

Service check_uptime
Sélectionnez
# 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.

PROCSTATE
Sélectionnez
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.

SERVICESTATE
Sélectionnez
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.Image non disponible

Pour Nagios, voici la configuration du service :

Windows : service MEMUSE
Sélectionnez
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 :

check_process.pl
Cacher/Afficher le codeSélectionnez

Ce programme doit être déposé dans le répertoire « /usr/local/nagios/libexec ». Rendez-le exécutable.

chmod
Sélectionnez
chmod +x check_process.pl

Ce programme ne sera fonctionnel que si les modules Perl suivants sont installés sur le serveur :

 
Sélectionnez
cpan -i Monitoring::Plugin Proc::ProcessTable

Vous pouvez tester le programme sur le serveur en ligne de commande :

Commande
Sélectionnez
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 ».

NRPE
Sélectionnez
# vi /usr/local/nagios/etc/nrpe.cfg
&#8230;
&#8230;
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.

Depuis serveur Nagos
Sélectionnez
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 !

Service check_uptime
Sélectionnez
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 :

DHCP
Sélectionnez
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 :

Service DHCP
Sélectionnez
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_dns
    Sélectionnez
    root@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 DNS
    Sélectionnez
    define 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.

Installer modules
Sélectionnez
cpan -i  Monitoring::Plugin Net::NTP

Voici le programme :

check_ntp.pl
Cacher/Afficher le codeSélectionnez

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 :

Ligne de commande DOS
Sélectionnez
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 :

NSC.ini
Sélectionnez
NRPEListener.dll
CheckExternalScripts.dll

Dans les sections [NRPE] et [External Script], il nous faut cette ligne pour activer les arguments :

Activer arguments
Sélectionnez
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 :

Commande check_ntp
Sélectionnez
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 :

Test depuis serveur Nagios
Sélectionnez
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.

Service Nagios
Sélectionnez
# 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 :

Service Nagios pour Linux
Sélectionnez
# 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 ».

check_apt
Sélectionnez
# /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 ».

check_apt personnaliser
Sélectionnez
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.

NRPE
Sélectionnez
# vi /usr/local/nagios/etc/nrpe.cfg
&#8230;
&#8230;
command[check_apt]=/usr/local/nagios/libexec/check_apt $ARG1$

Ensuite, sur le serveur Nagios, il ne reste plus qu'à configurer le service :

Service check_apt
Sélectionnez
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 :

Ping, paquets perdus
Sélectionnez
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 ».

snmpwalk
Sélectionnez
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 :

OID statut des ports
Sélectionnez
.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 :

Mes ports
Sélectionnez
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 :

check_snmp : test port 2
Sélectionnez
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 » :

Service : port 1
Sélectionnez
# 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 :

Formule bande passante
Sélectionnez
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).

Formule pourcentage d'occupation
Sélectionnez
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.

Installer modules Perl
Sélectionnez
cpan -i Monitoring::Plugin Net::SNMP

Voici le programme :

check_switch.pl
Cacher/Afficher le codeSélectionnez

Ce programme se lance de la façon suivante :

Lancement programme
Sélectionnez
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
Sélectionnez
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 :

Commande Nagios
Sélectionnez
# '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 :

Service - port 2
Sélectionnez
# 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.

Redémarrer Nagios
Sélectionnez
# /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 Donner une note à l´article (5)

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 » :

Aide plugin Nagios
Sélectionnez
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 :

Erreur Perl : module
Sélectionnez
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 :

Installation module Perl
Sélectionnez
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 Donner une note à l´article (5).

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.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   


Nagios s'appelait autrefois « NetSaint ».
Ce nom localisé est issu de la traduction de Windows en fonction de la version, de la langue.
The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.
The length of the output packet queue (in packets).
The total number of octets received on the interface, including framing characters.
The total number of octets transmitted out of the interface, including framing characters.
An estimate of the interface's current bandwidth in bits per second.

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2014 djibril. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.