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

• Affichage web se basant sur Kohana
• Affichage web se basant sur jQuery Themes
• Fonctions javascript se basant sur des plugins jQuery
• process_perfdata.pl est capable d'utiliser une base RRD par source de données
• Amélioration de l'installateur. Possibilité de spécifier l'emplacement des layout --with-layout
• Les erreurs RRD sont maintenant affichées en image. Plus d'image manquante.
• Les templates PNP n'ont plus la possibilité de changer les paramètres internes
• Les templates en version 0.4.x sont toujours utilisables
• Fonction de génération du PDF recodée
• Template par défaut (default.php) mieux optimisé
• Export des bases RRD au format XML, CSV and JSON à l'aide de la fonction “xport” de RRDtool
• Fonctions des pages recodées
• Les pages d'erreurs vous renvoient aux pages en ligne FAQ
• Popup au survol de la souris dans nagios via le plugin jQuery.clueTip
• Support de rrdcached

Retour a l'index | Pré-requis

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 (').

• Perl >= 5.x sans dépendance supplémentaire
• RRDtool >= 1.x, voir 1.2 mais pas obligatoire
  Attention: l'installation de RRDtool sans gestionnaire de paquet peut mener à des problèmes de fontes dejavu absentes. Si vous obtenez des graphiques sans texte, il s'agit peut-être de l'origine de votre problème.
• PHP >= 5.1.6 pour le moteur web Kohana
• Nagios >= 2.x ou Icinga
• Kohana a besoin du module “mod_rewrite”. Pour plus de détails, merci de vous reporter à la documentation spécifique de votre serveur web.

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.

• An error occurred while fetching this feed: http://sourceforge.net/export/rss2_projsummary.php?group_id=191615

Retour a l'index | mode PNP

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.

TODO

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.

Retour a l'index | installation

Vous avez accès aux derniers changements sur pnp4nagios.git.sourceforge.net

La dernière version est pnp4nagios-0.6.7.tar.gz

pnp4nagios-head.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

• Feature: Webinterface for mobile devices based on jQuery Mobile
  ( http://jquerymobile.com/ )
• Feature: Zoom based on jQuery plugin imgAreaSelect
  ( http://odyniec.net/projects/imgareaselect/ )
• Feature: New template check_mssql_health.php
• Bugfix: Fixed popups to work under nginx ( Joram Agten )
• Bugfix: Helper rrd::vdef() fixed
• Update: jQuery update to 1.6.2
• Update: jQuery-ui update to 1.8.14

pnp-0.6.13 05/19/2011

• Feature: New option --ignore-hosts added to check_pnp_rrds.pl ( by Jochen Bern )
• Feature: New options zgraph_width and zgraph_height in config.php ( Mike Liebsch )
• Bugfix: rrd_convert.pl: parse_xml_filename() regex fix
• Info: Version used by OMD-0.48 OMD

pnp-0.6.12 04/22/2011

• Feature: mod_gearman support added
• Feature: rrd_convert.pl is now able to convert all RRDs from RRD_STORAGE_TYPE=SINGLE to RRD_STORAGE_TYPE=MULTIPLE
• Feature: New template check_gearman.php
• Feature: Install process_perfdata.cfg and npcd.cfg by default
• Bugfix: rrd_convert.pl is now able to parse xml dumps created by rrdtool 1.4.x
• Bugfix: process_perfdata.pl default timeout value set to 15 seconds

pnp-0.6.11 01/15/2011

• Bugfix: urldecoding fixed
• Bugfix: Zoom in/out is working again ( Reported by Thorben Soehl )
• Featue: npcd.cfg - New option perfdata_file_processing_interval used by npcdmod
• Info: Version used by OMD-0.46 OMD

pnp-0.6.10 12/15/2010

• Feature: Add RRDTool Option --only-graph if graph height is below 32px to create thumbnails
• Feature: RRDTool Option --width and --height is now allowed in templates
• Feature: RRDTool DS Type for UOM of “c” changed from COUNTER to DERIVE
• Feature: Pass query string from special controller to image controller ( Matthew Garrett )
• Feature: Authorisation against mk_livestatus API added
• Feature: Sample nginx webserver config added ( by evax@users.sourceforge.net )
• Feature: Kohana backport to support PHP 5.1.6 ( Kudos to Andreas Ericsson )
• Bugfix: Sort list of special templates
• Bugfix: Urlencode hostname and service description ( Reported by Yannick )
• Bugfix: corrected warning/critical thresholds in ticker/alerter functions

pnp-0.6.7 09/27/2010

• Bugfix: Page config parser fix (Beau Gunderson)
• Bugfix: Zoom window size fixed (Report by Rudolf Labuschagne)
• Bugfix: Fixed undefined offset while using 'ds_name' in templates (Reported by Vladimir Bilik)
• Bugfix: Npcdmod respects process_perf_data option used in hosts and services definitions ( Reported by Wolfgang Barth )
• Template: New Template check_nagiostats.php used with check_nagiostats written by Jochen Bern

pnp-0.6.6 08/07/2010

• Bugfix: Fixed max amount of graphs per template
• Bugfix: Autodetect PNP base URL
• Bugfix: Too short npcdmod perfdata_template to take perfdata + overhead, increased +1024byte
• Bugfix: Ignore files in var/perfdata and check for empty directories
• Bugfix: Reducing memory usage while parsing page config (Laurent Freval)

pnp-0.6.5 07/09/2010

• Feature: Special Templates are back tpl_special
• Feature: New rrdtool helper functions makes template design easier tpl_helper
• Feature: config.php → 'recursive_template_search' is enabled by default
• Feature: config.php → 'template_dirs' is now an array of directorys to search for PNP templates

pnp-0.6.4 06/03/2010

• Update: jQuery Update to 1.4.2
• Update: jQuery-ui Update to 1.8
• Feature: New configure Option --with-base-url
• Template: New template check_ntp_time.php (Mathias Kettner)
• Feature: New i18n files for fr_FR (Yannig Parre)
• Feature: New jQuery Theme 'multisite'

pnp-0.6.3 03/16/2010

• Feature: New helper script libexec/rrd_convert.pl → rrd_convert
• Bugfix: Ignore old XML files while building the service list
• Template: New template check_hpasm.php
• Bugfix: Installer now checks for json_decode()
• Workaround: Allow “trailing unfilled semicolons”. Workaround for nsclient++
• Template: Updates for check_openmanage.php, check_hp_bladecenter.php and check_dell_baldecenter.php ( Trond Hasle Amundsen )”

pnp-0.6.2 12/23/2009

• Feature: XML_WRITE_DELAY option added to process_perfdata.cfg as suggested by Mathias Kettner
• Feature: New template integer.php
• Update: FPDI update to 1.3.1
• Feature: PNP will now work with lighttpd and php-cgi
• Template: check_mk-ps.perf.php added ( by Mathias Kettner )
• Feature: PNP will now work without mod_rewrite → webfe
• Bugfix: Wrong pdf link used on site 'pages' and 'basket'
• Bugfix: Incorrect group permissions on spool directory

pnp-0.6.1 11/22/2009

• Feature: RRD heartbeat per check_command → tpl_custom
• Feature: New config.php option pdf_graph_opt
• Feature: Recognize the 'background_pdf' option in page definitions → pages
• Feature: Recognize the 'source' option in page definitions → pages
• Feature: Array $TIMERANGE now available for templates → timeranges
• Bugfix: ./configure --sysconfdir no longer ignored
• Feature: Store internal runtime statistics on a per minute base
• Feature: Added two widgets views/widget_menu.php and views/widget_graph.php

pnp-0.6.0 10/30/2009

• Webfrontend based on Kohana
• Webfrontend based on jQuery Themes
• Javascript-functions using jQuery plugins
• process_perfdata.pl will be able to use one RRD database per datasource
• improved installer. Specification of directory layouts using --with-layout
• RRDtool errors are now displayed as images. no more missing images
• PNP templates cannot overwrite internal variables anymore
• PNP templates of version 0.4.x can still be used
• PDF functions recoded
• Template default.php optimized
• Export from RRD databases into XML, CSV and JSON format using the RRDtool “xport” function
• Page functions recoded
• Error pages links to online FAQ
• Mouseover Popup in Nagios frontend via jQuery.clueTip plugin
• Full support of rrdcached

Retour a l'index | mode PNP

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 .

1. Configurer la nouvelle plateforme
2. procéder à une nouvelle installation et préparez vous à ce nouveau fonctionnement
3. faîte une sauvegarde de l'ancienne installation
4. installer PNP 0.6.x dans le répertoire /usr/local/pnp4nagios
5. make install-config
6. make install-webconf
7. recharger apache
8. tester la configuration Apache
   1. l'appel à /pnp4nagios vous renverra que les répertoires de données de performance vides
9. créer /usr/local/pnp4nagios/etc/npcd.cfg depuis npcd.cfg-sample
   1. vérifier les chemins et adapter en fonction de ceux de la version 0.4.x si besoin
10. ajuster les chemins dans nagios.cfg pour pointer sur la nouvelle installation de PNP
11. ajuster les chemins dans la définition des commandes
12. stopper npcd à l'aide de /etc/init.d/npcd stop
13. make install-init installe le nouveau script init de npcd
14. /etc/init.d/nagios stop
15. copier /usr/local/nagios/share/perfdata to /usr/local/pnp4nagios/var/perfdata. Attention: faîtes gaffe aux permissions !
16. /etc/init.d/npcd start
17. /etc/init.d/nagios start

Retour a l'index | mode PNP

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

Retour a l'index | configuration

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 secondes
• service_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
}

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 secondes
• service_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:

• The perfdata routines can now be used for other addons.
• The configuration is easier.
• It is the preferred mode of the PNP developers.

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.

back to contents | checking the functionality

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.

Retour a l'index | verify_pnp_config.pl

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 directory

lenny:~# 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:

• PNP doit être installé et fonctionnel
• Le fichier status-header.ssi du dossier contrib/ssi/ du packet PNP a été copié dans /usr/local/nagios/share/ssi/.
  Attention: Ce fichier NE DOIT PAS être exécutable. Si non il sera traité comme un script CGI ce qui génèrera une erreur.
  *Note pour les administrateurs Apache*: Apache ssi et Nagios ssi n'ont de commun que le nom.
• La/les définition(s) du/des service(s) a/on été modifié. A noter que jusqu'à Nagios 2.x vous devez modifier la définition serviceextinfo (qui est rendue obsolète à partir de la version 3 de Nagios).

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:

Retour a l'index | config options

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.

Retour a l'index | Intervalle de temps

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.

Différents exemples:

Retour a l'index | pages

“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
}

Retour à l'index | Export des données

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é.

Retour à l'index | modèle

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/…)

