Import des données de ndoutils dans pnp4nagios

Il y a de ça 5 ou 6 mois, j'ai procédé à un refresh à notre infrastructure de suivi nagios. A l'époque nous utilisions un nagios couplé avec NDOUtils pour faire notre suivi de tendance des machines. J'avais par ailleurs créé un plugin permettant de grapher tout ceci en me basant sur la bibliothéque JPGraph.

Malheureusement, entre les problèmes sur la base de données, le fait que je sois sur Solaris (chouette encore un truc à compiler), les problèmes liés au broker nagios (pourquoi ce foutu machin ne veut pas se reconnecter à la base !!!), les problèmes de performance de la base (j'avais mis en place un système de rotation de la table nagios_servicechecks pour m'affranchir des problèmes de dégradation des performances avec le temps), la taille de tout ceci (200 Mo de place par jour pour 600 services !) et le plugin de graph à maintenir, j'ai fini par péter un cable !

Bref, à l'occasion d'un plan de refresh de ma machine, je suis tombé sur pnp4nagios et là, j'ai sérieusement réfléchi à me débarrasser de NDOUtils. En revanche, un point m'embêter : perdre mon historique de 100 jours de l'ancienne base MySQL. J'ai donc à ce moment pensé à utiliser les possibilités d'insertion en mode bulk de pnp4nagios afin de reconstituer mon historique.

Au démarrage, j'ai procédé par une extraction via un ensemble de scripts shells. J'ai ensuite procédé à un refactoring de ce script afin de le réécrire en perl que j'ai ensuite proposé à l'équipe de pnp4nagios. Ils m'ont simplement proposé de le déposer sur leur wiki à l'emplacement suivant.

Le script en question s'appelle ndo2pnp.pl et vous trouverez ci-dessous l'aide en ligne disponible sur l'outil :

$ ./ndo2pnp.pl --help
Usage :
-h  --help            Display this message.
    --version         Display version then exit.
-v  --verbose         Verbose run.
-u  --user ndouser    Log on to database with ndouser (default root).
-p  --pass passwd     Use passwd to logon (default gbu2kfe).
-t  --type dbtype     Change database type (default mysql).
    --host dbhost     Use dbhost (default localhost).
    --dbname db       Use db for ndo database name (default ndoutils).
    --list-machine    Display machine definition in ndo database.
    --list-service    Show services defined.
    --export-as-pnp   Export ndo content as a bulk file used by process_perfdata.pl.
>

Globalement, pour procéder à votre export/import, il faut suivre les étapes suivantes :

• Extraction du contenu de la base : ./ndo2pnp.pl --user mysql_user -p mysql_pass --export-as-pnp > /tmp/perfdata.bulk


• Import de l'extraction :/usr/share/pnp4nagios/libexec/process_perfdata.pl -b /tmp/perfdata.bulk --timeout 0

Quoi ? C'est tout ! Euh, juste une petite précision : l'import a duré 4 jours sur ma machine de production :). Un conseil : essayez de faire des extracts machine par machine (avec l'option --machines MAMACHINEAEXTRAIRE ou --services MESSERVICESAEXTRAIRE que j'ai oublié de documenté d'ailleurs ... Pas beau !). Les imports seront du coup moins long à faire (et éventuellement en parallèle) et peuvent vous donner une idée du résultat final sans avoir à vous coltiner l'intégralité de l'import de vos données.

Le résultat de tout ceci se trouve ci-dessous :


Toute la partie de décembre à février et le résultat de l'import (plus les quelques jours parasites d'octobre et novembre, date à laquelle nous avions eu des soucis avec la base MySQL). Vous remarquerez qu'entre temps, la base s'est alimentée avec de nouvelles valeurs.

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.

Personnalisation de PNP4Nagios : écriture d'un template

L'import de mon historique ndoutils sous pnp4nagios s'est bien passé et j'ai maintenant quelques courbes avec lesquels je peux m'amuser. J'ai notamment personnalisé l'aspect des courbes CPU afin d'y faire apparaître une tendance sur une certaine période. Pour info, j'ai mis à disposition le plugin à l'emplacement suivant : http://docs.pnp4nagios.org/templates/check_cpu

Nous allons voir ensemble comment fonctionne la création de template pour pnp4nagios. Pour cela, il suffit de se rendre dans le répertoire de pnp4nagios dans le sous-répertoire share/templates. De là, on va créer un nouveau fichier et nous allons commencer à personnaliser l'aspect de nos graphiques (ici check_cpu.php).

Ce qu'il faut savoir avant de commencer est que l'interface pnp4nagios génère des fichiers PNG à l'aide des RRDTools. Notre template est donc en réalité un petit programme en PHP qui initialisera les valeurs envoyé au programme RRDTool.

