dimanche 26 février 2012

Gestion des mots de passe de l'interface web de shinken

Shinken est sortie il y a peu de temps en version 1.0rc1. J'ai voulu l'installer et utiliser la nouvelle interface web. Comme j'ai eu quelques difficultés et qu'il semblerait que d'autre ai eu le même problème que moi (merci à David pour ton aide !), je me permets de déposer quelques éléments sur le sujet.
Pour l'installation, il faut tout d'abord télécharger l'archive à l'adresse suivante :https://github.com/naparuba/shinken/tarball/1.0rc1
Vous obtiendrez alors l'archive naparuba-shinken-1.0rc1-0-g5a2075e.tar.gz. Une fois l'archive décompressé, vous pourrez lancer l'installation à l'aide de la commande suivante :
sudo python setup.py install --install-scripts=/usr/bin/
De là, lancez shinken avec la commande /etc/init.d/shinken start
Si vous jetez un oeil au process shinken de votre machine, vous devriez obtenir les choses suivantes :
root@robert:/home/drayan/dev/naparuba-shinken-5a2075e# ps -fu shinken
UID        PID  PPID  C STIME TTY          TIME CMD
shinken  15495 30036  0 00:15 ?        00:00:00 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30009     1  0 Feb25 ?        00:00:56 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30019 30009  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30021     1  0 Feb25 ?        00:00:51 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30031 30021  0 Feb25 ?        00:00:21 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30036     1  0 Feb25 ?        00:00:40 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30046 30036  0 Feb25 ?        00:00:07 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30051     1  0 Feb25 ?        00:00:54 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30061 30051  2 Feb25 ?        00:05:53 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30063     1  0 Feb25 ?        00:00:22 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30073 30063  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30079     1  0 Feb25 ?        00:01:11 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30080 30079  0 Feb25 ?        00:00:03 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30087 30079  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30109 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30116 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30124 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30140 30051  1 Feb25 ?        00:03:26 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30149 30051  0 Feb25 ?        00:00:14 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30170 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
Vous pouvez maintenant vous rendre sur l'interface web de shinken sur l'url suivante : http://localhost:7767/
Un utilisateur vous sera demandé. Il s'agira par défaut de admin/admin.
A ce sujet, il faut savoir que le système d'authentification s'appuie sur la configuration contenu dans le fichier shinken-specific.cfg (dans le répertoire /etc/shinken) et notamment sur le passage suivant :

# The WebUI broker module
define module{
       module_name      WebUI
       module_type      webui
       
       host             0.0.0.0       ; mean all interfaces
       port             7767

[...]
       modules          Apache_passwd,ActiveDir_UI,Cfg_password
[...]
}
Comme indiqué, l'interface essaye d'authentifier l'utilisateur avec 3 modules différents. Le premier qui y arrive arrête le mécanisme.
Dans le cas présent, nous allons tout d'abord essayer de nous authentifier avec un fichier htpasswd apache (toujours dans shinken-specific.cfg) :
define module{
       module_name      Apache_passwd
       module_type      passwd_webui

       #  WARNING : put the full PATH for this value!
       passwd           /etc/shinken/htpasswd.users

}
Vient ensuite le module active directory :
# Check authentification for WebUI using a Active Directory
define module{
       module_name      ActiveDir_UI
       module_type      ad_webui

#   UNCOMMENT this line to really enable this module and allow it to
#   connect!
#        ldap_uri         ldaps://myserver
       username         user
       password         password
       basedn           DC=google,DC=com

}
Enfin, dans le cas de l'interface web de shinken (avec sa conf par défaut), ce dernier va s'appuyer sur ces fichiers de configuration. Dans le cas de l'utilisateur admin, il s'agit d'un contact (au sens nagios) définie dans les fichiers de configuration (par défaut, fichier contacts.cfg). Le mot de passe est par ailleurs définie de la manière suivante :
define contact{
        use                                     generic-contact
        contact_name                            admin
        email                                   shinken@localhost
        pager                                   0600000000   ; contact phone number
        password                                admin
        is_admin                                1
}
De là, vous pouvez changer le mot de passe et le faire prendre en compte par shinken. Il ne reste plus maintenant qu'à configurer vos services !

