Introduction

Gros guide de mise en place de Nagios sur Debian, avec comme principal objectif de vous amener petit à petit à monitorer tout ce qu’on peut imaginer sur un parc de serveurs Linux, Windows, des équipements réseaux etc. Ca part d’un exemple bien détaillé (je l’espère) pour bien faire comprendre les principes et l’esprit Nagios pour espérer à la fin, vous avoir donné de quoi évoluer facilement pour ajouter n’importe quel test.
Au départ, je voulais faire un guide super complet, mais avec Nagios, on ajoute des tests tous les jours, pour ainsi dire. Bref, ça fait 3 mois que j’attendais pour faire ce guide. Finalement je l’écourte un peu et j’ajouterai (peut-être) des chapitres plus tard sur ce blog.
Après un premier exemple bien complet, je donne des exemples rapides de contrôles courants.

J’ai eu l’idée de rédiger cet article sachant que je ne connaissais rien à Nagios (rien de sa mise en place, rien des fichiers de conf, rien de sa syntaxe, rien des outils de base, rien des plug-ins supplémentaires et rien des contributions à gogo sur le web etc). L’intérêt, n’y connaissant rien justement, est que j’explique pas à pas, notamment les principes de l’outil pour comprendre comment le configurer, en détaillant parfois toutes les panneaux que j’ai pu me prendre, mais en donnant la solution rapidement 🙂

A la fin, je donne mes fichiers de conf, un peu anonymisés et allégés, ils peuvent vous servir pour de la mise en place de certains morceaux ou pour vous guider dans la syntaxe. Exemple, vous voulez surveiller vos serveurs DNS, cherchez le mot « dns » dans tous les fichiers, comprenez ce qui y est fait et copiez-collez-modifiez les bons blocs. Reste à changer les noms de hostname 🙂 Hum, ça, ce sera plus tard lorsque j’aurai complété par d’autres articles (cf. ci-dessus), je n’ai pas trop le temps, et sinon, je ne publierai jamais cet article… il traîne depuis 3 mois…

Je ne compte pas faire de l’ombre 😀 à Nicolargo (passionné du sujet Nagios) mais mon approche est différente : je pars de ce que Debian a fait pour moi, pas des sources à compiler pour avoir l’absolue dernière version. Les répertoires de configuration et de chemins des binaires sont différents, tous les plug-ins classiques sont directement disponibles.
Après, une fois l’outil fonctionnel sur quelques cas, ça reste du Nagios pur. Allez voir son site, il y a de bonnes docs et le forum peut aider aussi. Sans compter d’autres sites d’outils de monitoring complémentaires, notamment http://www.monitoringexchange.org/, et évidemment la doc officielle qui est très bien foutue. J’y ferai référence autant de fois que j’y penserai.

La version actuellement packagée sous Debian « stable » (Lenny) est Nagios 3.0.6. Comme d’habitude avec Debian, un peu en retard sur la version officielle, mais il y a d’autres intérêts à utiliser tout de même la version packagée, à mon avis.

Installation

Sur un air d’aptitude install

Ca commence sur un air connu par un aptitude install nagios3. A noter que ça descend par dépendance 3 paquets nagios-plugins* qui contiendront tout un tas de plugins (contrôle de LDAP, de mail, de MySQL, de MRTG, de serveur FTP…).
Une remarque pendant l’installation (pour le chapitre suivant) :

[...]
Get:10 ftp://ftp.fr.debian.org lenny/main nagios3-doc 3.0.6-3 [2034kB]
[...]
serious bugs of nagios3-common (-> 3.0.6-3) 
 #519341 - nagios3-common: missing "then" in nagios3-common.prerm (Fixed: nagios3/3.0.6-4)
[...]

On voit aussi passer ces plugins :

[...]
Creating config file /etc/nagios-plugins/config/http.cfg with new version
Creating config file /etc/nagios-plugins/config/load.cfg with new version
Creating config file /etc/nagios-plugins/config/mail.cfg with new version
[...]

Lisez de préférence tous les fichiers README.Debian des répertoires /usr/share/doc/nagios3 et /usr/share/doc/nagios-plugins. Il y a 2/3 infos importantes, mais je les reprends au fil de l’eau dans la suite de l’article.

Droits d’accès à l’interface web de Nagios

Les README.Debian habituels qu’on trouve dans /usr/share/doc/nagios* parlent du truc et indiquent qu’on doit avoir une question posée pendant l’installation. Vu le bug mentionné plus haut par apt-listbugs (c’est quoi ?), je ne m’étonne qu’à moitié de n’avoir pas vu passer de « fenêtre » (ncurses) pendant l’installation. Doc pas à jour ou vrai bug. Bon bref, il faut rectifier le tir.

On voit dans /etc/apache2/conf.d/nagios3.conf que les droits sont gérés par htaccess (voir directive AuthUserFile)dans /etc/nagios3/htpasswd.users. Or, ce fichier n’existe pas, on doit donc le créer.

htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

Le nom nagiosadmin semble important pour éviter certains ennuis (de ce que j’en ai lu, mais je ne sais plus où, peut-être là).
Enfin, vérifiez les droits sur le fichier en question, idéalement, il faut :

chown root:www-data /etc/nagios3/htpasswd.users
chmod 640 /etc/nagios3/htpasswd.users