Commençons tout d'abord par changer le titre de notre graphique :

#
# Copyright (c)  2010 Yannig Perre
# Plugin: check_cpu
#
$ds_name[1] = "Activité CPU";

$opt[1] = "--vertical-label CPU -l0  --title \"Activité CPU sur $hostname\" ";

Nous allons maintenant définir les périodes pendant lesquelles nous allons dessiner une tendance :

$trend_array = array(
  "one_month"    => array(strtotime("-1 month", $this->TIMERANGE['end']), $this->TIMERANGE['end'], "Tendance sur 1 mois:dashes=10", "#FF007F", "LINE3"),
  "global_trend" => array($this->TIMERANGE['start'], $this->TIMERANGE['end'], "Tendance globale:dashes=20", "#707070", "LINE2"),
);

Ci-dessous, nous définissons simplement les sources de notre graphique.

NB : Nous allons cumuler les valeurs des sources afin d'obtenir un graphique sous forme d'aire (io en haut du graphique, user puis consommation système). Pour se faire nous utilisons la notion de CDEF des outils RRDs :

$def[1] =  "DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE " ;
$def[1] .= "DEF:var2=$RRDFILE[2]:$DS[2]:AVERAGE " ;
$def[1] .= "CDEF:user=var2,var1,+ " ;
$def[1] .= "DEF:var3=$RRDFILE[3]:$DS[3]:AVERAGE " ;
$def[1] .= "CDEF:io=var3,var2,+,var1,+ " ;

Une fois nos sources redéfinies, nous allons maintenant définir nos tendances en fonction du tableau $trend_array que nous avons définit précédemment :

$trend_elements = "";

foreach(array_keys($trend_array) as $trend) {
  $def[1] .= "DEF:var1$trend=$RRDFILE[1]:$DS[1]:AVERAGE:start=".$trend_array[$trend][0]." ";
  $def[1] .= "DEF:var2$trend=$RRDFILE[2]:$DS[2]:AVERAGE:start=".$trend_array[$trend][0]." ";
  $def[1] .= "CDEF:user$trend=var2$trend,var1$trend,+ " ;

  $def[1] .= "VDEF:dtrend$trend=user$trend,LSLSLOPE ";
  $def[1] .= "VDEF:htrend$trend=user$trend,LSLINT ";
  $def[1] .= "CDEF:curve_user$trend=user$trend,POP,dtrend$trend,COUNT,*,htrend$trend,+ ";
  $trend_elements .= $trend_array[$trend][4].":curve_user$trend".$trend_array[$trend][3].":\"".$trend_array[$trend][2]."\" " ;
}

Ici, on rajoute les valeurs de warning et critical si présente :

if ($WARN[1] != "") {
    $def[1] .= "HRULE:$WARN[1]#FFFF00 ";
}
if ($CRIT[1] != "") {
    $def[1] .= "HRULE:$CRIT[1]#FF0000 ";       
}

Enfin, nous allons dire aux RRD tools de dessiner 3 graphiques d'aire : les io en premier (en vert), la consommation user en bleu et enfin la consommation système en dernier. A noter que nous ajoutons des lignes noirs pour mieux définir les 3 aires.

$def[1] .= "AREA:io#00FF00:\"iowait\" " ;
$def[1] .= "GPRINT:var3:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var3:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var3:MAX:\"max %6.2lf\\n\" " ;
$def[1] .= "AREA:user#005CFF:\"user  \" " ;
$def[1] .= "GPRINT:var1:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var1:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var1:MAX:\"max %6.2lf\\n\" ";
$def[1] .= "AREA:var2#FF5C00:\"sys   \" " ;
$def[1] .= "GPRINT:var2:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var2:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var2:MAX:\"max %6.2lf\\n\" " ;
$def[1] .= "LINE1:io#000000:\"\" " ;
$def[1] .= "LINE1:user#000000:\"\" " ;
$def[1] .= "LINE1:var2#000000:\"\" " ;
$def[1] .= $trend_elements;

Voici notre fichier template terminée, il ne nous reste plus qu'à consulter le résultat sur l'interface PNP. Voici ce que j'obtiens par exemple après quelques petits réglages au niveau de la tendance sur une de mes machines sur 6 mois d'historique :

Import en cours

J'ai lancé mon script d'import de ma base ndo MySQL vers pnp4nagios. J'ai compté, il y en a pour environ 25 minutes par jour et j'ai environ 130 jours à importer. Après avoir parallélisé un peu les traitements j'ai réussi à descendre à 15 minutes pour chaque jour. Chouette, ça me fera donc environ 30 heures d'import ...

Courage ! On va y arriver.