lundi 19 décembre 2011

Patch multi packet pour NRPE 2.13

Malgré le faible intérêt de la sortie de nrpe 2.13, je vais tout de même le déployer pour la simple et bonne raison que nous allons bientôt migrer notre infrastructure nagios de Solaris à Linux. C'est donc dans ce cadre que j'ai voulu changer de version et surtout réappliquer le patch que j'utilise depuis pas mal de temps permettant de gérer des sorties longues.

Problème, le patch de tonvoon (dont je parle ici) n'est plus utilisable en l'état. Comme de toute façon le code source a très peu été retouché (juste l'ajout d'une fonction dans le démon nrpe), nous allons voir comment faire pour récupérer ce patch et forcer son application.

Tout d'abord, il nous faut récupérer une copie de notre patch sur notre machine :

wget https://dev.icinga.org/attachments/download/113/nrpe_multiline.patch

Passons maintenant à la transformation de notre patch au format Windows (eurk !) :

unix2dos ./nrpe_multiline.patch

Il ne nous reste plus qu'à passer le patch en indiquant la ligne de commande patch --binary -l -p1. Si tout se passe bien, la sortie devrait ressembler à ce qui suit :

nous@roulette:~/nagios/nrpe-2.13$ patch --binary -l -p1 < ../nrpe_multiline.patc
h 
patching file include/common.h
patching file src/check_nrpe.c
patching file src/nrpe.c
Hunk #1 succeeded at 972 (offset -57 lines).
Hunk #2 succeeded at 1190 (offset -57 lines).
Hunk #3 succeeded at 1206 (offset -57 lines).
Hunk #4 succeeded at 1235 (offset -57 lines).

Lançons maintenant la configuration et la compilation. Tout devrait bien se passer.

Nous allons maintenant nous assurer qu'il n'y a pas eu de régression. Tout d'abord créons un fichier nrpe.cfg avec le contenu suivant :

log_facility=daemon
pid_file=./nrpe.pid
server_port=5666
server_address=127.0.0.1
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1
dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300

command[short_output]=echo coucou
command[long_output]=/bin/cat /etc/wgetrc

La première commande affiche un simple coucou et la seconde affiche le contenu du fichier /etc/wgetrc.

Mais trêve de bavardage et lançons séance tenante notre démon :

nous@roulette:~/nagios/nrpe-2.13$ ./src/nrpe -c ./nrpe.cfg -d
nous@roulette:~/nagios/nrpe-2.13$ ps -ef | grep nrpe
nous      9374     1  0 17:04 ?        00:00:00 ./src/nrpe -c ./nrpe.cfg -d
nous      9376  5769  0 17:04 pts/0    00:00:00 grep --color=auto nrpe

Tout semble parfait. Lançons un test de notre première commande :

./src/check_nrpe -H localhost -c short_output
coucou

Ça semble plutôt pas mal. Regardons maintenant la taille de la sortie de notre commande longue et comparons cela au fichier d'origine :

nous@roulette:~/nagios/nrpe-2.13$ ./src/check_nrpe -H localhost -c long_output | wc
    126     797    4496
nous@roulette:~/nagios/nrpe-2.13$ wc /etc/wgetrc
 126  797 4496 /etc/wgetrc

C'est parfait ! Notre NRPE en version 2.13 avec patch sortie longue est prêt à fonctionner !

samedi 26 novembre 2011

Sortie de NRPE 2.13

Il y'a peu de temps, la version 2.13 de NRPE est sortie. Autant dire que je suis assez déçu sur le contenu de cette nouvelle version puisque nous n'avons qu'un seul changement pour définir qui a le droit de se connecter sur l'agent NRPE dans le fichier nrpe.cfg (ainsi que la compilation sous Solaris 10). En gros, auparavant, vous étiez obliger de donner explicitement l'IP de votre serveur nagios pour pouvoir vous connecter. Dorénavant, vous pouvez préciser un réseau avec un masque. Ci-dessous un exemple de fichier nrpe.cfg faisant appel à ce mécanisme :
log_facility=daemon
pid_file=/var/run/nagios/nrpe.pid
server_port=6666
nrpe_user=nagios
nrpe_group=nagios
# allowed_hosts=127.0.0.1
allowed_hosts=192.168.0.0/24

dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200 
NB: ce démon tourne sur le port 6666 pour des besoins de test. La commande check_nrpe ci-dessous utilisera l'option -p 6666 pour pouvoir s'y connecter.
On va essayer de se connecter sur notre agent NRPE. Ci-dessous l'adresse de mon poste :
drayan@robert:~/dev/nrpe-2.13$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 1c:6f:65:21:7b:c0  
          inet adr:192.168.0.17  Bcast:192.168.0.255  Masque:255.255.255.0
[...]
Lançons un test en tant que localhost (qui devrait nous jeter du fait qu'on se présente avec l'adresse IP 127.0.0.1) :
drayan@robert:~/dev/nrpe-2.13$ ./src/check_nrpe -H localhost -c check_load -p 6666
CHECK_NRPE: Error - Could not complete SSL handshake.
Parfait ! Lançons maintenant la même chose en utilisant notre adresse IP :
drayan@robert:~/dev/nrpe-2.13$ ./src/check_nrpe -H 192.168.0.17 -c check_load -p 6666
OK - Charge moyenne: 0.03, 0.06, 0.09|load1=0.030;15.000;30.000;0; load5=0.060;10.000;25.000;0; load15=0.090;5.000;20.000;0;
Voilà, c'est tout ... Je suis notamment assez déçu que le patch pour gérer les sorties longues (dont j'avais parlé ici il y'a quelque temps) ne fasse pas partie de cette release.

Compilation de NRPE 2.13 sous Ubuntu 11.10


Si comme moi vous voulez compiler votre démon NRPE 2.13 sous Ubuntu oneiric, vous avez dû tomber sur un bien beau message d'erreur :

drayan@robert:~/dev/nrpe-2.12$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
[...]
checking for type of socket size... size_t
checking for SSL headers... SSL headers found in /usr
checking for SSL libraries... configure: error: Cannot find ssl libraries
drayan@robert:~/dev/nrpe-2.12$

Autant dire qu'avec ça, je suis bien avancé. Après quelque recherche, je tombe sur un bug référencé sur launchpad : https://launchpad.net/ubuntu/oneiric/+source/nagios-nrpe/2.12-4ubuntu3.

Dans le bug, le mainteneur du paquet nous fait part d'un laconique message invitant à rajouter l'option --with-ssl-lib=<multiarch dir>. N'ayant pas trop d'idée de ce que ça pouvait bien vouloir dire, j'ai donc tâtonné avant de tomber sur un configure qui passait. Dans l'espoir de faire gagner du temps à d'autre, je vous fais donc part de cette merveilleuse option (dans le cas d'une machine avec un kernel x86_64) :
drayan@robert:~/dev/nrpe-2.13$ ./configure --with-ssl-lib=/usr/lib/x86_64-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
[...]
checking for SSL headers... SSL headers found in /usr
checking for SSL libraries... SSL libraries found in /usr/lib/x86_64-linux-gnu

*** Generating DH Parameters for SSL/TLS ***
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
.+......................[...].....++*++*++*++*++*++*
checking for Kerberos include files... could not find include files
checking for perl... /usr/bin/perl
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating subst
config.status: creating include/config.h


*** Configuration summary for nrpe 2.13 11-11-2011 ***:

 General Options:
 -------------------------
 NRPE port:    5666
 NRPE user:    nagios
 NRPE group:   nagios
 Nagios user:  nagios
 Nagios group: nagios


Review the options above for accuracy.  If they look okay,
type 'make all' to compile the NRPE daemon and client.
Bref, maintenant, je vais pouvoir me battre avec le patch long output pour NRPE.