Et recharger apache via /etc/init.d/apache2 reload.
L’adresse d’accès doit être http://votre.serveur/nagios3/.

Principe de base et cheminement de ma doc

Une fois qu’on a pataugé un peu, il en ressort quelques grands principes pour gagner en autonomie et arriver à pondre du fichier de conf au kilomètre ou savoir où regarder pour trouver un plug-in tiers, le mettre en place, l’utiliser et même l’adapter.
Quelques grandes idées pour démarrer :

• Nagios appelle des scripts permettant de contrôler un élément particulier (ou plusieurs d’un coup) : contrôler un service, les espaces disques, la charge CPU, la réponse d’un site web, la charge d’un port de switch etc
• On a des modèles d’appels de scripts, nommés en général « check_quelquechose » permettant de comprendre les paramètres pour un contrôle donné (valeurs limites, nom du truc à regarder
• Il faudra déployer des agents pour certains contrôles, notamment pour contrôler du Windows. En gros, pour obtenir des informations qui sont récupérables par un traitement local uniquement, pas à distance. Normal me direz-vous. Ces agents sont des à côtés du projet Nagios. Mais il y a déjà tout ce qu’il faut.
• Il va falloir décrire nos machines une à une et ce qu’on contrôle pour chacune (forcément, c’est pas magique comme outil). On pourra faire des groupes de machines et y associer des contrôles appliqués à ces groupes. Exemples : toute machine hébergeant un serveur web aura de base un contrôle vérifiant le port 80 ; toute machine Windows aura de base un contrôle sur la nécessité d’applications de patchs, un contrôle sur l’espace disque etc…

Dans cette doc, je vais décrire chaque sujet dans l’ordre dans lequel j’ai mis en place les contrôles, souvent en partant de la doc officielle (parfois pas exactement à jour) puis en adaptant au contexte Debian qui a, comme d’habitude, pré-mâché certaines choses (mise à dispo de scripts, « modèles » pour tel type de machine, de switchs etc).
Je voulais avant tout contrôler un peu tous ces jolis serveurs Windows qui sont peu bavards en général (ou qui racontent uniquement des trucs dont on se fout)… Donc il y a une bonne partie sur l’interfaçage avec Windows ; cas somme toute courant je pense.
Du coup, je dissémine des informations malgré moi à mesure de ma compréhension (lorsque j’ai « appris » Nagios) ; et surtout en ayant rédigé la doc quelques mois après (hum).

Bon, en bref, Nagios est un outil tout sauf clef-en-main (sauf peut-être si vous optez pour un système comme FAN, mais vous aurez un système dédié « limité » à Nagios&co je suppose)
Le paramétrage est long et on en ajoute chaque jour.
Pour le planning pour le patron, prévoyez large. Mise en place et premiers résultats quelques heures tout au plus, paramétrage plus poussé : quelques semaines. Plus on en découvre, plus on monitore de choses. On corrige les problèmes et on en anticipe d’autres grâce à Nagios. Bref, le bonheur avec reporting pour le patron. A la fin, on commence à écrire ses propres scripts, en n’importe quel langage.

Ah au fait, attention aux alertes par mail. Nagios vous dit tout : « tel service est tombé », « tel service est toujours KO », « tel service est revenu ». Multiplié par le nombre de service et de machines, ça fait des mails à la pelle. Faudra prévoir des règles de tri dans un premier temps…

C’est parti

Surveillance des basiques de serveurs Windows (NT, 2000, XP, 2003 et +)

Oui les libristes vont encore perdre du temps à critiquer le fait que je parle de Windows-le-mal-incarné d’abord. Economisez-vous. Mon point de vue est que justement, Nagios aide très bien à monitorer « du windows » là où Windows est quand même à chier niveau remontées d’alertes, en standard. Autant, un Linux un tant soit peu configuré vous remonte déjà plein de choses par mail, par exemple, qu’il ne sera pas forcément la peine d’aller contrôler par Nagios.

Installation et 1er paramétrage de l’agent NSClient++

Si vous voulez la doc officielle, commencez par là (http://nagios.sourceforge.net/docs/3_0/quickstart.html) et enchainez sur http://nagios.sourceforge.net/docs/3_0/monitoring-windows.html.
Il faut donc télécharger et déployer un agent windows pour Nagios. Disponible en 32, 64 bits. Je pense qu’il y en a plusieurs, j’ai opté pour celui-ci, qui m’a l’air complet : http://sourceforge.net/projects/nscplus.
Lorsque ça marchera pour une machine, il n’y aura qu’à déployer l’agent à distance et injecter le fichier de conf NSC.ini qui va bien sur chaque machine. Pensez aux outils sysinternals.com microsoft, notamment les PSTools et psexec. C’est pratique pour automatiser.

L’agent apporte une interface entre l’appelant Nagios et un serveur Windows. Il apporte aussi de base quelques outils pour effectuer une certaine batterie de tests. Le paramétrage des tests que l’on veut se fait sur le serveur Nagios, pas du côté de l’agent Windows.
Si on veut ajouter un test qui n’est pas prévu par cet agent, il faudra écrire un script, sous windows cette fois, et le définir dans l’agent, qui sert de relai, en gros. On le verra plus bas avec le contrôle des patchs Windows en attente d’installation.

Bref, une fois NSClient++ installé, la doc dit d’aller trafiquer les options du service Windows qu’on vient d’installer. Dans les propriétés du service, allez dans l’onglet « Connexion / Log on » et cocher la case pour autoriser à « interagir avec le bureau ».

Maintenant il faut ajuster un peu le fichier de paramétrage de l’agent, C:\Program Files[ (x86)]\NSClient++\NSC.ini. Sachant que je vais y revenir plus tard pour NRPE (voir plus bas), si c’est la galère pour déployer le fichier sur vos machines, attendez un peu pour le faire une seule fois (cherchez plus bas dans l’article NRPE). Enfin bon, commencez par un serveur avant de généraliser un truc qui ne fonctionne pas.

Dans la section [modules], décommenter comme suit (tout sauf CheckWMI.dll et RemoteConfiguration.dll) :

[modules]
;# NSCLIENT++ MODULES
;# A list with DLLs to load at startup.
;  You will need to enable some of these for NSClient++ to work.
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
; *                                                               *
; * N O T I C E ! ! ! - Y O U   H A V E   T O   E D I T   T H I S *
; *                                                               *
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
SysTray.dll
CheckEventLog.dll
CheckHelpers.dll
;CheckWMI.dll
;
; RemoteConfiguration IS AN EXTREM EARLY IDEA SO DONT USE FOR PRODUCTION ENVIROMNEMTS!
;RemoteConfiguration.dll

Dans la partie [NSClient], attribuer un port d’écoute (celui par défaut à priori) et dans la section [Settings], à voir si vous voulez un mot de passe. Je n’en ai pas mis, j’ai limité l’écoute à l’adresse IP de mon serveur Nagios ; pratique dans ce cas simple avec un seul serveur de monitoring.

[...]
[NSClient]
[...]
port=12489
[...]
[Settings]
[...]
;password=secret-password
allowed_hosts=192.168.y.x
[...]

Notez la section [log] qui peut être pratique quand rien ne fonctionne et qu’il faut comprendre ce que NSClient reçoit de Nagios.

Redémarrez le service, le client est prêt.

Premier morceau de config Nagios, la théorie

Maintenant on va indiquer à Nagios d’aller voir ce qu’il se passe là-bas et quels tests de base effectuer pour une « machine windows ».
On va partir d’un modèle de configuration de poste Windows fourni par Debian et définir notre machine, appelée « mamachine ».
Là ça fait un peu mal au crâne la première fois, mais une fois le concept compris, vous pondrez des fichiers de conf Nagios au kilomètre. En effet, c’est le chapitre où on fait le baptême du feu dans la syntaxe Nagios. J’espère être clair dans ces prochains chapitres.

---

IMPORTANT

---

L’organisation en terme de fichiers dans /etc/nagios3/conf.d/ est complètement libre. Vous pouvez tout mettre dans un seul fichier ou couper par site (par exemple), ou encore séparer la déclaration des machines de celle des groupes de machines, mettre la définition de vos propres services à part ou proche des groupes de machines auxquelles ces services se rapportent etc.
C’est votre choix, à la fin, Nagios intègrera l’ensemble des directives de configuration de « conf.d » (ainsi que des plugins, tout ceci est configuré en amont par Debian dans /etc/nagios3/*conf) et hurlera au « reload » si vous vous êtes trompés.
C’est d’autant plus libre qu’en géréral, il y a plusieurs manières d’organiser les choses pour arriver à un même résultat. Premier exemple ci-dessous : est-ce que je dis que « mamachine » appartient au groupe (hostgroup) « windows-servers » ou est-ce que je dis que le groupe « windows-servers » contient comme membre (members) « mamachine ». A vous de voir.
Je mets les mots-clefs Nagios entre parenthèse et en italique pour faire l’association « bon français »-« mot-clef Nagios ».

---

TNATROPMI

---

Donc, pour une conf de base pour tester une machine via NSClient++, je prends le « groupe » Windows (qu’on complètera plus tard) et je crée une machine « mamachine » appartenant à ce groupe. Ce qu’on appelle ici un « groupe » est un « ensemble des machines auxquelles un certains nombre de tests communs seront appliqués ». C’est un « hostgroup ». Debian a déjà affecté plusieurs tests à ce groupe. C’est pratique.
L’idée sera d’ajouter par la suite au groupe (hostgroup) « windows-servers » d’autres les tests qui sont communs à tous les Windows : présence de patchs WSUS par exemple. Par exemple, on n’ajoutera pas le contrôle du disque F: qui n’existe peut-être pas sur tous les serveurs. Là il faudra faire par machine, ou alors un groupe « des machines ayant un disque F: ». C’est votre choix.

Attention, la notion de « template » dans Nagios est différente, c’est réellement un modèle qui définit d’autres informations sous-jascentes. On n’y touchera pas (il me semble). Il y a des templates « windows » (nommés windows-server, et pas windows-servers qui est le groupe de machine windows, vu ? ;)), mais aussi par exemple un « template » de service nommé generic-service sur lequel on se base pour déclarer un service.

Premier morceau de config Nagios, la pratique

Alors, je localise le groupe (hostgroup) « windows-servers » pré-mâché par Debian. On va l’utiliser car il amène en standard les contrôles de base : espace disque, charge CPU…

srvnag:/etc/nagios3/conf.d# dpkg -S windows.cfg
nagios3-common: /usr/share/doc/nagios3-common/examples/template-object/windows.cfg
srvnag:/etc/nagios3/conf.d# cp /usr/share/doc/nagios3-common/examples/template-object/windows.cfg template-windows.cfg

Ce fichier contient, sans les commentaires standards mais avec les miens et une fois un peu remodelé, ceci :

define host{ ; définition d'une machine basée sur le template "windows-server", nommé ci-dessous
        use             windows-server  ; Inherit default values from a template
        host_name       mamachine       ; The name we're giving to this host
        alias           C est mamachine       ; A longer name associated with the host
        address         192.168.x.y     ; IP address of the host
        ; #hostgroups windows-servers ; voir ci-dessous
}

Cette dernière ligne (hostgroups) aurait permis de dire « mamachine » appartient au groupe (hostgroup) « windows-servers » (donc elle hérite de tous ses tests). Dans mon cas, j’ai plutôt décidé de définir la liste des membres (=machines = « host ») d’un groupe (hostgroup) dans la définition de ce groupe. Voir ci-dessous.
J’ai adapté les tests fournis par Debian pour le groupe « windows-servers » (qui ne contient qu’une machine pour l’instant). Voici le fichier résultant :

### Déclaration du groupes windows-servers auquel on affectera les tests communs à tous les windows
define hostgroup{
        hostgroup_name  windows-servers ; Mes serveurs windows
        alias           Windows Servers ; Long name of the group
}

### Définition des SERVICE que l'on va associer au groupe windows-servers
# Create a service for monitoring the version of NSCLient++ that is installed
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     NSClient++ Version
        check_command           check_nt!CLIENTVERSION
}
# Create a service for monitoring the uptime of the server
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Uptime
        check_command           check_nt!UPTIME
}
# Create a service for monitoring CPU load
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     CPU Load
        check_command           check_nt!CPULOAD!-l 5,80,90
}
# Create a service for monitoring memory usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Memory Usage
        check_command           check_nt!MEMUSE!-w 80 -c 90
}
# Create a service for monitoring C:\ disk usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     C:\ Drive Space
        check_command           check_nt!USEDDISKSPACE!-l c -w 80 -c 90
}
# Create a service for monitoring the W3SVC service
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un service, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     W3SVC
;        check_command           check_nt!SERVICESTATE!-d SHOWALL -l W3SVC
;}
# Create a service for monitoring the Explorer.exe process
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un processus, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     Explorer
;        check_command           check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe
;}

Voilà. Si vous rechargez Nagios via /etc/init.d/nagios3 reload, ben ça plante !!!
Je décris ça juste après avoir décrit « check_command » histoire de finir l’initiation à la conf de base et aux problèmes pénibles du début :/.

Autres principes à comprendre de cet exemple

Qu’y a-t-il d’autre d’important dans cette configuration pour comprendre le principe de Nagios ? le mot-clef « check_command » bien sûr. Lors de la définition d’un service, la directive check_command est celle qui explique à Nagios comment effectuer le test et quels paramètres on lui passe. Les paramètres sont séparés par le « ! ». Le premier argument est le nom de la commande (command) Nagios (et pas du script appelé, pas encore, qui lui s’appelle command_line).

Exemple :

        check_command           check_nt!MEMUSE!-w 80 -c 90

On voit les valeurs d’alertes warning et critical pour la charge mémoire utilisée, en pourcentage. On retrouvera souvent les mêmes noms d’arguments alors que les scripts n’ont rien à voir entre eux (-w pour seuil de warning etc). Il doit y avoir une sorte de norme dans le développement de ces scripts, je suppose.

Pour comprendre le lien entre la command et le script effectivement appelé sur l’OS, voici :

srvnag:/etc/nagios-plugins# grep -r command_name * | grep check_nt
config/nt.cfg:  command_name    check_nt
[...]

On y voit l’association entre cette commande Nagios et la commande OS appelée :

srvnag:/etc/nagios-plugins/config/cat nt.cfg
define command {
        command_name    check_nt
        command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
# cette ligne est erroné d'ailleurs, on le verra plus tard.
}

La commande (command) check_nt appelle donc le script /usr/lib/nagios/plugins/check_nt.
C’est avec lui qu’il faudra jouer pour « tester certains tests » en ligne de commande, avant de comprendre pourquoi ils plantent depuis Nagios mais pas depuis la ligne de commande. C’est un cas courant..
Bon revenons au bug qui m’occupait et qui devrait aussi vous occuper, à priori un problème lors du reload (je n’ai plus le message précis), mais on comprend que :

Il manque le template windows-server

J’ai dit le template « windows-server », pas « windows-servers » qui est un hostgroup, j’insiste.
En effet, ce template est fourni dans les packages Debian, mais pas chargé par défaut. En cherchant un peu, on le trouve ici : /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz.
Mais si on le gunzip et qu’on le place dans /etc/nagios3/conf.d, il y a doublon de définition de generic-service comme le montre encore un reload qui plante. Ca se confirme avec cette commande :

srvnag:/etc/nagios3/conf.d# egrep "name[[:space:]]+generic-service" *
generic-service_nagios2.cfg:        name                            generic-service ; The 'name' of this service template
templates.cfg:        name                            generic-service   ; The 'name' of this service template

Deux fichiers définissent « generic-service ». Les emmerdes continuent.

Donc, je reprends le minimum du template générique, dans mon cas, « windows-server », on verra plus tard si j’ai besoin de quelque chose d’autre de ce super-template. Je crée donc ce fichier, tout au moins j’ajoute ce bout de code quelque part dans ma conf Nagios :

srvnag:/etc/nagios3/conf.d# cat windows-server_from_templates-gz.cfg
define host{ ; oui ça passe par un "host" pour définir ce modèle de machine "windows-server"
        name                    windows-server  ; The name of this host template
        use                     generic-host    ; Inherit default values from the generic-host template
        check_period            24x7            ; By default, Windows servers are monitored round the clock
        check_interval          5               ; Actively check the server every 5 minutes
        retry_interval          1               ; Schedule host check retries at 1 minute intervals
        max_check_attempts      10              ; Check each server 10 times (max)
        check_command           check-host-alive        ; Default command to check if servers are "alive"
        notification_period     24x7            ; Send notification out at any time - day or night
        notification_interval   30              ; Resend notifications every 30 minutes
        notification_options    d,r             ; Only send notifications for specific host states
        contact_groups          admins          ; Notifications get sent to the admins by default
        hostgroups              windows-servers ; Host groups that Windows servers should be a member of
        register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE
}

Bien sûr, on comprend que ce template dépend lui-même du template « generic-host », mais, ce « generic-host » est dans les templates de base de /etc/nagios3/conf.d/. Pas de problème cette fois.
Là, le restart de Nagios devrait bien se passer 🙂 hop, connexion à l’interface. Moi perso, j’y ai vu une tartine de trucs avec des warnings, des « critical », des machins à hurler partout. Surtout des trucs à débugger en fait. Ce qu’on va faire en expliquant.

Attention les remontées par mail vont commencer (par défaut root@localhost). Faites ce qu’il faut pour récupérer ces mails.

Bug « missing -l parameters »

Le premier bug relevé fût donc un résultat de commande « missing -l parameters » dans ̉l’interface web̉ de Nagios.
Pour débugger, il faut en revenir à la ligne de commande comme montré brièvement plus haut. Si on exécute le vrai binaire /usr/lib/nagios/plugins/check_nt, ça marche. Depuis Nagios, ça ne marche pas. Tiens tiens.
Demandez l’aide pour apprendre à utiliser ce plug-in en ligne de commande :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt
check_nt: Could not parse arguments
Usage:check_nt -H host -v variable [-p port] [-w warning] [-c critical][-l params] [-d SHOWALL] [-t timeout]

Vous pouvez faire un /usr/lib/nagios/plugins/check_nt --help pour une doc plus complète.
Si vous jouez avec l’outil en ligne de commande, ça marche pourtant, exemple :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt -H mamachine_ou_son_IP -v MEMUSE -p 12489 -w 80 -c 90
Memory usage: total:3945.26 Mb - used: 1287.70 Mb (33%) - free: 2657.56 Mb (67%) | 'Memory usage'=1287.70Mb;3156.21;3550.73;0.00;3945.26

Il y a deux problèmes. D’abord Nagios n’est pas configuré pour tolérer l’appel à des scripts « extérieurs » (raison sécuritaire). Ensuite, la command check_nt est mal définie (gasp !). J’en parlais plus haut.

Le README.Debian le disait, et dans notre cas on en a besoin, il faut autoriser Nagios a appeler des scripts extérieur. Il faut positionner set check_external_commands=1 dans /etc/nagios3/nagios.cfg. Ensuite, il faut modifier quelque chose dans dpkg pour qu’une manip soit retenue après mise à jour/upgrade de nagios par aptitude :

srvnag:/etc/nagios3# /etc/init.d/nagios3 stop
Stopping nagios3 monitoring daemon: nagios3
.
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
srvnag:/etc/nagios3# /etc/init.d/nagios3 start
Starting nagios3 monitoring daemon: nagios3/etc/init.d/nagios3: line 64: kill: (19130) - No such process.

A noter, j’ai vu plusieurs fois un problème de PID non trouvé, on dirait que le fichier /var/run/nagios3/nagios3.pid n’est pas purgé à l’arrêt de Nagios ; pas grave.

Enfin, on modifie la command check_nt. Le « missing -l parameters » signifie bien qu’on n’a pas passé le paramètre « -l » au binaire check_nt, paramètre obligatoire pour certains tests. En fait, dans /etc/nagios-plugins/config/nt.cfg, l’appel à check_nt est défini comme suit :

        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'

Mais souvent, dans les services associés à notre hostgroup windows-servers, on voit qu’un deuxième paramètre est passé. Le fameux « -l ». C’est simplement que la définition de la commande (command_line) ne s’occupe de récupérer qu’un seul paramètre…
Je suggère donc de modifier /etc/nagios-plugins/config/nt.cfg comme suit :

gw:/etc/nagios-plugins/config# cat nt.cfg
# 'check_nt' command definition
define command {
        command_name    check_nt
        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
        command_line    /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$
}

Reload de Nagios. Enfin les premiers testent passent !
Pour dire vrai, je suis passé par un stade intermédiaire de « wrong -l argument ». J’ai forcé l’appel du port (-p 12489) dans la command_line pour régler le problème. Si vous voulez rendre ce port variable, à vous de modifier la définition des services (dans les define service) appelant check_nt pour passer un n-ième argument.
J’ai aussi fait sauter les apostrophes, ça me faisait des trucs bizarres.
FIXME : si quelqu’un sait comment activer une trace qui permet de savoir comment a été appelée telle ou telle commande par Nagios, ce serait cool ça permettrait de débugger plus facilement. J’ai tenté plusieurs niveaux de débuggage, sans succès.

Ouf, premiers tests fonctionnels. Vite, d’autres !

Ca marche, c’est pas trop tôt. Quelques suggestions tirées de ce qui précède :

• Dans /etc/nagios-plugins/conf.d/, il y a plein de noms de commandes à lire, pour voir ce qu’on va pouvoir rapidement contrôler. Exemple : contrôler un port https, avec ou sans authentification (plusieurs commandes dispo).
• Dans /usr/lib/nagios/plugins/, il y a le pendant en terme de binaires. C’est bien de se familiariser avec ceux qu’on compte utiliser pour être sûr de savoir les utiliser en ligne de commande avant de s’ajouter des bugs en les définissant mal dans la conf Nagios.

Je considère par la suite que vous avez bien assimilé ce qu’on vient de voir et que vous êtes maintenant parés pour créer de la configuration Nagios à grand coup de grep et de copier-coller d’exemples. Je vais pouvoir donner des bouts de codes en vrac, par thème.

C’est reparti.
C’est là où j’aurais voulu faire une doc méga-complète, mais c’est impossible. J’ajouterai donc plus tard des chapitres lorsque j’estimerai que tel ou tel sujet n’était pas trivial à mettre en place ou qu’il y a un concept fort que je n’ai pas abordé.

Contrôle DHCP

Plus exactement, « tester si le serveur DHCP est en mesure d’attribuer des IP » (plage pleine ? service KO ?).
Je considère ici mon serveur Nagios comme un simple ordinateur client DHCP sur le réseau (ou une partie du réseau). En exécutant un script, l’outil check_dhcp simulera une demande de bail et vérifiera que tout se passe bien.
En lisant /etc/nagios-plugins/config/dhcp.cfg, vous voyez vite que la command_line attend un paramètre, l’adresse du serveur DHCP. Donc, en ajoutant quelque part dans votre /etc/nagios3/conf.d/quelquechose.cfg les lignes suivantes, on met en place le contrôle DHCP :

define service {
        use     generic-service
        host_name mon_serveur_dhcp ; ou alors vous raisonnez par hostgroups, au choix
        service_description     Reponse du DHCP
        check_command           check_dhcp
}

En ayant bien sûr défini « mon_serveur_dhcp » dans un bloc define host quelque part.
Notez qu’il y a aussi un check_dhcp_interface, qui d’après /usr/lib/nagios/plugins/check_dhcp --help permet de spécifier une interface particulière.

Ce contrôle est un bon exemple car il faut qu’il soit lancé avec les droits root – ou en sudo – car le principe, je suppose, doit être de forger des paquets pour déclencher une attribution de bail du serveur DHCP ; et forger des paquets => droit root, un peu comme l’outil de scan de port « nmap » dans certains types de scans. Lire /usr/share/doc/nagios-plugins/README.Debian à ce propos. Ca raconte de faire :

dpkg-statoverride --update --add root nagios 4750 /usr/lib/nagios/plugins/check_dhcp

Sinon, vous aurez un joli Warning: This plugin must be either run as root or setuid root. dans l’interface Nagios.
Dans mon cas, le serveur DHCP est un Windows (ah, j’te parle plus). J’ai donc aussi installé le client NSC++ sur cette machine afin de pouvoir remonter de base tous les autres indicateurs. En effet, j’ai déclaré « mon_serveur_dhcp » dans la catégorie windows-servers, donc il récupère de base tous les tests concernant le groupe « windows-servers », contrôle des disques, RAM, blablabla.
Hop, un test de plus.

Zoom sur les groupes de machines

J’en parle tout de suite car il y a déjà des groupes (hostgroups) définis dans /etc/nagios3/hostgroups_nagios2.cfg. Notamment les machines « pingables ». Je trouve que c’est une bonne idée d’ajouter des groupes type « les serveurs web » ou « les serveurs de mail ». Même si pour l’instant vous n’avez pas encore défini de service (define service) pour ces groupes, ça permet de s’organiser et de prévoir la distribution automatique de plein de tests à mesure qu’on déclare nos host et qu’on les affecte à ces groupes (hostgroup), et non pas aux machines.

Au passage, avec un bon dpkg -S base/debian.png et un grep qui va bien, vous allez vite localiser le bout de configuration qui permet d’affecter des icones aux types de serveurs, pour faire joli dans l’interface.

Droits d’utilisateurs, contacts

Pour créer un utilisateur en lecture (votre patron par exemple, il faut le limiter, pour pas qu’il fasse n’importe quoi depuis l’interface), le mieux est de lire http://nagios.sourceforge.net/docs/3_0/cgiauth.html. Attention, c’est fourbe car le menu de replanification – par exemple – de test de service est disponible pour tous les utilisateurs, mais c’est après validation de l’action qu’on voit que la personne n’a bien pas le droit de lancer une planification de tests.

Dans le cas d’une installation énorme de serveurs, il est possible d’affecter des contacts à tel ou tel serveur. Vous pouvez aussi donner les droits de supervision à une personne sur un certain ensemble de contrôles uniquement, ce genre de trucs.
Car la liste peut être longue une fois déclarés une 20aine de serveurs triés en X catégories…

Vue par service

Dans l’interface web de Nagios, vous avez sûrement trouvé le menu qui permet d’avoir un aperçu par hostgroup. On peut aussi créer une vue par service. Exemple, j’ai mis plein de contrôles de « services publics », à savoir la réponse d’un FTP distant, la présence d’un serveur web distant, la réponse spécifique (recherche d’un mot dans un page web reçue) etc. J’estime que tout ça représente un ensemble, mes « services publics dont j’aimerais être sûr qu’ils sont bien online à tout moment sinon on perd nos clients ».
Je vais donc définir un « groupe de service » (servicegroup) rassemblant des couples (machine , service).

Plus précisemment, il s’agit de lister des couples (host_name d’un host , service_description d’un service).
Petit exemple :

define servicegroup {
        servicegroup_name       public-services
        alias                   Services Internet
        members                 srvweb,Check URL non signee,ftpext,Check FTP ; les fameux couples host/service
}

Je suppose ici que les define host « srvweb » et « ftpext » sont définis, ainsi que les define service « Check FTP » et « Check URL non signee » ; ces exemples seront donnés plus bas dans cette doc.
Pour les services, il s’agit bien de leur description longue, pas de leur nom.
Ainsi, dans le menu « servicegroup overview », vous verrez un groupe « Services Internet » vous donnant d’un coup d’oeil l’état de tous vos services publics/web.

Contrôle de services Windows

Exemple pour un serveur Exchange ou pour une base Oracle, je veux être sûr que tous les services associés sont en cours d’exécution.
Bon cette fois, je passe sur les groupes de machines Oracle qu’on pourrait créer. Là le but est d’appréhender le contrôle de services Windows via NSClient++.

Exemple avec Exchange

Si je vous suggère de tester la commande suivante, vous allez vite comprendre :

srvnagw:/usr/lib/nagios/plugins# ./check_nt -H mon_serveur_exchange -p 12489 -v SERVICESTATE -d SHOWALL -l MSExchangeIS,MSExchangeMTA,SMTPSVC,RESvc,W3SVC

La liste des noms technique des services s’obtient en double-cliquant sur le nom d’un service Windows, dans ses propriétés.
Reste à définir le service et la commande qui va bien et à l’affecter à votre serveur ou votre groupe de serveurs Exchange.
Voir plus bas mes exemples si vous êtes paumés.

Ce qui est bien avec cet agent NSClient++, c’est que ça marche pour n’importe quel service. Ci-dessous, on découvre que ça marche aussi pour perfmon :).

Exemple avec l’anti-virus Sophos, remarque sur la syntaxe

Attention, certains services ont des espaces dans leur nom.

• Pour les nommer/utiliser en ligne de commande, il faut un backslash \
• Pour les nommer/utiliser depuis Nagios, il faut 2 backslash \

Exemple :

define service {
        use generic-service
        hostgroup_name          sophos-servers
        service_description     Svc SOPHOS server
        check_command           check_nt!SERVICESTATE!-d SHOWALL -l Sophos\\ Agent,Sophos\\ Certification\\ Manager,Sophos\\ EMLibUpdate\\ Agent,Sophos\\ Enterprise\\ Manager\\ Scheduler,Sophos\\ Management\\ Service,Sophos\\ Message\\ Router
}

Pour tester ce check_nt en ligne de commande, un seul \ suffirait.

Exemple de surveillance des services Oracle

Ben c’est la même chose, un gros check_nt!SERVICESTATE!-d SHOWALL -l blabla où « blabla » est la liste de noms de noms instances Oracle, du listener etc.

Contrôle de perfmon

Dans la lignée de ce qui précède, si vous voulez surveiller des indicateurs perfmon de serveurs Windows, c’est jouable.
Notez que perfmon permettant de surveiller à peu près n’importe quoi sur Windows (charge réseau par exemple), ce test peut être une variante d’un test de charge via SNMP ; en ce qui concerne la charge réseau. Pour d’autres indicateurs de perfmon, il n’y a que NSClient++ je suppose, ou un script dédié.
Notamment, vous pouvez contrôler la taille des files d’attente du serveur Exchange monitoré précédemment.
Je ne m’étends pas, mais il faut appeler check_nt avec « -v COUNTER » et le nom des indicateurs que l’on veut suivre.

Contrôle de switchs

Les informations sont décrites là : http://nagios.sourceforge.net/docs/3_0/monitoring-routers.html.
Il faut être un peu habitué à SNMP, ou alors c’est l’occasion de s’y mettre. Il faut savoir activer le SNMP sur un switch et connaître quelques OIDs.
Ceci dit attention, vous pourrez tester l’état de certains ports, l’uptime d’un switch. Mais pour contrôler la bande passante du trafic d’un port, il n’y a pas d’OID. Il faudra écrire votre script vous-même ou alors, interfacer avec Cacti qui lui stocke l’historique des informations de compteurs de trafic, permettant ainsi de calculer des vitesses moyennes. Je suis dessus là, donc j’en parlerai sûrement de ce ces 4.
Le principe est le suivant :

• Il faut activer le « requêtage » SNMP sur le routeur en question, définir une « communauté » (si autre que « public »), un éventuel mot de passe (si SNMP v3)
• S’inspirer ensuite du modèle de conf générique des switchs dispo ici : /usr/share/doc/nagios3-common/examples/template-object/switch.cfg
• Reprendre le template generic-switch (et uniquement lui) de /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz
• Lire http://fr.wikipedia.org/wiki/Snmp
• Lire http://doc.ubuntu-fr.org/snmp pour comprendre rapidement les MIB
• Tester en ligne de commande pure d’abord, avec check_snmp

Pour activer le SNMP sur un 3com type 4400, l’attaquer en telnet (menu system management snmp community) car ce n’est pas accessible en interface web. Pour un netgear, c’est gérable par l’interface web du switch (ou alors ça dépend de la version du firmware, j’ai déjà vu ça aussi). On peut limiter à une interface IP, par exemple le serveur Nagios exécutant la requête.

Appel à un script tiers, sous Windows : contrôle des patchs en attente

Truc très pratique, au lieu d’aller voir dans WSUS-qui-rame-et-qui-est-à-moitié-pratique.
On va utiliser NRPE, un agent qui tournera localement sur la machine distante et qui permettra d’exécuter des scripts. Ca tombe bien NSClient++ peut assurer ce rôle, du moment qu’on a décommenter NRPEListener.dll, voir plus haut dans la doc.
Nagios appellera donc NRPE qui appellera un script (ici un .wsf). Au niveau des alertes NAgios, on obtiendra des « warnings » et « critical » suivant la nature des patchs.
J’utilise le script suivant (ou celui là, je ne sais plus, essayez les deux).
Placez les par exemple sur C:\ du serveur à monitorer.

Conf NRPE pour patchs Windows

Dans la section [NRPE] du fichier NSC.ini d’un serveur à monitorer, j’ai dû paramétrer les choses suivantes :

;# COMMAND ARGUMENT PROCESSING
;  This option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed.
allow_arguments=1

;  This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in |`&><'"\[]{}) characters in arguments.
allow_nasty_meta_chars=1

allowed_hosts=192.mon.nag.ios

Et dans la section [NRPE Handlers], comprenez "les commandes autorisées via NRPE", j'ai simplement créé une commande appelée (au niveau de NSClient/NRPE) "windows_updates" :

command[windows_updates]=c:\\windows\\system32\\cscript.exe //NoLogo //T:120 c:\\check_windows_updates.wsf /w:0 /c:1
;# RESTE du blabla pour que vous situiez l'endroit
;# COMMAND DEFINITIONS
;# Command definitions that this daemon will run.
;# Can be either NRPE syntax:
;command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10

Attention aux doubles backslashs/slashs etc.
Rechargez le service NSClient++.
Je suppose que le port par défaut (5666) est accessible depuis NAgios vers votre serveur.

Conf Nagios pour patchs Windows

Si tous vos serveurs Windows sont équipés du script et que la conf NRPE dans NSClient++ est bonne pour chacun, vous pouvez ajouter quelque part dans /etc/nagios3/conf.d/ ce bout de code :

define service{
        hostgroup_name          windows-servers
        use                     generic-service
        service_description     Windows Update
        check_command           check_nrpe_1arg!windows_updates
}

Si vous n'avez qu'une machine (pour tester), pensez à utiliser host_name toto au lieu de hostgroup_name.

Ensuite, on va définir un test Nagios qui appelle la commande "windows_updates" via NRPE. Le nom windows_updates est bien celui reprit dans la conf NSC.ini, section [NRPE Handlers].
Après quelques tests, j'ai dû recréer mon propre passage d'argument à check_nrpe, script qui d'ailleurs vient normalement avec les plugins de Nagios. Voyez :

monnagios:/etc/nagios-plugins/config# cat check_nrpe.cfg
# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
#JACQUES
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 60
        #command_line   /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Notamment en ajoutant un timeout (-t) plus long et en supprimant le 2è argument.
Comme d'habitude, pour inventer cela, il faut jouer avec la commande /usr/lib/nagios/plugins/check_nrpe directement. Et commencer par jouer localement avec le script .wsf (sur la machine Windows, donc), histoire de vérifier que tout va bien et de débugger pas à pas votre bazar (script mal placé, NRPE mal configuré, Nagios mal paramétré pour ce test etc).

Voilà, normalement ce test fonctionne aussi.

Trucs en vrac

Par manque de temps et impossibilité de faire un guide "complet", je note 2/3 idées en vrac :

Attention après un /etc/init.d/nagios3 reload : temps de latence (tests en pending) et lorsqu'un test échoue, il est replanifié pour X minutes plus tard. On peut forcer sa réexécution, mais il faut y aller mollo et ne pas être trop impatient.

Il reste tant à dire : la dépendance entre services, la carte des machines, les prévisions de downtime de machines (pour éviter les mails et alertes inutiles), la fréquence des tests.
Mais là, maintenant que vous avez la base, vous allez pouvoir facilement lire n'importe quelle doc (je veux dire, même celles où très peu de choses sont expliquées) pour peaufiner votre installation. J'espère.

A+

(enfin c'est publié, youhou.... ; j'espère que le tout reste cohérent et utile vu que ça a été écrit en plein de fois et à différents moments de mon apprentissage Nagios)