• …/templates.dist - pour les “templates” fournis avec le packet PNP.
• …/templates - pour les “templates” personnalisés. Ceux-ci ne sont pas modifiés lors d'une mise à jour.
• …/templates.special - pour des “templates” particuliers qui seront décrits plus loin.

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 :

1. templates/check_http.php
2. templates.dist/check_http.php
3. <autre défini dans config.php>/check_http.php
4. templates/default.php
5. templates.dist/default.php

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 :

1. ils doivent contenir un code PHP valide.
2. ils ne doivent engendrer aucune exception.
3. ils doivent renseigner les deux tableaux (Arrays) $opt[] et $def[].

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.

retour au sommaire | Templates personnalisés

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

back to contents | PNP in distributed environments

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.

back to contents | support of rrdcached

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.

Retour à l'index | migration des fichiers RRD

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:

• Améliorations des performances pour Nagios
  • Parce que le traitement des données de performance sont détachées de Nagios , Nagios a plus de temps pour ses propres travaux
• Pas de perte de données
  • Tant que Nagios écrit les fichiers de performance dans le repertoire de spool, vous ne perdrez pas de données, même si NPCD n'est pas lancé ou si vous avez oublié de le lancer après un reboot. NPCD redémarrera dès la découverte d'un fichier (ces fichiers sont triés en ordre chronologique par la macro $TIME_T$ et met à jour vos fichiers RRD).

