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.

Recyclage d'une miroir SDS sous ZFS

ATTENTION !!! Dans ce qui va suivre, je vais vous expliquer comment mettre en place un pool ZFS. Cette manœuvre supprimera entièrement le contenu de votre ancien FS. Pensez à faire des sauvegardes de vos anciennes données !!!

Il y a peu de temps, j'ai eu à préparer une machine Solaris (une T5120 pour les plus curieux d'entre vous). A l'origine cette machine n'utilisait que du SDS (un mirroring software livré en standard sous Solaris) en combinaison avec les slices Solaris (l'équivalent des partitions classiques sous Linux). Comme on ne peut faire que 7 slices et que 5 slices étaient déjà pris pour le système et que la machine n'avait que deux disques, je me suis donc trouvé très rapidement bloqué pour la création de nouveaux FS. Auparavant, pour contourner ce problème, nous utilisions le mécanisme de lofs de Solaris (l'équivalent de l'option de montage bind sous Linux). Mais je n'étais pas vraiment enchanté de la situation ...

J'ai donc décidé de recycler un slice des deux disques qui étaient auparavant alloué à un device SDS afin de le réaffecter à un pool ZFS. En effet, avec ZFS, plus de problème de limitation de slice, de problème de mirroring, de création de FS, etc. Bref quelque chose d'un petit peu plus poussé en terme de fonctionnalité.

Pour démarrer, nous allons jeter un coup d'oeil au miroir existant avant de le casser. Tout ceci se fait à l'aide de la commande metastat :

$ metastat d6
d6: Miroir
 Sous-miroir 0: d16
   Etat : Ok        
 Sous-miroir 1: d26
   Etat : Ok        
 Accès : 1
 Option de lecture : roundrobin (par défaut)
 Option d'écriture : parallel (par défaut)
 Taille : 179891328 blocs (85 GB)

d16: Sous-miroir de d6
 Etat : Ok        
 Taille : 179891328 blocs (85 GB)
 Bande 0 :
     Périphérique     Bloc de débu Base          Etat Redis Tranche dynamique
     c1t0d0s6                0     Non             Ok   Oui
[...]

Nous avons donc un device d6 constitué de deux sous-miroirs d16 et d26 eux-même étant les slices 6 des disques c1t0d0 et c1t1d0 (soit respectivement les slices c1t0d0s6 et c1t1d0s6). Nous allons donc supprimer tout ceci à l'aide de la commande metaclear :
- suppression du mirroir :

metaclear d6

- puis suppression des sous-mirroirs :

metaclear d16

et

metaclear d26

Maintenant que nous avons deux slices de disponible, nous allons les allouer à un pool ZFS en mirroir que l'on appellera zfs_pool :

$ zpool create -f zfs_pool mirror c1t0d0s6 c1t1d0s6

NB : ne pas oublier l'option '-f'. Dans notre cas, comme les devices étaient anciennement utilisé en tant que partition ufs, zpool refuse de créer le pool zfs avec le message suivant :

$ zpool create zfs_pool mirror c1t0d0s6 c1t1d0s6
spécification vdev incorrecte
utilisez '-f' pour ignorer les erreurs suivantes :
/dev/dsk/c1t0d0s6 contient un système de fichiers ufs.

Et voilà ! Notre pool ZFS est prêt !

Tentons maintenant de créer un FS :

$ zfs create -o mountpoint=/data zfs_pool/data

Et voilà ! Le FS est monté, formaté et prêt à l'emploi. A remarquer que par défaut, il n'y a aucune limitation dans l'utilisation du FS et qu'il est possible d'utiliser tout l'espace du pool. Bien sûr, il est possible de limiter l'utilisation à l'aide de l'option quota. Ceci peut se faire avec la commande zfs set :

$ zfs set -o quota=10G zfs_pool/data

Vérifions le résultat :

$ df -h /data
Filesystem             size   used  avail capacity  Mounted on
zfs_pool/data           10G     8K    10G     1%    /data

Et voilà, je pense que ça sera tout pour aujourd'hui.

Compilation NRPE et génération d'un binaire statique sous Solaris 8 ou 10

On va pas aller jusqu'à dire qu'en ce moment Nagios soit toute ma vie mais en tout cas, au taff, ça occupe pas mal mes journées. Donc, je vais essayer de sortir les astuces que j'ai pu utiliser pour arriver à compiler NRPE et les plugins de surveillance standard.

Donc, pour la compilation, récupérer le source de NRPE, le décompresser et commencer par modifier le fichier src/nrpe.c de la manière suivante :

617c617
<               log_facility=LOG_AUTHPRIV;
---
>               log_facility=LOG_AUTH;
619c619
<               log_facility=LOG_FTP;
---
>               log_facility=LOG_DAEMON;

Une fois la modification terminée, il nous faut maintenant lancer configure avec les options suivantes :

./configure --prefix=/path/to/nagios --with-ssl=/usr/local/ssl/lib

NB : Ici il faut s'assurer d'avoir télécharger un compilateur GCC et OpenSSL depuis le site www.sunfreeware.com.

Lancez ensuite la compilation. En principe, vous devriez obtenir un nrpe fonctionnel mais lié aux librairies situées dans /usr/local/lib et autant vous dire, vous n'aurez jamais cette librairie présente sur vos machines Solaris.

Pour cette raison, nous allons donc générer un binaire statique pour ne plus avoir de dépendance sur openssl. Pour se faire, se rendre dans le répertoire src et relancer manuellement la compilation de nrpe avec la commande suivante :

gcc -g -O2 -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include -DHAVE_CONFIG_H -o nrpe-static \
  nrpe.c utils.c -lsocket -L/usr/local/ssl/lib  /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a \
  -lnsl -lsocket  ./snprintf.o

Pour info, voici le résultat sous Solaris 10 :

$ ls -l nrpe nrpe-static
-rwxr-xr-x   1 root     root      118888 mars 19 14:42 nrpe
-rwxr-xr-x   1 root     root     1349532 mars 19 14:41 nrpe-static

Le binaire est maintenant parfaitement fonctionnel. Il ne vous reste plus qu'à le déployer sur vos machines.