Menu
- PNP4Nagios 0.6.x
- PNP4Nagios 0.4.x
Le travail sur la version 0.6.x est toujours en cours.
Depuis la version 0.6.x nous sommes passés de subversion à GIT. Le code source est disponible chez sourceforge.
Fonctionnalités déjà présentes
PNP a besoin de données de performance valides de la part des plugins nagios.
Mais qu'appelle t'on les données de performance ?
Les sorties des plugins en nagios jusqu'à la version 2.x sont limitées à une ligne. Quand le plugin donne des données de performance, la sortie se scinde en deux parties. Le pipe (“|”) sert à délimiter ces deux parties.
Exemple check_icmp :
OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;
Voici la partie à gauche du pipe :
OK - 127.0.0.1: rta 2.687ms, lost 0%
et ci-dessous les données de performance :
rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;
Les données de performance sont conçues pour être traitées automatiquement. Le format est spécifié dans le document Guide du développeur (vous trouverez rapide du format à cet emplacement). Voici néanmoins un petit récapitulatif de la norme :
rta=2.687ms;3000.000;5000.000;0; | | | | | | | |----|--|----|---------|-----|-|----- * labelle |--|----|---------|-----|-|----- * valeur courante |----|---------|-----|-|----- unité (UOM = UNIT of Measurement) |---------|-----|-|----- seuil de l'alerte warning |-----|-|----- seuil de l'alerte critique |-|----- valeur minimum |----- valeur maximum
Les champs marqués avec * sont obligatoires. Tous les autres sont optionnels.
Plusieurs séries de données peuvent être spécifiées en les séparant par des espaces. Si le label contient des blancs, il faut l'entourer de quote simple (').
PNP est sous licence GPL 2
Le développement de PNP s'organise autour de Sourceforge.Net. PNP est enregistré sous le nom “PNP4nagios”.
La version stable 0.4.x actuelle est disponible à l'emplacement suivant : Sourceforge Download
Vous pouvez également utiliser la dernière version de développement de la 0.4.x qui est générée automatiquement chaque jour depuis notre dépot SVN.
Depuis la version PNP 0.6.x, le code source est passé de SVN à GIT.
La version actuelle de développement peut être consultée à tout moment sur http://pnp4nagios.git.sourceforge.net/. En cliquant sur version de développement PNP téléchargera une archive avec la dernière version.
AVANT de demander du support, merci de vous assurer d'avoir vérifié certaines choses dans l'article vérification de votre installation.
Les développeurs et les contributeurs sont également présents sur http://www.nagios-portal.org et seront tenus au courant de nouveaux posts dans la section PNP. Il vous sera demandé de poster en anglais.
Après vous être enregistré en tant qu'utilisateur, compléter votre profil en précisant la version de votre OS ainsi que la version de PNP. Précisez également si vous utilisez un package de la distribution ou si vous avez compilé le programme par vous même.
Une fois votre problème résolu, merci de marquer le titre de votre post avec ”[solved]”. Cela aidera les autres utilisateurs à trouver une solution à leur problème.
Les mailing lists sur Sourceforge peuvent-être utilisées pour obtenir du support (merci de formuler vos demandes en anglais) :
pnp4nagios-users: mailing-list des utilisateurs pour les questions sur la configuration. Merci de bien préciser votre version d'OS ainsi que la version de PNP.
pnp4nagios-devel: mailing-list de développement pour les demandes de fonctionnalités ou les rapports de bug. Merci de bien préciser votre version d'OS ainsi que la version de PNP.
pnp4nagios-checkins: mailing-list du suivi de l'activité du développement.
Les données de performance sont stockées en base RRD (RRDtool). Ceci veut dire que vos vieilles données à la fin du fichier RRD se feront remplacées par de nouvelles valeurs au début du fichier.
Il existe plusieurs intervalles avec différentes résolutions. Les valeurs par défaut permettent de stocker une valeur toutes les minutes pendant deux jours, une valeur toutes les 5 minutes pendant 10 jours, une valeur toutes les 1/2 heures pendant 90 jours et une valeur toutes les 6 heures pendant 4 ans. L'augmentation de l'intervalle va provoquer l'agrégation des valeurs ayant pour conséquence de réduire les valeurs max. Ceci n'est pas un bug de PNP.
L'utilisation de ce format garantie que la taille des fichiers ne changera pas au cours du temps. Chaque source de données prendra environ 400 Ko.
PNP supporte plusieurs modes d'insertion des données de performance. Les différences présentent entre les différents modes seront fonction de la complexité ainsi que des besoins de performances.
L'image suivante montre la connexion entre nagios, PNP et RRDtool
Nagios appelle une commande pour chaque machine et chaque service sur lesquels les données de performance doivent être récupérées. En fonction du mode de fonctionnement, les données seront passées directement à process_perfdata.pl ou seront écrites dans un fichier temporaire pour être traitées plus tard. process_perfdata.pl écrit les méta-données dans des fichiers XML et stockent les données de performance dans des fichiers RRD via l'utilisation de RRDtool.
Avant de choisir un mode, veuillez vous référer à la documentation afin de choisir la meilleure solution pour votre installation.
Le “mode synchrone” est le plus simple à mettre en œuvre. Nagios appellera le script perl
process_perfdata.pl
pour traiter les données de chaque service et machine. Le mode synchrone devrait fonctionner correctement jusqu'à environ 1.000 services avec un intervalle de test toutes les 5 minutes.
En mode bulk (par paquet), Nagios écrit les données de performance dans un fichier temporaire. Après un certain laps de temps défini, le fichier sera traité en un seul bloc puis sera supprimé.
Le nombre d'appels à process_perfdata.pl est ainsi grandement réduit. En fonction du temps et du nombre de données à récolter, vous aurez beaucoup moins d'appels. Attention toutefois, process_perfdata.pl mettra plus de temps à se lancer.
NB Si vous utilisez ce mode, gardez un oeil sur le temps pris par process_perfdata.pl pour se lancer. En effet, pendant ce temps, nagios ne lancera aucune exécution.
extrait du fichier var/perfdata.log :
2007-10-18 12:05:01 [21138] 71 Lines processed 2007-10-18 12:05:01 [21138] .../spool/service-perfdata-1192701894-PID-21138 deleted 2007-10-18 12:05:01 [21138] PNP exiting (runtime 0.060969s) ...
71 lignes ont été traitées en 0.06 seconde. Il s'agit ici de la quantité de données générés par 2000 services en utilisant un intervalle d'exécution de 10 secondes. Cela veut dire que nous avons bloqué nagios pendant exactement 0.06 secondes.
De tous les points de vue, il s'agit de la méthode bloquant le moins le process nagios.
Nagios utilise toujours un fichier temporaire pour stocker ses données et exécute régulièrement une commande. Au lieu de lancer directement le traitement avec process_perfdata.pl, le fichier est déplacé dans un répertoire spool. Comme le déplacement d'un fichier est pour ainsi dire instantané, Nagios peut donc continuer à travailler sur des tâches essentielles.
Le démon NPCD (Nagios Performance C Daemon) surveillera le contenu du répertoire et passera au script process_perfdata.pl les nouveaux fichiers. Dans ce mode, la gestion des données de performance est complétement découplée du fonctionnement de nagios. NPCD est capable de lancer plusieurs threads de traitement afin de traiter les données.
Ici npcdmod.o est un module NEB. Ce module réduit la configuration du “mode bulk avec NPCD” de deux lignes dans nagios.cfg
Ce mode est similaire au “mode bulk avec NPCD” et il a exactement les mêmes fonctionnalités avec les mêmes performances.
Le mode à mettre en oeuvre dépendra de la taille de la configuration de votre nagios. Vous trouverez des éléments de réponse tout au long de la documentation.
Vous avez accès aux derniers changements sur pnp4nagios.git.sourceforge.net
La dernière version est pnp4nagios-0.6.7.tar.gz
Vous obtiendrez la dernière version de la branche GIT HEAD.
Dernière mise à jour: Vendredi 12 Aout 13:55:01 CEST 2011
pnp-0.6.15 ??/??/2011
pnp-0.6.14 08/05/2011
pnp-0.6.13 05/19/2011
pnp-0.6.12 04/22/2011
pnp-0.6.11 01/15/2011
pnp-0.6.10 12/15/2010
pnp-0.6.7 09/27/2010
pnp-0.6.6 08/07/2010
pnp-0.6.5 07/09/2010
pnp-0.6.4 06/03/2010
pnp-0.6.3 03/16/2010
pnp-0.6.2 12/23/2009
pnp-0.6.1 11/22/2009
pnp-0.6.0 10/30/2009
L'interface web a été complètement réécrite et est maintenant basée sur le gestionnaire PHP Kohana. Ce changement a eu des conséquences sur les dépendances qui doivent être vérifiées avant la mise à jour.
NB: Dans un premier temps, la mise à jour fonctionne comme une nouvelle installation. Ce n'est qu'après que nous verrons les changements spécifiques.
Auparavant, si nous n'utilisions aucune option avec le ./configure
, PNP s'installait par défaut dans /usr/local/nagios
.
Dorénavant, le ./configure
de PNP 0.6.x s'installe dans le répertoire /usr/local/pnp4nagios
. Il est donc maintenant vu comme une application à part.
NB: Il suffit simplement de recopier les anciens fichiers rrd de l'ancien emplacement au nouveau. Ce sont eux qui contiennent les données. Pour les fichiers *.xml, ces derniers sont recréés à chaque mise à jour. Comme la structure interne de ces fichiers a changé, vous ne pourrez pas les utiliser tel quel.
Sommaire d'une installation de PNP 0.4.14 :
./configure ... *** Configuration summary for pnp 0.4.14 05-02-2009 *** General Options: ------------------------- ------------------- Nagios user/group: nagios nagios Install directory: /usr/local/nagios HTML Dir: /usr/local/nagios/share/pnp Config Dir: /usr/local/nagios/etc/pnp Location of rrdtool binary: /usr/bin/rrdtool Version 1.3.1 RRDs Perl Modules: FOUND (Version 1.3001) RRD Files stored in: /usr/local/nagios/share/perfdata process_perfdata.pl Logfile: /usr/local/nagios/var/perfdata.log Perfdata files (NPCD) stored in: /usr/local/nagios/var/spool/perfdata/
Sommaire d'une installation PNP 0.6.0 :
./configure ... *** Configuration summary for pnp4nagios-0.6.0 07-30-2009 *** General Options: ------------------------- ------------------- Nagios user/group: nagios nagios Install directory: /usr/local/pnp4nagios HTML Dir: /usr/local/pnp4nagios/share Config Dir: /usr/local/pnp4nagios/etc Location of rrdtool binary: /usr/bin/rrdtool Version 1.3.1 RRDs Perl Modules: FOUND (Version 1.3001) RRD Files stored in: /usr/local/pnp4nagios/var/perfdata process_perfdata.pl Logfile: /usr/local/pnp4nagios/var/perfdata.log Perfdata files (NPCD) stored in: /usr/local/pnp4nagios/var/spool Web Interface Options: ------------------------- ------------------- HTML URL: http://localhost/pnp4nagios/ Apache Config File: /etc/apache2/conf.d/pnp4nagios.conf
Regardez bien ces lignes de paramètres et si elles correspondent bien à votre stratégie de migration.
Les paramètres de l'option action_url ont changés. Au lieu de ”/nagios/pnp”, l'URL est devenue ”/pnp4nagios” et au lieu de “index.php”, il faut maintenant utiliser “graph”.
define host { name host-pnp register 0 action_url /pnp4nagios/graph?host=$HOSTNAME$ } define service { name srv-pnp register 0 action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$ }
La définition du popup de prévisualisation a changée de la même manière :
define host { name host-pnp action_url /pnp4nagios/graph?host=$HOSTNAME$' class='tips' rel='/pnp4nagios/popup?host=$HOSTNAME$ register 0 } define service { name srv-pnp action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$' class='tips' rel='/pnp4nagios/popup?host=$HOSTNAME$&srv=$SERVICEDESC$ register 0 }
Attention: Ce n'est pas une erreur que la chaîne avant et après “class” ne contienne qu'un seul quote (').
Ceci peut-être utilisé indifféremment avec Nagios 2.x et 3.x.
Les variables dans les fichiers du répertoire template doivent être absolument initialisées avant la première utilisation.
Exemple :
$lower = ""
Auparavant, vous étiez en mesure de concaténer des variables qui n'étaient pas initialisées.
Exemple:
foreach ($DS as $i) { $def[1] .= "DEF:var$i=$rrdfile:$DS[$i]:AVERAGE " ;
Il faut maintenant changer ceci en :
$def[1] = ""; foreach ($DS as $i) { $def[1] .= "DEF:var$i=$rrdfile:$DS[$i]:AVERAGE " ;
Les constantes dans les fichiers de template ne fonctionnent plus. Il faut maintenant les convertir en variables :
define("_WARNRULE", '#FFFF00');
sera changé en
$WARNRULE = '#FFFF00';
Il faudra, bien sûr, penser à changer toutes les occurrences de votre constante .
/usr/local/pnp4nagios
/pnp4nagios
vous renverra que les répertoires de données de performance vides/usr/local/pnp4nagios/etc/npcd.cfg
depuis npcd.cfg-sample
/etc/init.d/npcd stop
make install-init
installe le nouveau script init de npcd/etc/init.d/nagios stop
/usr/local/nagios/share/perfdata
to /usr/local/pnp4nagios/var/perfdata
. Attention: faîtes gaffe aux permissions !/etc/init.d/npcd start
/etc/init.d/nagios start
Nous allons expliquer comment installer PNP4Nagios ci-dessous. Pour suivre ce document il faut que nagios fonctionne et soit installé dans /usr/local/nagios .
Attention: L'article ci-dessous a été écrit pour la version développeur PNP 0.6.0.
Merci de noter que PNP doit être configuré après l'installation.
L'installation de PNP est contrôlée par makefiles. Après avoir lancé ./configure, votre système est analysé et les variables sont transférées aux makefiles.
Décompressez PNP en tant qu'utilisateur root:
tar -xvzf pnp4nagios-HEAD.tar.gz cd pnp4nagios
Lancez ./configure à partir du répertoire pnp4nagios.
./configure
Note: Si l'on ne spécifie aucune option, l'utilisateur et le groupe par défaut seront “nagios”. Si vous avez configuré un autre utilisateur pour faire fonctionner Nagios, vous devez utiliser les paramètres suivants ”--with-nagios-user” et ”--with-nagios-group”, respectivement. Avec un utilisateur et un groupe de nom icinga, la commande est
./configure --with-nagios-user=icinga --with-nagios-group=icinga
Une fois lancé, des lignes vont défiler à l’écran. Les dernières lignes ci-dessous sont importantes.
*** Configuration summary for pnp4nagios-0.6.2 23-12-2009 *** General Options: ------------------------- ------------------- Nagios user/group: nagios nagios Install directory: /usr/local/pnp4nagios HTML Dir: /usr/local/pnp4nagios/share Config Dir: /usr/local/pnp4nagios/etc Location of rrdtool binary: /usr/bin/rrdtool Version 1.2.12 RRDs Perl Modules: FOUND (Version 1.2012) RRD Files stored in: /usr/local/pnp4nagios/var/perfdata process_perfdata.pl Logfile: /usr/local/pnp4nagios/var/perfdata.log Perfdata files (NPCD) stored in: /usr/local/pnp4nagios/var/spool Web Interface Options: ------------------------- ------------------- HTML URL: http://localhost/pnp4nagios/ Apache Config File: /etc/apache2/conf.d/pnp4nagios.conf Review the options above for accuracy. If they look okay, type 'make all' to compile.
Les chemins doivent être vérifiés. Si les chemins affichés ne sont pas corrects, ils doivent être modifiés en utilisant ./configure avec les options appropriées.
Attention: “Location of rrdtool binary” veut dire le chemin avec le nom de l’exécutable! Si nécessaire, il peut être spécifié en utilisant la syntaxe suivantes:
./configure --with-rrdtool=/usr/local/rrdtool-1.2.xx/bin/rrdtool
./configure --help
Montre toutes les options supportées.
Lancer
make all
compile les composants comme NPCD qui sont écrits en C.
make install
copie tous les fichiers au bon endroit dans votre système de fichiers. Les chemins utilisés sont ceux qui vous ont été montrés lors de l'utilisation de la commande ./configure.
Après l'installation du programme et des fichiers HTML, vous pouvez copier l'exemple de configuration dans le dossier de configuration de votre serveur web
make install-webconf
Optionnellement, le lancement de make install-config, vous copie les fichiers de configuration pour process_perfdata.pl et npcd dans etc/pnp.
make install-config
Pour installer le script de lancement automatique d'NPCD lors du démarrage du serveur, lancez:
make install-init
Pour lancer toutes les commandes précédentes les unes après les autres, lancez:
make fullinstall
Attention: Après avoir copié les fichiers de configuration du serveur web, vous devez redémarrer votre serveur web (service httpd restart
ou /etc/init.d/apache2 restart
, selon votre distribution).
La mise a jour vers la version 0.6.x se passe (à peut prêt) de la même manière que l'installation.
Notez que vous devez invoquez ./configure
avec les mêmes options que vous aviez utilisées lors de la première installation.
Vérifiez si vous avez fait des changements dans share/templates.dist
. Vos templates perso doivent être placées dans le dossier share/templates
pour ne pas être écrasées.
Attention: Si vous avez changé config.php vous devez en faire une sauvegarde avant qu'il ne soit écrasé par la commande make install-config
.
Vous pouvez ignorer make install-webconf
et make install-init
car rien ne change entre les différentes versions 0.6.x.
Après l'installation tous les composants de PNP on été copiés dans les emplacements suivants:
Les fichiers PHP pour l'interface web dans
/usr/local/pnp4nagios/share/pnp
Le script process_perfdata.pl dans
/usr/local/pnp4nagios/libexec
Les examples de configuration avec le suffixe -sample
dans
/usr/local/pnpnagios/etc
Le fichier de config config.php pour l'interface web dans
/usr/local/pnp4nagios/etc
La configuration des différences modes des traitements des données de performance va être expliquée ci-dessous.
Le mode synchronisé est le plus simple pour intégrer le collecteur de données
process_perfdata.pl
dans nagios. Tous les évènements vont déclencher l'exécution de process-service-perfdata
.
Dans un premier temps, vous devez activer la collecte des données de performance (process_performance_data
) dans le fichier nagios.cfg
. Notez que cette directive est sûrement déjà présente et configurer par défaut à “0”.
process_performance_data=1
La collecte des données de performance doit être désactivée dans la définition de chaque Host ou service pour lequel vous NE SOUHAITEZ PAS collecter ces données.
define service { ... process_perf_data 0 ... }
Depuis Nagios 3.x il est possible de désactiver l'export des variables d'environnement (Pour optimiser au maximum les performances du système). Malheureusement cette directive doit être activée pour permettre l'utilisation du mode synchronisé. Soit vous utilisez la valeur par défaut (ce qui veut dire que l'export est activé) ou vous pouvez définir la directive dans nagios.cfg
enable_environment_macros=1
En plus de cela, la commande pour traiter les données de performance doit être spécifiée dansnagios.cfg
service_perfdata_command=process-service-perfdata
Depuis la version 3.0 de Nagios, il peut être utile d'activer également l'analyse des performances pour les Hosts. Due au changement de logique pour la vérification des Hosts, Nagios 3 effectue désormais des contrôles réguliers.
host_perfdata_command=process-host-perfdata
La nouvelle commande doit également être référencée dans la configuration de Nagios. Si vous avez utilisé le guide d'installation rapide pour installer Nagios, alors vous pouvez modifier la définition dans le fichier commands.cfg. La commande process_perfdata.pl n'a pas besoin d'argument à part l'option -d ( DATATYPE ) si vous voulez analyser les performances résultant de la vérification des hosts.
define command { command_name process-service-perfdata command_line /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl } define command { command_name process-host-perfdata command_line /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA }
Note: process_perfdata.pl
ne peut pas tourner sous ePN ( embedded Perl Nagios ). Dans ce cas le script doit être appelé en utilisant /usr/bin/perl
( ou le chemin où est installé l'exécutable perl). Si vous utilisez Nagios 3.x ou n'utilisez pas ePN, il n'y a pas besoin de spécifier /usr/bin/perl
.
Bulk mode est un mode un peu plus compliqué que le mode synchronisé mais reduit clairement la charge sur le serveur Nagios car le collecteur de données
process_perfdata.pl
n'est pas appelé à chaque vérification de service/host.
In bulk mode, Nagios écrit les données dans un fichier temporaire dans un format bien défini. Ce fichier est traité par process_perfdata.pl
à intervalle régulier. Nagios prend en charge le démarrage et le lancement périodique.
Le traitement des performances doit être activé dans nagios.cfg
process_performance_data=1
de plus que quelque directives doivent être ajoutées:
# # service performance data # service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$ service_perfdata_file_mode=a service_perfdata_file_processing_interval=15 service_perfdata_file_processing_command=process-service-perfdata-file # # host performance data starting with Nagios 3.0 # host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$ host_perfdata_file_mode=a host_perfdata_file_processing_interval=15 host_perfdata_file_processing_command=process-host-perfdata-file
Attention: Ces définitions d'exemples diffèrent de celles présentes dans nagios.cfg
!
Les directives et leurs significations:
service_perfdata_file
chemin du fichier temporaire qui vas contenir les données de performance.service_perfdata_file_template
format du fichier temporaire. Les données vont être définies en utilisant les macros Nagios.service_perfdata_file_mode
l'option “a” spécifie que les données doivent être ajoutées au fichier.service_perfdata_file_processing_interval
intervalle de 15 secondesservice_perfdata_file_processing_command
la commande à appeler à chaque intervalle.La commande utilisée doit être annoncée à Nagios. Si vous avez utilisé le "quickstart installation guides" pour Nagios vous pouvez modifier les définitions se trouvant dans commands.cfg.
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 }
NOTE:
process_perfdata.pl
va mettre plus de temps à analyser ces données, donc vous devez vérifier la valeur du TIMEOUT dans etc/process_perfdata.cfg
et l'ajuster comme il se doit.
La configuration est identique au mode Bulk à l'exception de la commande utilisée.
Le traitement des performances doit être activé dans
nagios.cfg
process_performance_data=1
de plus que quelque directives doivent être ajoutées:
# # service performance data # service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$ service_perfdata_file_mode=a service_perfdata_file_processing_interval=15 service_perfdata_file_processing_command=process-service-perfdata-file # # host performance data starting with Nagios 3.0 # host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$ host_perfdata_file_mode=a host_perfdata_file_processing_interval=15 host_perfdata_file_processing_command=process-host-perfdata-file
Attention: Ces définitions d'exemples diffèrent de celles présentes dans nagios.cfg
!
Les directives et leurs significations:
service_perfdata_file
chemin du fichier temporaire qui va contenir les données de performance.service_perfdata_file_template
format du fichier temporaire. Les données vont être définies en utilisant les macros Nagios.service_perfdata_file_mode
l'option “a” spécifie que les données doivent être ajoutées au fichier.service_perfdata_file_processing_interval
intervalle de 15 secondesservice_perfdata_file_processing_command
la commande à appeler à chaque intervalle.
La commande utilisée doit être annoncée à Nagios. Si vous avez utilisé le "quickstart installation guides" pour Nagios vous pouvez modifier les définitions se trouvant dans commands.cfg
.
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$ }
En utilisant ces commandes, le fichier service-perfdata va etre déplacé dans var/spool/ après que le temps spécifié dans service_perfdata_file_processing_interval
soit écoulé. La variable Nagios $TIMET$ est ajoutée à la fin du nom du fichier pour éviter l'écrasement des anciens fichiers éventuellement existants. La variable $TIMET$ contient l'heure et la date actuelle au format time_t (Nombre de secondes depuis le 1 Janvier 1970 “UNIX date format”).
Les fichiers se trouvant dans le dossier /usr/local/pnp4nagios/var/spool/ sont récoltés par le processus NPCD.
NPCD surveille le dossier et passe les noms de fichiers au script process_perfdata.pl
. De cette façon, la collecte des données de performance est complètement indépendante de Nagios.
Before starting NPCD you have to check the paths to the spool directory and to process_perfdata.pl
specified in the config file npcd.cfg
.
The only thing that remains is to start NPCD.
/usr/local/pnp4nagios/bin/npcd -d -f /usr/local/pnp4nagios/etc/npcd.cfg
The option -d
starts NPCD as a daemon in the background.
This mode uses the event broker module npcdmod.o. The flow of data is identical to “bulk mode with NPCD”. The internal perfdata routines of Nagios activated by the “*_perf_data_*” directives in nagios.cfg are *NOT* used anymore. The module npcdmod.o takes over the task of processing the data required by PNP.
Pro:
Adjustments in nagios.cfg:
process_performance_data=1 broker_module=/usr/local/pnp4nagios/lib/npcdmod.o config_file=/usr/local/pnp4nagios/etc/npcd.cfg
All other directives mentioned on this page must NOT be used.
Attention: If you have changed the value of event_broker_options
from -1 to another value then please note that PNP needs the bits 2 and 3 set (0b01100). Make sure that the resultung value has these bits set because otherwise there will be no performance data to process.
After restarting Nagios information regarding the start of the module will be logged.
Excerpt from nagios.log
[1277545053] npcdmod: Copyright (c) 2008-2009 Hendrik Baecker (andurin@process-zero.de) - http://www.pnp4nagios.org [1277545053] npcdmod: /usr/local/pnp4nagios/etc/npcd.cfg initialized [1277545053] npcdmod: spool_dir = '/usr/local/pnp4nagios/var/spool/'. [1277545053] npcdmod: perfdata file '/usr/local/pnp4nagios/var/perfdata.dump'. [1277545053] npcdmod: Ready to run to have some fun! [1277545053] Event broker module '/usr/local/pnp4nagios/lib/npcdmod.o' initialized successfully.
Si tout c'est bien passé jusqu’à présent vous pouvez essayer d’accéder à PNP en lançant votre navigateur web.
Quand vous installez PNP avec les valeurs par défaut vous devriez pouvoir y accéder en utilisant http://<server name>/pnp4nagios/.
La première fois vous allez voir la page “PNP4Nagios Environment Tests” qui inclue différents tests pour vérifier que les composants nécessaires au bon fonctionnement sont bien installés. Evidemment, toutes les vérifications doivent être passées avec succès avant de pouvoir continuer.
Si tous les tests sont passés avec *succès* le fichier pnp4nagios/share/install.php peut être effacé ou renommé. Après cela l'interface web sera accessible.
Vous pouvez également créer un fichier vide, appelé pnp4nagios/share/install.ignore
ce qui aura comme effet de ne pas appeler le vérificateur d'installation au prochain chargement.
Si vous recevez le message “PHP magic_quotes_gpc is deprecated” editez votre php.ini
et assurez vous que “magic_quotes_gpc = Off”, rechargez la configuration de apache pour que les changements prennent effet.
Lancé sans argument, PNP va chercher la base de données RRD et fichiers XML dans pnp4nagios/var/perfdata et afficher tous les graphiques du premier host.
ATTENTION: Après avoir activé l'analyse des données de performance, vous obtiendrez un message d'erreur dans votre navigateur, si vous essayez de visualiser les graphiques avant que nagios n'ait récupéré les premières données de performance et les ait stockées dans la base RRD du service monitoré. Selon l'intervalle de vérification configuré, vous devrez attendre un certain temps avant de pouvoir voir les différents graphiques.
L'appel de make install-config
pendant l'installation, va créer le fichier d’exemple de configuration etc/process_perfdata.cfg-sample
. Les valeurs dans ce fichier correspondent aux valeurs par défaut utilisées par process_perfdata.pl
donc normalement le fichier process_perfdata.cfg
n'existe pas si vous suivez la procédure d'installation normal.
Cependant vous pouvez influencer la façon dont process_perfdata.pl
fonctionne en changeant les options que vous voulez modifier dans process_perfdata.cfg
.
Les options les plus importantes quand on lance PNP sont LOG_LEVEL
et LOG_FILE
. Nous recommandons de configurer la valeur de LOG_LEVEL
à “2” pour que vous puissiez suivre ce que fait process_perfdata.pl
.
Il est très probable que nous demandions un extrait de perfdata.log
si vous ouvrez un ticket avec notre support sur notre mailing lists ainsi le résultat du script verify_pnp_config, donc merci de les inclure .
En temps normal le niveau de debug doit être mis à 0
pour éviter tous problèmes de performance dus à une écriture de logs inutile.
Vérifiez quelques éléments de base.
1. Y a t'il des fichiers RRD et XML qui ont été créés?
process_perfdata.pl
va créer un répertoire sous pnp/perfdata pour chaque host. Dans ce répertoire une base de donnée RRD et un fichier XML vont être créés pour chaque service. Les données de l'host seront stockées dans _HOST_.xml
et _HOST_.rrd
respectivement.
Si l’affichage du graphique stoppe soudainement, alors éditez le fichier XML approprié. Il y a 2 balises appelées <RC> et <TXT>. <RC> montre le code renvoyé par l'outil RRDtool et <TXT> une description texte.
De temps en temps vous devez spécifier des options supplémentaires pour que les données de performance soient gérées correctement. Dans certain cas un wrapper script peut aider.
Attention, tous les scripts de checks ne donnent pas forcément des indicateurs de performance. Ceci s'applique - mais pas seulement - à “check_ping” au contraire de “check_icmp” qui fournit ces données (Depuis la version version 1.4.12 de Nagios plugin, check_ping donne des informations de performance).
En utilisant l'interface web on peut voir le champ “Performance Data” dans chaque hosts/services. Si ce champ est vide, il n'y a pas de données disponibles, donc aucun fichier n'est écrit dans le dossier de PNP et c'est pour cela que PNP ne fournit pas de graphes!
L'image suivante montre les informations du service “PING”. La sortie du plugin est encadrée en bleu, les données de performance en rouge.
2. Est ce que Nagios a appelé le script process_perfdata.pl
?
Dans le fichier de configuration de process_perfdata.pl (etc/process_perfdata.cfg
) vous pouvez augmenter le niveau de debug. Toutes les données passant par le système seront loggées dans var/perfdata.log
.
3. Seul les Graphiques sont affichés (sans les textes)? Vérifiez que vous avez bien tous les prérequis.
4. En utilisant le module npcdmod la valeur de la directive event_broker_options
dans votre nagios.cfg devra peut être adapté si vous en avez modifié la configuration. Vous trouverez plus de détails ici.
5. Vous pouvez utiliser le script verify_pnp_config.pl dans le dossier scripts
du dossier d'installation ou dans le dossier libexec
après installation pour vérifier votre configuration ainsi que s'assurer que les données de performance sont bien présentes et/ou valides. La syntaxe de cette commande est relativement simple:
./verify_pnp_config.pl -m <mode>
ou <mode>
peut être égale à “sync”, “bulk” ou “npcd” (sans les guillemets). NOTE: La valeur par “default” est “npcd” ce qui est différent de la version PNP 0.4.x.
En cas de problèmes, il existe un script appelé verify_pnp_config.pl
localisé sur http://verify.pnp4nagios.org. Ce script vous permet de vérifier votre configuration complète aussi bien sur les données de performance des Hosts et des services. Il peut être utilisé avant le lancement de PNP ou pendant son utilisation.
wget http://verify.pnp4nagios.org/verify_pnp_config
Le script de vérification est accessible sur http://verify.pnp4nagios.org et a besoin de trois options pour être utilisé
--mode
One of the modes described on modes--config
Path nagios.cfg or icinga.cfg--pnpcfg
Path to PNP´s etc directorylenny:~# perl verify_pnp_config --mode npcdmod --config=/usr/local/nagios/etc/nagios.cfg --pnpcfg=/usr/local/pnp4nagios/etc [INFO] ========== Starting Environment Checks ============ [INFO] My version is: verify_pnp_config-0.6.14-R.31 [INFO] Reading /usr/local/nagios/etc/nagios.cfg [OK ] Running product is 'nagios' [OK ] object_cache_file is defined [OK ] object_cache_file=/usr/local/nagios/var/objects.cache [INFO] Reading /usr/local/nagios/var/objects.cache [OK ] resource_file is defined [OK ] resource_file=/usr/local/nagios/etc/resource.cfg [INFO] Reading /usr/local/nagios/etc/resource.cfg [INFO] Reading /usr/local/pnp4nagios/etc/process_perfdata.cfg [INFO] Reading /usr/local/pnp4nagios/etc/pnp4nagios_release [OK ] Found PNP4Nagios version "0.6.14" [OK ] Effective User is 'nagios' [OK ] User nagios exists with ID '1000' [OK ] Effective group is 'nagios' [OK ] Group nagios exists with ID '1000' [INFO] ========== Checking npcdmod Mode Config ============ [OK ] process_performance_data is 1 compared with '/1/' [OK ] event_broker_options is defined [OK ] event_broker_options=-1 [OK ] event_broker_option bits 2 and 3 enabled (12) [OK ] broker_module is defined [OK ] broker_module=/usr/local/pnp4nagios/lib/npcdmod.o config_file=/usr/local/pnp4nagios/etc/npcd.cfg [OK ] npcdmod.o config file is /usr/local/pnp4nagios/etc/npcd.cfg [OK ] /usr/local/pnp4nagios/etc/npcd.cfg used by npcdmod.o is readable [OK ] npcd daemon is running [OK ] /usr/local/pnp4nagios/etc/npcd.cfg is used by npcd and readable [OK ] npcd and npcdmod.o are using the same config file (/usr/local/pnp4nagios/etc/npcd.cfg) [INFO] Nagios config looks good so far [INFO] ========== Checking config values ============ [INFO] Reading /usr/local/pnp4nagios/etc/npcd.cfg [OK ] Script /usr/local/pnp4nagios/libexec/process_perfdata.pl is executable [INFO] ========== Starting global checks ============ [OK ] status_file is defined [OK ] status_file=/dev/shm/status.dat [INFO] Reading /dev/shm/status.dat [INFO] ==== Starting rrdtool checks ==== [OK ] RRDTOOL is defined [OK ] RRDTOOL=/usr/bin/rrdtool [OK ] /usr/bin/rrdtool is executable [OK ] RRDtool 1.3.1 Copyright 1997-2008 by Tobias Oetiker <tobi@oetiker.ch> [OK ] USE_RRDs is defined [OK ] USE_RRDs=1 [OK ] Perl RRDs modules are loadable [INFO] ==== Starting directory checks ==== [OK ] RRDPATH is defined [OK ] RRDPATH=/usr/local/pnp4nagios/var/perfdata [OK ] Perfdata directory '/usr/local/pnp4nagios/var/perfdata' exists [WARN] 62 hosts/services are not providing performance data [WARN] 'process_perf_data 1' is set for 43 hosts/services which are not providing performance data! [WARN] 'process_perf_data 0' is set for 27 of your hosts/services [OK ] 'process_perf_data 1' is set for 243 of your hosts/services [INFO] ==== System sizing ==== [OK ] 269 hosts/service objects defined [INFO] ==== Check statistics ==== [WARN] Warning: 3, Critical: 0 [WARN] Checks finished...
Est-il préférable que PNP soit facilement accessible? Vous n'avez certainement pas envie de chercher longtemps le bon graphique.
Nagios propose des fonctionnalités permettant d'accéder à des URL externes. En raison de changements entre les versions de nagios 2.x et 3.x, nous décrirons la configuration pour ces deux versions.
Avec Nagios 2.x, l'intégration d'URL externe dans l'interface web de nagios se fait en renseignant les informations étendues des services. Pour PNP, nous utilisons la directive action_url pour appeler l'interface web de PNP web frontend avec les options ad hoc :.
define serviceextinfo { host_name localhost service_description load action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$ }
Vous devrez spécifier ces informations étendues de services pour chaque définition de service.
Depuis nagios 3.0 la directive action_url a été déplacée dans la définition des machines ou des services. De cette façon, la définition de l'accès aux URLs de PNP est plus simple. Les définitions serviceextinfo et hostextinfo sont maintenant dépréciées.
Nous allons d'abord définir 2 templates. Si vous avez utilisé le guide d'installation rapide de Nagios vous pouvez ajouter ces lignes directement au fichier templates.cfg:
define host { name host-pnp action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_ register 0 } define service { name srv-pnp action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$ register 0 }
Ces 2 templates peuvent maintenant être utilisées en incluant “use srv-pnp” ou “use host-pnp” pour les services et les hosts respectivement. Si vous avez utilisé le guide d'installation rapide de Nagios vous pouvez par exemple éditer votre fichier de config localhost.cfg et ajouter les nouvelles templates définies à votre host ou vos services comme ceci:
define host{ use linux-server,host-pnp ; Name of host templates to use ; This host definition will inherit all variables that are defined ; in (or inherited by) the linux-server host template definition. host_name localhost alias localhost address 127.0.0.1 }
define service{ use local-service,srv-pnp ; Name of service template to use host_name localhost service_description PING check_command check_ping!100.0,20%!500.0,60% }
Les liens correct vers PNP4NAGIOSThe vont se générer automatiquement.
Astuce: Si vous voulez ouvrir la fenêtre de PNP4NAGIOS dans votre fenêtre principale (a droite du menu) au lieu d'une nouvelle page, modifiez juste action_url_target=main
dans votre nagios cgi.cfg
Vous pouvez également intégrer PNP dans Nagios de façon à ce que vous n'ayez à cliquer sur aucuns icones. Cela peut être configuré en utilisant CGI Includes qui nous autorise a utiliser du code JavaScript dans la vue de détail ( status.cgi ).
Prérequis:
Définition:
define host { name host-pnp action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_' class='tips' rel='/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=_HOST_ register 0 } define service { name srv-pnp action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$' class='tips' rel='/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=$SERVICEDESC$ register 0 }
Après le redémarrage de Nagios (après modification des définitions) cela ressemble à ceci:
Le comportement de l'interface Web PNP peut être contrôlé grâce au fichier etc/config.php. Ce fichier est écrasé à chaque mise à jour car les chemins et les options sont détectés lors du ./configure.
Les configurations personnalisées doivent être effectuées dans le fichier etc/config_local.php. Si ce fichier n'existe pas, il peut être créé en utilisant comme modèle le fichier etc/config.php.
Les paramètres les plus importants sont:
Le chemin vers le binaire de RRDtool. Sera détecté par le ./configure
$conf['rrdtool'] = "/usr/bin/rrdtool";
Hauteur et Largeur des graphiques RRD
$conf['graph_width'] = "500"; $conf['graph_height'] = "100";
Les tailles d'écran peuvent varier, les pages non. Les deux paramètres suivants vous permettent de spécifier différentes tailles pour la création de PDFs. S'ils ne sont pas spécifiées, ils prennent pour valeur la taille des graphiques.
$conf['pdf_width'] = "675"; $conf['pdf_height'] = "100";
D'autre options peuvent être passer a chaque appel de RRDTool, par exemple ----slope-mode
pour lissé les graphiques.
$conf['graph_opt'] = "";
Le chemin vers du fichier RRD et XML créé par process_perfdata.pl
$conf['rrdbase'] = "/usr/local/pnp4nagios/var/perfdata/";
Le chemin du fichier de config de pages.
$conf['page_dir'] = "/usr/local/pnp4nagios/etc/pages/";
Les pages PNP seront rafraîchies toutes les n secondes
$conf['refresh'] = "90";
L'âge Maximum des fichiers RRD en secondes. Après avoir atteint cette valeur, le lien vers le graphique sera marqué comme inactif
$conf['max_age'] = 60*60*6;
L'URL de base vers les CGIs de Nagios
$conf['nagios_base'] = "/nagios/cgi-bin";
Liste des utilisateurs autorisés à voir les liens vers les services de l'host actif
$conf['allowed_for_service_links'] = "EVERYONE";
Liste des utilisateurs qui peuvent voir/accéder au champs de recherche d'host
$conf['allowed_for_host_search'] = "EVERYONE";
Si PNP est appelé avec seulement le nom de l'host ( index.php?host=<myserver> ), les utilisateur définis voient un aperçu de tous les services de cet host
$conf['allowed_for_host_overview'] = "EVERYONE";
Les périodes de temps affichées par les graphique RRD sont déterminées par la variable de tableau $views[]. Le titre et le nombre de graphiques peuvent être configurés globalement ici
$views[] = array('title' => 'Une heure', 'start' => (60*60) ); $views[] = array('title' => '4 Heures', 'start' => (60*60*4) ); $views[] = array('title' => '25 Heures', 'start' => (60*60*25) ); $views[] = array('title' => 'Une Semaine', 'start' => (60*60*25*7) ); $views[] = array('title' => 'Un Moi', 'start' => (60*60*24*32) ); $views[] = array('title' => 'Une Année', 'start' => (60*60*24*380) );
Vous pouvez ajouter plus de vues ($views[5], …), mais gardez quand même à l’esprit que par défaut TOUTES les vues définies ici seront affichées.
Dans la fenêtre de visualisation, PNP nous affiche 5 intervalles de temps différents qui peuvent être configurés dans config.php.
Vous pouvez également influencer l'intervalle de temps par URL. Cela peut être utile pour la création automatique de PDF. Intervalle peut être défini par l'option “start” et “end”.
Exemple:
pnp4nagios/graph?host=<hostname>&srv=<servicedesc>&start=-1week
Le graphique démarrera une semaine avant la date et l'heure actuelles. Il se terminera à l'heure et à la date actuelle.
start | end | view | résultats |
---|---|---|---|
Toutes les vue se terminent à la date et l'heure actuelles | |||
x | Toutes les vue démarrent à la date et l'heure définies | ||
x | Toutes les vue se terminent à la date et l'heure définies | ||
x | x | Une vue entre deux dates | |
x | Une vue se terminant à la date et l'heure actuelles | ||
x | x | Une vue démarrant à la date et l'heure définies | |
x | x | Une vue se terminant à la date et l'heure définies |
Différents exemples:
format | description |
---|---|
2009W04 | 4em semaine de 2009 |
1.5.2009 | 1er Mai 2009 |
-1 day | Moins 1 jour |
-3 weeks | Moins 3 semaines |
-1 year | Moins 1 an |
yesterday | année |
“pages” nous donne la possibilité de regrouper les graphiques de plusieurs hosts/services sur une seule page, permettant ainsi de composer des documents pdf spécifiques. Cela nous permet - par exemple - d'afficher le traffic réseau de tous nos robots de sauvegarde. Les expressions régulières sont également supportées, ce qui vous permet une modularité importante avec seulement quelques règles. Le dossier configuré en utilisant “$conf['page_dir']” contient un ou plusieurs fichier(s) avec une extension ”.cfg”.
Les commentaires commencent par le signe “dièse” (#) et peuvent être inclus dans les lignes. Chaque fichier contient une définition de “page” qui spécifie le nom de la page ainsi que les graphiques sélectionnés en utilisant les expressions régulières ou non.
La description correspondant au champ “page_name” apparaîtra dans la liste des pages disponibles dans la fenêtre du navigateur.
Attention : Les champs “host_name” et “service_desc” font directement référence aux fichiers créés dans le répertoire des données de performance (ex.: /var/nagios/perfdata) et non aux variables définies dans les fichiers de configuration de Nagios. Les espaces sont remplacés par des symboles de soulignement (_).performances
define page { use_regex 1 # 0 = use no regular expressions, 1 = use regular expressions page_name test-page # page description }
suivi par une ou plusieurs définitions de graphiques :
define graph { host_name host1,host2,host3 service_desc Current_Load }
Attention: Une liste de nom d'hôtes fonctionne uniquement si le paramètre “use_regex” est réglé à 0 !
define graph { host_name host4 service_desc Current_Users }
Et maintenant quelques définitions utilisant les expressions régulières. Le paramètre “use_regex” doit pour cela être réglé à 1 ! Ainsi, pour atteindre tous les hôtes dont le nom commence par “Tape” :
define graph { host_name ^Tape service_desc Traffic }
tous les hôtes dont le nom se termine par “00”:
define graph { host_name 00$ service_desc Load }
tous les services sur l'hôte local qui contiennent les lettres “a” ou “o” :
define graph { host_name localhost service_desc a|o }
tous les services dont le nom contient un caractère “underscore” suivi de trois chiffres sur les hôtes dont le nom commence par les lettres “UX :
define graph { host_name ^UX service_desc _\d{3} }
Dans la plupart des cas, vous voudrez sans doute limiter l'affichage à un seul graphique. Cet objectif sera atteint si vous ajouter la directive “source” suivi du numéro d'ordre du graphique souhaité, tel que défini dans les choix définis dans l'interface, le premier étant 0 (par exemple pour 2 heures).
define graph { host_name host1,host2,host3 service_desc PING source 1 }
PNP vous permet d'accéder aux données des bases RRD en utilisant le module xport
. Le format d'export peut-être spécifié. Actuellement, il est possible d'exporter au format xml
, json
et csv
.
Le module peut-être appelé en utilisant l'URL suivante :
/pnp4nagios/xport/<format>?host=<hostname>&srv=<servicedesc>
Où <format> doit être remplacé par le format souhaité.
Les “templates” sont des modèles que PNP utilise pour l' aspect des graphiques produits à partir des données fournies par RRD (Round-Robin-Data).
Le “template” correspond au service check_<commande> qui a récupéré les données. La suite décrit où sont stockés les “templates” et comment ils sont sélectionnés.
Les “templates” sont stockés dans deux sous-répertoires de celui de pnp (ex. /usr/share/pnp/…)
Depuis la version 0.6.5 de PNP, d'autres emplacements peuvent être définis dans le fichier de configuration …/etc/config.php .
Ainsi, pour la représentation graphique du service “http” pour l'hôte (Host) “localhost”, PNP consulte en premier lieu le fichier XML ”…/perfdata/localhost/http.xml”. Ce fichier est généré automatiquement avec les données “performance-data” et contient les informations correspondantes à l'hôte et au service. Par ailleurs, il fournit également des renseignements sur le plugin utilisé et sur les données “performance-data”. Dans l'exemple suivant, le nom du “template” qui sera utilisé est noté entre les balises <TEMPLATE>.
/localhost/http.xml
<NAGIOS> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>1</DS> <NAME>time</NAME> <UNIT>s</UNIT> <ACT>0.006721</ACT> <WARN>1.000000</WARN> <CRIT>2.000000</CRIT> <MIN>0.000000</MIN> <MAX></MAX> </DATASOURCE> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>2</DS> <NAME>size</NAME> <UNIT>B</UNIT> <ACT>263</ACT> <WARN></WARN> <CRIT></CRIT> <MIN>0</MIN> <MAX></MAX> </DATASOURCE> ... </NAGIOS>
PNP recherche maintenant un “template” portant le nom check_http.php
dans l'ordre suivant des dossiers :
Le “template” default.php
est particulier car il sera sélectionné si aucun autre portant le nom recherché n'a été trouvé.
Les “templates” dans PNP sont des fichiers PHP qui lui sont associés pendant son fonctionnement grâce à la fonction PHP include()
.
Ceci a comme conséquence que tout code PHP contenu dans les templates sera interprété, et permet le traitement de toutes les valeurs par PHP.
Les “templates” de PNP doivent avoir les propriétés suivantes :
Les deux PHP-Arrays $opt[] et $def[] constituent l'appel de 'rrdtool graph
'. Toutes les options mises à disposition de RRDtool sont donc disponibles. Ces dernières sont décrites sur le site RRDtool Homepage.
Par ailleurs les “templates” peuvent utiliser les autres données contenues dans le fichier XML correspondant.
Les options les plus utiles peuvent facilement se déduire à l'aide du “template” relativement simple response.php
.
<?php # $opt[1] = "--title \"Response Time For $hostname / $servicedesc\" "; # $def[1] = "DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE " ; $def[1] .= "AREA:var1#00FF00:\"Response Times \" " ; $def[1] .= "LINE1:var1#000000 " ; $def[1] .= "GPRINT:var1:LAST:\"%3.4lg %s$UNIT[1] LAST \" "; $def[1] .= "GPRINT:var1:MAX:\"%3.4lg %s$UNIT[1] MAX \" "; $def[1] .= "GPRINT:var1:AVERAGE:\"%3.4lg %s$UNIT[1] AVERAGE \" "; ?>
Rédaction en cours. Merci de consulter les autres traductions en attendant…
$opt[1] = ”--title …”
définit les options de RRDtool pour le premier champ de données dans le tableau (Array). Ici il s'agit du titre du graphique. Comme on peut le remarquer, les guillemets sont masqués par le caractère d'échapement Backslash (\).
$def[1] = “DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE ”;
précise quelles données sont lues depuis quel fichier RRD. La variable $RRDFILE[1] contient le chemin vers le fichier de données RRD du service concerné. $DS[1] indique quelle sera la rangée de données à extraire.
$def[1] .= “AREA:var1#00FF00:\”Response Times \” ”;
l'opérateur ”.=” permet d'ajouter des données à l'Array $def[1]. L'aire (AREA) est représentée à l'aide des données transmises par la variable var1. La couleur est définie par le code hexadécimal #00FF00. Le libellé utilisé est précisé par le texte “Response Times”.
$def[1] .= “LINE1:var1#000000 ”;
trace une ligne noire (#000000) d'épaisseur 1 pixel (LINE1, maximum 3 pixels avec LINE3) délimitant l'aire.
$def[1] .= “GPRINT:var1:LAST:\”%3.4lg %s$UNIT[1] LAST \” ”;
$def[1] .= “GPRINT:var1:MAX:\”%3.4lg %s$UNIT[1] MAX \” ”;
$def[1] .= “GPRINT:var1:AVERAGE:\”%3.4lg %s$UNIT[1] AVERAGE \” ”;
Les trois instructions GPRINT ci-dessus constituent la légende du graphique. Les valeurs actuelles sont formatées en suivant la syntaxe printf. D'autres exemples utiliseront des tableaux (ARRAY).
En cours de fonctionnement, PNP ne stocke pas seulement des données “performance-data” grâce au script process-perfdata.pl
, mais également d'autres valeurs exportées par Nagios. Ces valeurs sont enregistrées dans le fichier XML concerné.
Dans la première section, les données “performance-data” sont décomposées par champs.
<NAGIOS> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>1</DS> <NAME>time</NAME> <UNIT>s</UNIT> <ACT>0.006721</ACT> <WARN>1.000000</WARN> <CRIT>2.000000</CRIT> <MIN>0.000000</MIN> <MAX></MAX> </DATASOURCE> ... </NAGIOS>
Le champs <DS> pointe vers la rangée contenue dans la série de données fournies par le fichier RRD et sert également de clé pour l'accès aux tableaux suivants.
Ainsi l'Array $UNIT[1]
pointe vers l'unité (Mb, Gb, …) précisée dans la première rangée de données.
Le fichier XML contient encore d'autres informations. Si le script process_perdata.pl
fonctionne en mode “sync”, alors toutes les macros ainsi que leurs valeurs actuelles sont disponibles.
L'extrait suivant a été tronqué pour des raisons de lisibilité.
<NAGIOS> ... <NAGIOS_SERVICENOTIFICATIONID>8418</NAGIOS_SERVICENOTIFICATIONID> <NAGIOS_SERVICENOTIFICATIONNUMBER>0</NAGIOS_SERVICENOTIFICATIONNUMBER> <NAGIOS_SERVICEOUTPUT>HTTP OK HTTP/1.1 200 OK - 10087 bytes in 0.125 seconds</NAGIOS_SERVICEOUTPUT> <NAGIOS_SERVICEPERCENTCHANGE>0.00</NAGIOS_SERVICEPERCENTCHANGE> <NAGIOS_SERVICEPERFDATA>time=0.124811s;;;0.000000 size=10087B;;;0</NAGIOS_SERVICEPERFDATA> <NAGIOS_SERVICEPERFDATAFILE></NAGIOS_SERVICEPERFDATAFILE> <NAGIOS_SERVICEPROBLEMID>0</NAGIOS_SERVICEPROBLEMID> <NAGIOS_SERVICESTATE>OK</NAGIOS_SERVICESTATE> <NAGIOS_SERVICESTATEID>0</NAGIOS_SERVICESTATEID> <NAGIOS_SERVICESTATETYPE>HARD</NAGIOS_SERVICESTATETYPE> <NAGIOS_SHORTDATETIME>27-12-2007 13:51:23</NAGIOS_SHORTDATETIME> ... </NAGIOS>
Les balises XML sont utilisables par PNP en tant que variables du même nom.
Ainsi, à partir de la balise <NAGIOS_SERVICEOUTPUT>
il est possible de former la variable $NAGIOS_SERVICEOUTPUT
.
Comme déjà expliqué dans ”Qu'est-ce qu'un template” l'apparence des graphiques dépend de la commande check utilisée.
Il y a des situations où ce comportement doit être changé. Cela doit être fait quand une commande universelle a été définie.
Exemple:
define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a "$ARG2$" }
Cela aurait pour effet d'appeler la template check_nrpe.php même si l'host monitoré utilisait un plugin complètement différent appelé via NRPE.
PNP, plus spécifiquement process_perfdata.pl, va rechercher le fichier de config (<check_command>.cfg) dans le dossier etc/check_commands et lit son contenu (s'il est présent).
Comme dans notre exemple, la commande appelée est check_nrpe, il va chercher le fichier etc/check_commands/check_nrpe.cfg.
Pendant l'installation, un exemple de fichier de configuration avec l'extension .cfg-sample est copié dans etc/check_commands.
Two options can be set in this config file:
# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5 # ________0__________| | | # ________1__________________| | # ________2__________________________| # CUSTOM_TEMPLATE = 1
CUSTOM_TEMPLATE = 1
assures that only the contents of $ARG1$ will be used as a template name. As $ARG1$ contains “load” in this example the template name would result in “load.php”.
CUSTOM_TEMPLATE = 0,1
results in → “check_nrpe_load.php”
CUSTOM_TEMPLATE = 1,0
results in → “load_check_nrpe.php”
The option “DATATYPE” controls the datatype which is used during creation of the RRD database. Default is “GAUGE”. For consecutive values the type should be “COUNTER”. Plugin-developers should use the unit “c” for counters but this is not always the case.
To set all datasources to COUNTER
DATATYPE = COUNTER
Setting datasources to different types
DATATYPE = GAUGE,GAUGE,COUNTER,COUNTER
This option has effect only during creation of the RRD database.
More datatypes are explained in the RRDTool documentation found at rrdcreate.
In a few situations it might be necessary to limit the values which are valid for RRDTool.
RRD databases can be created with fixed minimum and maximum values. You will find further details at http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html.
Account for the maximum value taken from the performance data
USE_MAX_ON_CREATE = 1
Account for the minimum value taken from the performance data
USE_MIN_ON_CREATE = 1
RRD_STORAGE_TYPE = SINGLE
The option RRD_STORAGE_TYPE defines the kind of data storage.
Possible values are MULTIPLE and SINGLE, respectively.
SINGLE: A RRD database per service
MULTIPLE: One or more RRD databases per service. Each datasource will be stored in a separate RRD database.
ATTENTION: The data will not be migrated automatically! You will find a conversion script here.
Starting with PNP 0.6.1
RRD_HEARTBEAT = 305
After <RRD_HEARTBEAT> seconds RRDtool expects new data.
More information at http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
Si votre surveillance Nagios est distribuée, vous devrez décider de l'emplacement où vous aller installer PNP.
D'un point de vue technique, cette question n'a pas d'importance. PNP peut-être installé sur un(des) esclave(s) aussi bien que sur le maître et éventuellement sur les deux.
Si PNP tourne sur le serveur maître, vous devrez vous assurer que les données envoyées par send_nsca depuis les esclaves contiennent bien les données de performance. Généralement, ces envoies de données sont fait à l'aide d'un autre moyen.
Pour aider PNP à reconnaître les commandes lancées par l'esclave sur le maître, vous pouvez préciser le nom de la commande à la fin des données de performances de la manière suivante :
OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;; [check_icmp]
Si PNP trouve une chaîne entouré de crochet à la fin des données de perforamnces, elle sera reconnue comme la commande de test et sera utilisé pour le template PNP.
De la documentation Nagios sur le sujet peut-être consulté ici. La commande dans la documentation peut-être adaptée facilement.
define command{ command_name submit_check_result command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$' }
should be changed to
define command{ command_name submit_check_result command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$ | $SERVICEPERFDATA$ [$SERVICECHECKCOMMAND$]' }
Le Plugin check_multi est l'un des premiers plugins à utiliser cette nouvelle fonctionnalité de Nagios 3.x. Check_multi peut exécuter plusieurs tests en même temps mais en retournant le tout sous la forme d'un seul service. La sortie de check_multi comprend plusieurs lignes pour être en mesure d'afficher l'information.
Ceci se traduit par des difficultés pour PNP qui doit alors extraire son information de plusieurs sondes depuis la sortie de performance. Avec l'aide de Matthias Flacke, créateur de check_multi, nous avons trouvé une solution pour appliquer les données aux bonnes sondes.
Dans les installations de supervision importantes, généralement, nous rencontrons un taux relativement élevé de charge d'E/S pendant le traitement des données de performance . RRDtool doit faire beaucoup de mises à jour sur disques, mais il ne peut pas utiliser le cache disque d'une manière optimale.
Une amélioration est apportée par la collecte et le tri des données. Il est plus efficace d'écrire de nombreuses mises à jour d'une base de données RRD dans un seul bloc. Le cache disque peut être utilisé de manière plus efficace de cette façon.
Le dernier RRDtool ( SVN trunk 1550+ ) rrdcached contient exactement ce qui devrait améliorer cette situation.
A ce stade, je tiens à remercier Florian octo Forster, Kevin Brintnall and Tobi Oetiker. Le développement de ce daemon a été coordonné de façon exemplaire sur la rrd-developers mailing list.
Le rrdcached fonctionne comme un démon en tâche de fond et ouvre une socket TCP ou UNIX, il attend les demandes de rrdtool. Pour des raisons de sécurité les nouvelles versions de rrdcached ne peuvent pas utiliser des chemins absolus pour l'accès au réseau. La seule façon possible est l'utilisation des sockets unix.
rrdcached reconnait un nombre important d'options qui sont mises en oeuvre au démarrage.
Option -l définit le socket d'écoute du daemon. Le port TCP par défaut est le 42217.
-l unix:/path/to/rrdcached.sock -l /path/to/rrdcached.sock -l 127.0.0.1 -l 127.0.0.1:8888
Option -P specifie quelles commandes seront utilisables avec les bases de données RRD
-P FLUSH,PENDING
Option -s permet de changer le groupe d'appartenance du socket unix
-s nagios
Option -m place les permissions sur le socket unix (format octal)
-m 0660
Option -w spécifie l'intervalle (en secondes) après lequel les données seront écrites sur le disque.
-w 1800
Option -z définit un délai maximum pour étaler les cycles d'écriture entre [0-delay] pour éviter les accès d'écritures parallèles. La valeur de l'option -z ne doit pas être plus grande que celle de l'option -w.
-z 1800
Option -p définit un fichier PID
-p /var/run/rrdcached.pid
Option -j définit le chemin pour un répertoire de journalisation. Toutes les demandes seront écrites et pourrons être exécuter après un redémarrage du daemon suite à un crash
-j /var/cache/rrdcached
Ces options peuvent être utilisées pour appeler rrdcached avec les paramètres suivants
rrdcached -w 1800 -z 1800 -p /tmp/rrdcached.pid -j /tmp -s nagios -m 0660 -l unix:/tmp/rrdcached.sock
RRDtool, lui-même, sera informé par le daemon avec l'option --daemon=<socket>.
rrdtool --daemon=unix:/tmp/rrdcached.sock update ...
Bien sûr, cela doit correspondre avec les options de rrdcached!
Deux composantes de PNP sont utilisées avec rrdcached, il faut apporter des changements dans les deux fichiers de configuration correspondants.
1. Modification du process process_perfdata.cfg pour le collecteur de données process_perfdata.pl
# EXPERIMENTAL rrdcached Support # Use only with rrdtool svn revision 1511+ # RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sock
2. Modification du fichier config_local.php (ou config.php) pour l'interface web
# # EXPERIMENTAL rrdcached Support # Use only with rrdtool svn revision 1511+ # # $conf['RRD_DAEMON_OPTS'] = 'unix:/tmp/rrdcached.sock'; $conf['RRD_DAEMON_OPTS'] = 'unix:/var/run/rrdcached.sock';
Les exemples de fichiers contiennent les options les plus pertinentes.
NPCD (Nagios-Perfdata-C-Daemon) a été écrit pour fournir un mode asynchrone dans le traitement des données de performance de nagios
.
Dans les grandes installations, votre latence moyenne peut augmenter jusqu'à une valeur élevée non acceptable. Cela signifie que Nagios doit faire une vérification au moment de x
mais en fait il ne le fait que Y
secondes plus tard.
Si vous dites à Nagios que vous voulez traiter les données de performance après chaque contrôle unique, vous allez le faire bien jusqu'à un certain nombre de contrôles, mais au-dessus de cette limite, vous rencontrez des problèmes de latence.
Pour réduire le nombre d'actions pour chaque vérification vous pouvez utiliser le Bulk Mode qui rassemble les données de performance pendant un certain temps et puis laisse Nagios
exécuter le <host|service>_perfdata_file_processing_command
ou vous pouvez dire à Nagios de simplement déplacer les perfdata_files
dans un répertoire de “spool”.
Ce déplacement est une action très rapide pour Nagios
et il peut continuer à faire ce qu'il doit faire: exécuter d'autres vérifications, l'envoi de notifications, et ainsi de suite.
Comme mentionné précédemment, le processus Nagios a terminé son travail avec le déplacement du fichier de données de performance dans un répertoire de spool, mais cela ne modifie pas les données dans les fichiers RRD.
Pour cette tâche, vous pouvez lancer npcd
, npcd va regarder dans le répertoire de spool et commencer à traiter chaque fichier trouvé.
Après le lancement de NPCD, il construit une liste de fichiers trouvés dans perfdata_spool_dir
et lance des nouveaux traitements pour chaque fichier et exécute le perfdata_file_run_cmd
avec l'option perfdata_file_run_cmd_arg
comme argument supplémentaire.
Les fichiers de perfdata dans le répertoire de spool sont dans le même format 'normal' bulk mode, NPCD exécutera process_perfdata.pl
dans le Bulk Mode.
Pro:
Con:
Nagios
(service_perfdata_file_processing_interval
)
Vous devez modifier le fichier de configuration de NPCD à partir du fichier npcd.cfg-sample
.
Renommez-le npcd.cfg
pour lancer NPCD de la manière suivante:
/usr/local/pnp4nagios/bin/npcd -f /usr/local/pnp4nagios/etc/npcd.cfg
ou
/usr/local/pnp4nagios/bin/npcd -d -f /usr/local/pnp4nagios/etc/npcd.cfg
pour lancer en mode Daemon (tâche de fond).
Attention: Si vous décidez de ne pas renommer le fichier de configuration, il sera perdu dans le prochain update de PNP.
Voici les directives essentielles pour NPCD:
# Privilege Options user = nagios group = nagios # Logging Options log_type = syslog log_file = /usr/local/pnp4nagios/var/npcd.log max_logfile_size = 10485760 log_level=0 # Processing Options perfdata_spool_dir = /usr/local/pnp4nagios/var/spool/ perfdata_file_run_cmd = /usr/local/pnp4nagios/libexec/process_perfdata.pl perfdata_file_run_cmd_args = -b # Thread Options npcd_max_threads=5 # greedy options use_load_threshold = 0 load_threshold = 10.0 # Process Options pid_file=/var/run/npcd.pid
log_type = file
nom du fichier utilisé<perfdata_file_run_cmd> <perfdata_file_run_cmd_args> <filename_from_perfdata_spool_dir>
use_load_threshold
est mis à 1, la limite de charge ne doit pas être dépasséecheck_procs est un exemple de plugin ne donnant pas d'informations de type “performance-data”:
./check_procs -a ndo2db -w 1: -c 0: PROCS OK: 2 processes with args 'ndo2db'
Cela peut être corrigé par le script suivant:
check_procs.sh
#!/bin/bash LINE=`/usr/local/nagios/libexec/check_procs $*` # On sauve la sortie du script dans la variable LINE RC=$? # On sauve le code de sortie dans la variable RC COUNT=`echo $LINE | awk '{print $3}'` # On sauve le contenue de la 3ème col de la variable LINE dans la variable COUNT PROCS=`expr $COUNT - 1` # check_procs.sh est computé, donc, soustraire un LINE=`echo $LINE | sed "s/: $COUNT /: $PROCS /"` # On remplace le numéro echo $LINE \| procs=$PROCS # On affiche le tout exit $RC # On sort avec le code de sortie du script initial
Maintenant vous allez avoir les informations “performance-data” grâce au libellé suivant :
./check_procs.sh -a ndo2db -w 1: -c 0:
ce qui conduit à la sortie :
PROCS OK: 2 processes with args 'ndo2db'| procs=2
2.6. Données de performance
Les données de performance sont définies par Nagios par “toutes les information présentes après le | résultant de l’exécution du plugin” - Se référer à la documentation de Nagios pour capturer ces informations dans un fichier de log. Toutefois, il est de la responsabilité du programmeur du plugin, que les données de performance soient dans un format respectant le standard des “plugins Nagios”. Ceci est le format attendu:
'label'=value[UOM];[warn];[crit];[min];[max]
Notes:
La conversion des données de performance de Nagios en graphique est à la charge d'un autre programme.
Source: https://www.monitoring-plugins.org/doc/guidelines.html#AEN200