mercredi 9 novembre 2011

Optimisation de PNP4Nagios avec RRDcached

Suite à l'article sur l'utilisation du démon NPCD, j'ai voulu voir quel pourrait être l'impact de la mise en place du démon RRDCached sur le fonctionnement de PNP4Nagios. Pour se faire, il faut bien comprendre à quoi sert ce fameux démon.

Pour cela, il faut revenir sur le fonctionnement de PNP4Nagios à savoir de prendre un grand nombre de métrique et d'alimenter au fur et à mesure un grand nombre de petit fichier : les fichiers RRD. Au delà d'un certain nombre de service, nous pouvons nous retrouver avec une machine qui fait énormément d'IO et qui du coup n'a plus le temps de mettre à jour certaines métriques (mécanisme de timeout de PNP4Nagios). Nous voyons donc qu'au delà un certain seuil, PNP4Nagios peut retomber sur tous les travers classiques des infrastructures de surveillance : consommer de la puissance CPU et être lent (qui a soufflé le nom de NDO utils ?). Le démon RRDCached prend ici tout son sens. En effet, ce dernier va buffuriser les mises à jours RRD au lieu de les faire unitairement réduisant grandement les IO sur notre serveur nagios.

Pour mieux comprendre, prenons le cas d'un serveur nagios remontant en moyenne 10 métriques par services. Si vous êtes comme moi et que vous avez explosé vos fichiers RRD en n fichiers pour chaque services, vous aurez un fichier par métrique. Si nous scruptons toutes les 5 minutes nos différents services (toujours en moyenne), nous nous retrouvons à mettre à jour 10 fichiers pour chaque test de service nagios. Si on reporte ce chiffre sur 1 heure, nous aurons donc environ 120 écritures sur une heure. Si vous multipliez tout ceci par le nombre de service présent sur vos machines (on va dire 5000), vous vous retrouvez à faire environ 600000 écritures par heure. Si vous ajoutez à cela que votre serveur faire appel à des métriques qui sont plus régulière (toutes les 2 minutes voir toute les minutes), vous pouvez commencer à avoir des problèmes.

RRDCached, en s'intercallant entre les outils RRD et les écritures sur le disque, va regrouper ces dernières et ainsi mieux exploiter les capacités de la machine. Imaginons que ce dernier procéde à une buffurisation des écritures sur 1/2 heure, vous diviserez par 6 vos IOs pour des services scruptant toutes les 5 minutes. Ce chiffre pouvant monter à 30 pour des services remontant des métriques toutes les minutes.

Voyons maintenant comment mettre en oeuvre ce démon.

NB : Par la suite, il est évident que je considérerai que PNP4Nagios sera configuré en mode NPCD (cf mon article sur la configuration de PNP4Nagios en mode NPCD) et surtout qu'il utilisera le module RRDs de perl pour faire ses mise à jour (cf mon article sur le sujet).

Installons tout d'abord notre démon rrdcached (sous Debian ou ubuntu) :
sudo apt-get install rrdcached
Et regardons si ce dernier est bien lancé :
$ /etc/init.d/rrdcached status
rrdcached (1262) is running.
$ ps -fp 1262
UID        PID  PPID  C STIME TTY          TIME CMD
root      1262     1  0 18:46 ?        00:00:00 /usr/bin/rrdcached -l unix:/var/run/rrdcached.sock -j /var/lib/rrdcached/journal
Tout semble aller pour le mieux. Nous allons maintenant configurer le script process_perfdata.pl afin qu'il passe par ce démon pour la mise à jour des fichiers RRD. Pour se faire, nous allons modifier le fichier process_perfdata.cfg et notamment la ligne suivante :
RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sock
Attendons un petit peu et allons consulter l'interface de PNP4Nagios. Cette dernière ne devrait plus nous remonter de statistique sur notre moteur PNP4Nagios. Ce comportement est tout à fait normal étant donné que l'interface PHP de PNP4Nagios n'a aucune connaissance de ce nouveau démon. Ce dernier continue donc de s'appuyer sur les fichiers RRD présent alors que ces derniers ne sont plus mis à jour en temps réel.

