Problème de performance avec pnp4nagios sous Solaris

Depuis quelques temps déjà, je devais mettre en place pnp4nagios combiné à un nagios 3.2 sur une nouvelle machine. Auparavant, je passais par une machine un peu vieillotte (un sunfire V210 avec 2 Go de mémoire) que je devais remplacer par une plus récente (à base de M5000 Sun). L'ancienne plateforme passait par un nagios combiné avec ndoutils (un backend de stockage des données de performance sous MySQL). Cette plateforme était très contraignante pour plusieurs raisons :

• Plugin de génération de graphique maison (c'est votre serviteur qui avait écrit ça)
• Scripts de gestion du contenu de la table nagios_servicechecks : je découpais cette table en journée pour pouvoir supporté le volume de données (environ 200 Mo/jour et 17 Go d'historique)
• Lenteur de la solution : nagios et le module de base de données (ndo2db) n'était pas très consommateur mais en revanche, la base MySQL était très consommatrice de ressource disque et CPU.

Bref, pour toutes ces raisons et après un rapide tour des solutions existantes, nous avions décidé de partir sur l'excellent plugin pnp4nagios pour l'historisation. Avec ce plugin, plus de serveur MySQL, moins d'IO, plus de script de maintenance. Bref, que du bonheur.

C'est donc assez confiant qu'il y a quelques jours que nous avons procédé à la mise en production. Mais comme toujours, j'ai eu une mauvaise surprise lors de la migration. Lors de la fin de la bascule de tous nos anciens services sur la nouvelle (environ 900 services), j'ai commencé à voir des messages d'erreurs m'indiquant un time out lors du lancement du script process_perfdata.pl au bout de 5 secondes. En y regardant de plus près, j'ai constaté que le timeout était fixé par la directive perfdata_timeout=5 et en urgence, j'ai donc fixé le timeout à 30 s.

Une fois ce contournement mis en place, j'ai pu regarder en détail le problème. J'ai notamment constaté que la machine passait énormément de temps à faire ses mises à jour. En rajoutant quelques traces, je me suis rendu compte que le script process_perfdata.pl n'utilisait pas la bibliothéque native perl RRD mais le binaire rrd ! Suite à quelques tests que j'avais pu faire il y a quelques temps sur les deux modes de fonctionnement, j'ai essayé de voir si le problème ne pouvait pas venir de là.

Après un coup d'oeil à la configuration de nagios et je suis tombé sur cette partie :

define command {
  command_name    process-service-perfdata-file
  command_line    /bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl --bulk=/var/nagios/service-perfdata
}

define command {
  command_name    process-host-perfdata-file
  command_line    /bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA --bulk=/var/nagios/host-perfdata
}

Rien de bien choquant mais le problème est que sous Solaris la version de RRD venant de sunfreeware s'installe dans /usr/local. Problème, ce dernier est livré avec un binding perl prévu pour la version 5.8.8. Malheureusement, la version installée par défaut (ie dans le répertoire /usr/bin) est une version 5.8.4 et n'est pas en mesure d'utiliser la bibliothéque native perl de RRD.

Bref, j'ai donc changé la version de perl par celle se trouvant dans /usr/local/bin :

define command {
  command_name    process-service-perfdata-file
  command_line    /usr/local/bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl --bulk=/var/nagios/service-perfdata
}

define command {
  command_name    process-host-perfdata-file
  command_line    /usr/local/bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA --bulk=/var/nagios/host-perfdata
}

Un coup d'arrêt relance et après quelques temps, j'ai obtenu une nette diminution au niveau des temps de traitement de perfdata :

Zoom sur la partie basse :

C'est ici qu'on constate tout l'intérêt de l'utilisation de la bibliothéque native RRD : on est passé à des temps de traitement d'environ 30s à des temps de traitement de l'ordre de la seconde.