Con:

• Pas de temps réel pour le traitement des données de performance
  • car il ya un retard dans l'écriture des fichiers de données de performance par Nagios (service_perfdata_file_processing_interval)
  • un autre délai existe avec NPCD qui attend jusqu'à 10 secondes après chaque traitement d'un répertoire

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

• Privilege Options
  • user <username>
    • NPCD enlève les privilèges 'root' pour mettre ceux d'un utilisateur.
    • default: nagios
  • group <groupname>
    • NPCD enlève les privilèges 'root' pour mettre ceux d'un groupe.
    • Default: nagios
• Logging Options
  • log_type <syslog> or <file>
    • Type de log utilisé par NPCD
    • Default: syslog
  • log_file </path/to/filename>
    • Si log_type = file nom du fichier utilisé
    • Default: /usr/local/pnp4nagios/var/npcd.log
  • max_logfile_size <bytes>
    • NPCD utilise des fichiers rotatifs si le fichier de log utilisé atteint la limite définie.
    • Default: 10485760 = 10 MByte
  • log_level <integer>
    • verbose log, valeurs possibles:
      • 0 = pas de log - sauf erreurs
      • 1 = petit Log - quelques logs
      • 2 = plus de Log (actuellement: tous les messages)
      • -1 = Mode DEBUG - Tous les messages avec des ralentissements, juste pour le debug
    • Default: 0
• Options de traitement
  • perfdata_spool_dir </path/to/spool/dir/>
    • Le répertoire où les fichiers de données de performance peuvent être trouvés
    • Default: /usr/local/pnp4nagios/var/spool/
  • perfdata_file_run_cmd </path/to/bin/filename>
    • Fichier script/binary que NPCD lance
    • Default: /usr/local/pnp4nagios/libexec/process_perfdata.pl
  • perfdata_file_run_cmd_args <option>
    • Argument ajouté à la commande perfdata_file_run_cmd
    • Default: ”-b”
    • La ligne de commande peut être créée de la façon suivante :

      <perfdata_file_run_cmd> <perfdata_file_run_cmd_args> <filename_from_perfdata_spool_dir>

• Thread Options
  • npcd_max_threads <integer value>
    • Définition du nombre de threads parallèles qui peuvent être lancés
    • Default: 5
• Greedy Options
  • use_load_threshold <0 or 1>
    • Pas de lancement de nouveaux threads si la charge système est trop grande
      • 0 = disable
      • 1 = enable
    • Default: 0
  • load_threshold <float value>
    • Si use_load_threshold est mis à 1, la limite de charge ne doit pas être dépassée
    • Default: 10.0
• Process Options
  • pid_file </path/to/pid.file>
    • Le chemin du fichier PID
    • Default: /var/run/npcd.pid

Retour à l'index | wrapper script