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).