Multiple vs single datasource sous pnp4nagios
Voici maintenant quelques temps que nous utilisons pnp4nagios et je n'avais - jusqu'à maintenant - pas eu à me plaindre de ce produit plus que ça. Malheureusement, aujourd'hui, je suis tombé sur un os : la gestion des données de performances changeante. Dit comme ça, ça peut ne pas sembler complètement évident mais vous allez très vite comprendre que ça peut devenir embêtant ...
Sous nagios, les données de performances (ce qu'on retrouve après le '|' sous la forme param1=i;warn-i;crit-i;min-i;max-i param2=j) est en principe tout le temps identique. Malheureusement, vous l'aurez deviné, les choses ne sont pas toujours simple et vous pouvez rencontrer des commandes qui à un moment vous donnez un certain résultat et qui le moment d'après vous sorte un résultat d'une autre forme. Ce type de désagrément arrive dans les cas suivants :
- changement du comportement d'un script
- changement des indicateurs surveillés (comme dans check_disk par exemple).
Dans ce cas, pnp4nagios perd un peu la boule et du coup, remplace des séries de données par d'autre et plus embêtant, fait un mélange in fine entre les différentes séries. Ce petit désagrément m'est arrivé cet après-midi et j'ai donc regarder un peu si j'étais la seule personne a qui c'était arrivé. Donc en épluchant la documentation, j'ai compris qu'il s'agissait de l'utilisation des datasources de type SINGLE vs MULTIPLE sous RRD. Plus simplement, dans le cas d'un RRD SINGLE (par défaut), toutes les données sont stockées dans un seul fichier. Très pratique pour réduire le bazard dans un répertoire. En revanche, dès que mes sources changent, c'est l'anarchie. L'autre option MULTIPLE quand à elle va créer un datasource par source de données.
C'est bien beau vous allez me dire mais qu'est ce que je fais du coup de mes 6 mois d'historique ? Et bien là, mauvaise nouvelle pour l'instant, il faudra restaurer le fichier avant le changement de datasource ... Ensuite, le script rrd_convert.pl est là pour faire le découpage des fichiers et - cerise sur le gateau - positionner un fichier de configuration dans le répertoire etc/check_commands de pnp4nagios afin de préciser au script process_perfdata.pl de ne plus utiliser un datasource SINGLE mais MULTIPLE.
Ci-dessous, quelques exemples de l'utilisation de cette commande :
- Consultation des commandes disponibles :
- Etat des indicateurs sur mon nagios de test avant conversion :
- Lancement de la conversion :
- Etat après la conversion :
$ ls -ltr Current_Load*
Le fichier Current_Load.rrd existe toujours, mais au vu de la date du fichier, il n'est plus alimenté. Nous pouvons également jeter un coup d'oeil dans le répertoire etc/check_commands de pnp4nagios :
Comme nous pouvons le voir, l'outil rrd_convert.pl a bien créé un fichier pour la commande check_load afin de lui indiquer que le type de stockage étant maintenant MULTIPLE.
Demain, nous testerons ça sur des vrais données de recette !
Sous nagios, les données de performances (ce qu'on retrouve après le '|' sous la forme param1=i;warn-i;crit-i;min-i;max-i param2=j) est en principe tout le temps identique. Malheureusement, vous l'aurez deviné, les choses ne sont pas toujours simple et vous pouvez rencontrer des commandes qui à un moment vous donnez un certain résultat et qui le moment d'après vous sorte un résultat d'une autre forme. Ce type de désagrément arrive dans les cas suivants :
- changement du comportement d'un script
- changement des indicateurs surveillés (comme dans check_disk par exemple).
Dans ce cas, pnp4nagios perd un peu la boule et du coup, remplace des séries de données par d'autre et plus embêtant, fait un mélange in fine entre les différentes séries. Ce petit désagrément m'est arrivé cet après-midi et j'ai donc regarder un peu si j'étais la seule personne a qui c'était arrivé. Donc en épluchant la documentation, j'ai compris qu'il s'agissait de l'utilisation des datasources de type SINGLE vs MULTIPLE sous RRD. Plus simplement, dans le cas d'un RRD SINGLE (par défaut), toutes les données sont stockées dans un seul fichier. Très pratique pour réduire le bazard dans un répertoire. En revanche, dès que mes sources changent, c'est l'anarchie. L'autre option MULTIPLE quand à elle va créer un datasource par source de données.
C'est bien beau vous allez me dire mais qu'est ce que je fais du coup de mes 6 mois d'historique ? Et bien là, mauvaise nouvelle pour l'instant, il faudra restaurer le fichier avant le changement de datasource ... Ensuite, le script rrd_convert.pl est là pour faire le découpage des fichiers et - cerise sur le gateau - positionner un fichier de configuration dans le répertoire etc/check_commands de pnp4nagios afin de préciser au script process_perfdata.pl de ne plus utiliser un datasource SINGLE mais MULTIPLE.
Ci-dessous, quelques exemples de l'utilisation de cette commande :
- Consultation des commandes disponibles :
$ /usr/share/pnp4nagios/libexec/rrd_convert.pl --list_commands
XML Files analyzed 14
XML Files found 0
Old XML Files ignored 1
Number of unique check_commands 7
\\ List of Check Commands
|- check-host-alive 7
|- 2
|- check_ping 1
|- check_load 1
|- check_all_disks 1
|- check_users 1
|- check_http 1
- Etat des indicateurs sur mon nagios de test avant conversion :
$ ls -ltr Current_Load.*
total 6084
-rw-rw-r-- 1 nagios nagios 1151496 2010-05-19 20:46 Current_Load.rrd
-rw-rw-r-- 1 nagios nagios 12872 2010-05-19 20:46 Current_Load.xml
- Lancement de la conversion :
$ /usr/share/pnp4nagios/libexec/rrd_convert.pl --check_command=check_load
Search pattern check_load
XML Files analyzed 14
XML Files found 1
Old XML Files ignored 1
Number of unique check_commands 7
Start Converter [n|Y]?:Y
Config for command check_load created (/usr/share/pnp4nagios/etc//check_commands/check_load.cfg)
File 1/1
RRDtool dump to /tmp/rrd_convert/localhost-Current_Load.dump
Manipulating /tmp/rrd_convert/localhost-Current_Load.dump
............ done 48166 lines
Restoring File
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load1.rrd
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load15.rrd
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load5.rrd
... done
DONE
\\Statistics:
|- runtime 3.048887
|- rrd_out 3
|- old_xml 1
|- rrd_in 1
- Etat après la conversion :
$ ls -ltr Current_Load*
-rw-rw-r-- 1 nagios nagios 1151496 2010-05-19 20:51 Current_Load.rrd
-rw-rw-r-- 1 nagios nagios 12840 2010-05-19 21:21 Current_Load.xml
-rw-r--r-- 1 nagios nagios 384952 2010-05-19 21:21 Current_Load_load5.rrd
-rw-r--r-- 1 nagios nagios 384952 2010-05-19 21:21 Current_Load_load1.rrd
-rw-r--r-- 1 nagios nagios 384952 2010-05-19 21:21 Current_Load_load15.rrd
Le fichier Current_Load.rrd existe toujours, mais au vu de la date du fichier, il n'est plus alimenté. Nous pouvons également jeter un coup d'oeil dans le répertoire etc/check_commands de pnp4nagios :
$ more /usr/share/pnp4nagios/etc/check_commands/check_load.cfg
# Generated by rrd_convert.pl 0.6.3
RRD_STORAGE_TYPE = MULTIPLE
Comme nous pouvons le voir, l'outil rrd_convert.pl a bien créé un fichier pour la commande check_load afin de lui indiquer que le type de stockage étant maintenant MULTIPLE.
Demain, nous testerons ça sur des vrais données de recette !