Modifions maintenant la configuration de PNP4Nagios (fichier config_local.php qu'il faudra créer s'il n'existe pas) afin de lui préciser le pipe nommé de notre démon de cache :

$conf['RRD_DAEMON_OPTS'] = 'unix:/var/run/rrdcached.sock';
Dorénavant, le graphique se met bien à jour en temps réel. En effet, en précisant au binaire RRDTool que nous avons un démon de cache, ce dernier va simplement dire au démon de vider ses buffers sur les fichiers RRDs que nous sommes en train de consulter afin qu'il nous fasse profiter des dernières valeurs que ce dernier avait emmagasiné.

Vous pourriez vous dire que le fait de vider le cache de notre démon avant de pouvoir consulter nos graphiques est une perte de temps. Effectivement, ce comportement sera peu avantageux pour les fichiers RRDs que nous voudrons consulter. En revanche, il sera avantageux pour les milliers d'autres qui pourront continuer à être buffurisé.

ATTENTION !!! Dorénavant, votre démon RRDcached est un élément vitale de votre infrastructure. Je vous recommande chaudement de le surveiller avec votre moteur nagios sous peine de ne plus avoir de mise à jour si ce dernier devait tomber.

Vous allez me dire que tout ça c'est très bien mais vous voudriez savoir si le jeu en vaut la chandelle. Comme généralement les graphiques parlent plus que les chiffres, voici les résultats des temps de réponse moyen de PNP4Nagios suite à la mise en place de ce merveilleux plugin (ici sur 1 mois) :


Comme vous pouvez le constater, du jour où le démon a été mis en place, j'ai vu une grosse diminution de l'effet yoyo et surtout une baisse assez importante du temps moyen pour les mise à jour de PNP4Nagios (passage de 9 secondes avec pointe à 70 secondes à une moyenne sans pique autour de 5 secondes). Autant vous dire que tout ceci est une très bonne nouvelle et que je vais pouvoir continuer mon travail de big brother !

mardi 20 septembre 2011

Template wlsagent pour PNP4Nagios

Il y a de ça peu de temps, j'ai présenté l'utilisation de wlsagent pour le suivi sous nagios d'instance WebLogic. J'avais également donné quelques exemples de graphique sous PNP4Nagios mais sans donner le template de présentation :



Le template est maintenant disponible à l'adresse suivante : http://docs.pnp4nagios.org/templates/check_wlsagent

Il faut copier-coller ce fichier dans le répertoire template de PNP4Nagios (en principe, quelque chose comme /usr/local/pnp4nagios/share/templates/) et se débrouiller pour que PNP4Nagios arrive à faire le lien entre le plugin de lancement et le template.

Personnellement, comme j'appelle tout au travers de NRPE, j'ai simplement créé un doublon de la commande check_nrpe en l'appelant check_wlsagent :
# 'check_wlsagent' command definition
define command{
  command_name check_wlsagent
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
J'appelle ensuite mes surveillances à l'aide de commande de ce genre :
# Application WebLogic à surveiller
define service{
  use generic-service
  host_name remotehost
  service_description Application hyperimportante
check_command check_wlsagent!check_application_hyperimportante
}

mardi 13 septembre 2011

Optimisation du couple nagios/PNP4Nagios

Description de l'installation

J'utilise depuis maintenant plusieurs années un moteur nagios sur notre infra pour avoir un suivi de ce qu'il se passe sur nos serveurs.

Au début, nous avions axé notre déploiement sur la partie serveur d'application Java (à base de WebLogic). Nous avons très rapidement activé l'utilisation du moteur de base de données ndo2db. Par la suite nous avons intégré environ 60 serveurs sous cette surveillance pour un total d'environ 600 services. Les choses sont restés en l'état en raison de la machine que nous utilisions qui était particulièrement lente et pauvre en IO disque (pour les plus curieux, il s'agissait d'un Sunfire V210 avec un bi-processeur Ultrasparc III@1Ghz et 2 Go de mémoire).

Il y'a de ça un an et demi, nous avons échangé notre vieille machine poussive contre une machine Solaris flambant neuve (à base de M5000). De là, j'ai profité pour changer nos outils d'autant que je n'étais pas particulièrement content de ndo2db. C'est à cette occasion que j'ai mis en place la toute dernière version de PNP4Nagios en version 0.6 (que j'avais testé en version béta quelques temps auparavant).

De là, j'ai découvert le super système de template de PNP4nagios (cf cet article) et j'ai commencé à mettre ça en oeuvre sur tous nos éléments vitaux d'infrastructure (apache, oracle, MySQL etc.).

Le mode synchrone de PNP4Nagios étant particulièrement lent, j'ai très vite déployé PNP4Nagios en mode bulk lancé par nagios. Mais, le succès aidant, je suis rapidement passé de 60 à 100 machines puis 200. Comme un SI ne diminue jamais, dernièrement nous sommes arrivé à environ 300 machines pour environ 3000 services. Loin d'être énorme (en tunant la configuration de nagios, on parle de configuration montant à 30000 services et plus), les performances du moteur nagios avaient tout de même tendance à se dégrader comme on peut le voir sur le graphique ci-dessous des temps de latence maximum :


On voit ici des temps de latence maximum qui monté à plus de 60 secondes. Même si c'est loin d'être complètement bloquant, ça indique une réactivité beaucoup moins bonne qu'au début du fonctionnement de la plateforme.

C'est donc à ce moment là que j'ai commencé à regarder les optimisations qu'il était possible de faire et notamment l'utilisation de NPCD. J'ai également mis en place le démon de cache RRD. Pour ce dernier j'essaierai d'en parler dans un autre article.

Mise en place de NPCD

La mise en place de NPCD se fait en deux temps : mise en place du démon puis modification de la commande d'insertion des données de performance dans PNP4Nagios. Ci-dessous un schéma extrait du site de PNP4Nagios expliquant le fonctionnement du démon NPCD :

Pour le lancement du démon NPCD, rien d'extraordinaire, il suffit simplement de lancer la commande suivante :
/usr/local/pnp4nagios/bin/npcd
On peut ensuite vérifier sa présence sur le serveur :
ps -ef | grep npcd
Le démon se lance en s'appuyant sur le fichier /usr/local/pnp4nagios/etc/npcd.cfg. Ce dernier va contenir toutes les informations sur le comportement que devra adopter le démon. Vous pouvez notamment tuner les éléments suivants :
  • Le temps de pause entre deux checks dans le répertoire de spool ;
  • Le nombre max de process perfdata à lancer en parallèle ;
  • La verbosité de la log.
Une fois NPCD, nous allons maintenant pouvoir basculer l'insertion des données en utilisant un répertoire de spool. Pour se faire, nous allons changer les commandes process-service-perfdata-file et process-host-perfdata-file (en principe dans le fichier /usr/local/etc/nagios/template/commands.cfg). Ces dernières ressemblaient aux lignes suivantes :
define command {
       command_name    process-service-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/service-perfdata
}

define command {
       command_name    process-host-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/host-perfdata
}
Nous les avons remplacé par les lignes suivantes :
define command {
       command_name    process-service-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-perfdata.$TIMET$
}

define command {
       command_name    process-host-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-perfdata.$TIMET$
}
Il s'agit simplement de substituer l'appel direct à la commande process_perfdata.pl de PNP4Nagios par un déplacement de fichier dans un répertoire. Pas grand chose me direz-vous mais nous allons vite voir que ce petit changement aura des conséquences très intéressante au niveau de nagios.

Résultat de l'optimisation

Et il se trouve que cette modification a eu un énorme impact sur les performances. Pour preuve un état du temps de latence moyen maximum :

On peut voir que nous avons gagné en stabilité au niveau des temps de réponse max et surtout que ces derniers restent largement en dessous les 5 secondes (sauf exceptionnellement mais rien à voir avec le comportement précédent).