Installation PNP4nagios on Thruk with 2 remotes nagios and 1 local nagios

Hi Folks,

I describe in this part my custom installation of PNP4Nagios for distributed monitoring. Here my plateform, I suppose you can install nagios, thruk, and livestatus broker (unix/tcp socket mode). I have 3 servers :

  • server1 : nagios, thruk, livestatus
  • server2 :  nagios, livestatus
  • server3 :  nagios, livestatus

How it work ?

  • PNP4nagios will be installed on server1
  • NCPD will be running on on server1
  • NFS server will be installed on server1
  • Npcdmod broker (npcdmod.o) will be used by server1, server2, server3
  • My server1, server2, server3 are Centos 6

Why ? Because Thruk provides a interesting feature, you can build report SLA and integrate PNP graph. Thruk can retrieve graphs of several PNP4Nagios. But you must to define different “action_url” on the host/service definition. Not very easy when you use template. That is why I am going to install a single PNP.

Server1 :

Install pnp4nagios and NFS daemon :

# yum install pnp4nagios nfs

Enabled npcd daemon a boot and restart Apache

# chkconfig npcd on
# /etc/init.d/httpd reload

Install NFS packages

# yum install nfs-utils nfs-utils-lib

Configuration NFS /etc/exports

/var/spool/pnp4nagios/ server2(rw,sync)
/var/spool/pnp4nagios/ server3(rw,sync)

Restart NFS daemon

# /etc/init.d/nfs restart

To preserve permission on /var/spool/pnp4nagios, nagios user must have the same id on server1, server2, server3.

server1 # id nagios
uid=100(nagios) gid=101(nagios) groups=101(nagios)
server2 # id nagios
uid=100(nagios) gid=101(nagios) groups=101(nagios)
server3 # id nagios
uid=100(nagios) gid=101(nagios) groups=101(nagios)

Configuration NPCD file : /etc/pnp4nagios/npcd.cfg

perfdata_spool_filename = perfdata-server1
log_level = 1

Restart NPCD daemon

# /etc/init.d/npcd restart

Configuration Thruk with PNP4nagios. Create .thruk file in Apache home directory (/var/www/.thruk)

touch /var/www/.thruk
chown apache:apache /var/www/.thruk
vi /var/www/.thruk

Paste the content :

export PNP_ETC="/etc/pnp4nagios"
export PNP_INDEX="/usr/share/nagios/html/pnp4nagios/index.php"

Restart thruk

# /etc/init.d/thruk restart

Add broker npcdmod in /etc/nagios/nagios.cfg file

broker_module=/usr/lib/nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg

Restart Nagios

# /etc/init.d/nagios restart


To use npcdmod.o module, we need install pnp4nagios

# yum install pnp4nagios

Modify the /etc/pnp4nagios/npcd.cfg file in order to identify perfdata on server2

perfdata_spool_filename = perfdata-server2

Edit /etc/fstab file to mount NFS share

server1:/var/spool/pnp4nagios    /var/spool/pnp4nagios   nfs    defaults  0 0

Mount /var/spool/pnp4nagios

# mount /var/spool/pnp4nagios

Edit file /etc/nagios/nagios.cfg and add the npcdmod broker

broker_module=/usr/lib/nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg
# /etc/init.d/nagios restart


To use npcdmod.o module, we need install pnp4nagios

# yum install pnp4nagios

Modify the /etc/pnp4nagios/npcd.cfg file in order to identify perfdata on server3

perfdata_spool_filename = perfdata-server3

Edit /etc/fstab file to mount NFS share

server1:/var/spool/pnp4nagios    /var/spool/pnp4nagios   nfs    defaults  0 0

Mount /var/spool/pnp4nagios

# mount /var/spool/pnp4nagios

Edit file /etc/nagios/nagios.cfg and add the npcdmod broker

broker_module=/usr/lib/nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg
# /etc/init.d/nagios restart

How NCP daemon works ?


  1. Nagios execute plugin
  2. Npcdmod Store perfdata into Spool files
  3. On server1 npcdmod move Spool file to Spool Directory
  4. On server2 or server3 npcdmod move Spool file to NFS Share “Spool Directory”
  5. NPCD scan Spool directory
  6. Execute perfdata command
  7. Update RRD Database
  8. Write XML Meta data


Thruk local config : /etc/thruk/thruk_local.conf

<Component Thruk::Backend>
        name    = server1
        type    = livestatus
            peer          = /var/log/nagios/rw/live
            resource_file = /etc/nagios/resource.cfg
        name    = server2
        type    = livestatus
            peer          = server2:6557
        name    = server3
        type    = livestatus
            peer = server3:6557

Thruk interface :  http://server1/thruk/


If you have no graph into pnp4nagios interface, change the log_level in /etc/pnp4nagios/npcd.cfg


Restart the daemon

/etc/init.d/npcd restart

You see log in /var/log/pnp4nagios/npcd.log file

[02-18-2014 14:03:42] NPCD: No more files to process... waiting for 15 seconds
[02-18-2014 14:03:57] NPCD: Processing file 'perfdata-server2.1392728630'
[02-18-2014 14:03:57] NPCD: Processing file 'perfdata-server3.1392728625'
[02-18-2014 14:03:57] NPCD: No more files to process... waiting for 15 seconds
[02-18-2014 14:04:12] NPCD: Processing file 'perfdata-server2.1392728645'
[02-18-2014 14:04:12] NPCD: Processing file 'perfdata-server3.1392728640'
[02-18-2014 14:04:12] NPCD: No more files to process... waiting for 15 seconds
[02-18-2014 14:04:27] NPCD: Processing file 'perfdata-server2.1392728660'
[02-18-2014 14:04:27] NPCD: Processing file 'perfdata-server3.1392728655'
[02-18-2014 14:04:27] NPCD: No more files to process... waiting for 15 second

FAN 2.4



je suis fier de vous annoncer la disponibilité de la nouvelle monture FAN 2.4/

C’est la nouvelle version stable de FAN . L’iso est téléchargeable sur

Les nouveautés :


I’m very proud to announce the availability of a new version of FAN : 2.4.

This version of FAN is in stable status. You can download FAN 2.4 iso here :

Changes :

Get Trend on HP EVA Storage Array with check_wmi_plus

Hi all,

I am inspired on cacti evaperf to monitor HP EVA Storage Array and i wrote an ini file for check_wmi_plus plugin. You can use it with Nagios, Shinken, Centreon Engine, Icinga…It’s a free and easy solution to monitor the HP EVA Storage Array

So I suppose check_wmi_plus plugin is installed on your monitoring engine and “Command View EVA” is installed and working on Windows Server.

The WMI Class used :

  • Win32_PerfRawData_EVAPMEXT_HPEVAPhysicalDiskGroup
  • Win32_PerfRawData_EVAPMEXT_HPEVAHostPortStatistics
  • Win32_PerfRawData_EVAPMEXT_HPEVAHostConnection
  • Win32_PerfRawData_EVAPMEXT_HPEVAStorageArray
  • Win32_PerfRawData_EVAPMEXT_HPEVAStorageController

You can test the “HP WMI Storage Providers” service is running

/bin/wmic -U "login"%"password" //Host 'Select Name from Win32_PerfRawData_EVAPMEXT_HPEVAStorageController'

If your wmic command gets you this :

ERROR: Retrieve result data.

Solution :

Stop Winmgmt service
Restart HPWMISTOR service
Start Winmgmt service

So, here my config file ini for check_wmi_plus : checkhpeva.ini

[checkhpeva listphysicaldiskgroup]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAPhysicalDiskGroup

[checkhpeva physicaldiskgroup]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAPhysicalDiskGroup where Name="{_arg1}"

[checkhpeva listhostportstatistics]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostPortStatistics

[checkhpeva hostportstatistics]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostPortStatistics where Name="{_arg1}"
[checkhpeva listhostconnection]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostConnection

[checkhpeva hostconnection]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostConnection where Name="{_arg1}"
perf=QueueDepth||{Name} Average_Queue_Depth

[checkhpeva liststoragearray]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageArray

[checkhpeva storagearray]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageArray where Name="{_arg1}"

[checkhpeva liststoragecontroller]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageController

[checkhpeva storagecontroller]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageController where Name="{_arg1}"
  [checkhpeva listvirtualdisk]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAVirtualDisk

[checkhpeva virtualdisk]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAVirtualDisk where Name like "%{_arg1}%"


Save checkhpeva.ini file in check_wmi_plus.d directory. FYI, I dont want to be able the test on warn/critical criteria. it is an improvement to do 🙂

Create Nagios command :

define command{
  command_name                    check_hpeva_hostconnection
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s allhostconnection -a $ARG3$
  ;$ARG1$                         Compte
  ;$ARG2$                         Mot de passe
  ;$ARG3$                         physicaldiskgroup

define command{
  command_name                    check_hpeva_hostportstatistics
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s hostportstatistics -a $ARG3$
  ;$ARG1$                         Compte
  ;$ARG2$                         mot de passe
  ;$ARG3$                         hostportstatistics

define command{
  command_name                    check_hpeva_physicaldiskgroup
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s physicaldiskgroup -a $ARG3$
  ;$ARG1$                         Compte
  ;$ARG2$                         Mot de passe
  ;$ARG3$                         physicaldiskgroup

define command{
  command_name                    check_hpeva_storagearray
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s storagearray -a $ARG3$
  ;$ARG1$                         Compte
  ;$ARG2$                         Mot de passe
  ;$ARG3$                         storagearray

define command{
  command_name                    check_hpeva_storagecontroller
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s storagecontroller -a $ARG3$
  ;command_example                        !Administrateur!mdp!exemple
  ;$ARG2$                         Mot de passe
  ;$ARG3$                         storagecontroller

define command{
  command_name                    check_hpeva_virtualdisk
  command_line                    $USER1$/ -H $HOSTADDRESS$ -u "$ARG1$" -p "$ARG2$" -m checkhpeva -s virtualdisk -a $ARG3$
  ;$ARG1$                         Compte
  ;$ARG2$                         Mot de passe
  ;$ARG3$                         storagearray

Read this PDF here for more informations on wmi counter.

Screenshoot : Create services and you can display graph with pnp4nagios or Centreon



En attendant centreon 2.4, thruk propose son panorama view

Pour ceux qui suivent le projet de Centreon de près, la prochaine version 2.4 intègrera les widgets et bien plus encore. Une fonctionnalité très attendue pour ma part car on pourra afficher des graphes, l’état des services sur un même tableau de bord avec la possibilités de filtrer sur plusieurs critères, la rotation de plusieurs dashbord… Le but étant d’utiliser un seul et même outil pour personnaliser sa supervision via des tableaux de bord.

Néanmoins, si vous êtes impatient comme moi et que vous regardez un peu ce que propose les autres outils, j’ai dernièrement testé le panorama view de Thruk. C’est un nouveau plugin qui est apparu en version 1.36 de (sorti le 19 juil 2012) qui ressemble beaucoup au dashbord que propose Icinga. Ce plugin vous permet de créer autant de dashbord que vous voulez et de rajouter des widgets.Personnellement, j’apprécie beaucoup le fait qu’on peut déplacer et redimensionner ses widgets à foison.

Parmi les widgets fournis, on retrouvera :

  • l’état des ses hosts et services
  • la disponibilité des hosts et services (sous forme d’un camembert)
  • la métrologie provenant des graphes pnp
  • les métrics et graphes de ModGearman

Mais voilà en tant qu’utilisateur de Centreon, j’aurai bien aimé que mes graphes RRD s’affichent sous Thruk et heureusement que mon ami Tensibai a fourni un patch très intéressant : la possibilité d’afficher les graphes RRD via l’autologin key (un peu comme un cookie de session) et en fournissant le host et le service en paramètre.

Son utilisation est très simple; voici un petit howto pour l’activer :

  • Modifier la configuration d’un utilisateur pour activer l’autologin key
  • Allez dans Configuration>Users, choisissez notre utilisateur (pour ma part : nagiosadmin), puis dans l’onglet dans l’onglet “Centreon Authentification”
  • Générer un autologin key, puis sauvegarder

Pour générer un graphe automatiquement, il va falloir utiliser une url bien particulière :


Remplacer <USER> <KEY> <HOST> <SERVICE> par vos propres valeurs.

Maintenant dans Thruk en allant le panorama view, il faut utiliser le widget Pnp Graph

Dans le champ Graph, il faut utiliser l’url de Centreon avec fournissant les bons paramètres de <USER> <KEY> <HOST> <SERVICE>

A la fin, cela ressemble à ça chez moi :

Vous n’êtes pas convaincu : essayer donc de faire vos propres test sur le site :


Capacity planning avec Centreon, c’est possible

Voici un petit article qui va intéresser plus d’un sur la mise en place du capacity planning sous Centreon. On le retrouve aussi sous le nom de forecasting ou prediction quand on fait des recherches sous cacti ou rrdtool…

Rentrons dans le vif du sujet, je me suis inspiré de cet article et voici un exemple pour vous illustrer sa mise en oeuvre. Je vous passe les commentaires sur les algorithmes utilisés mais vous pouvez les lire ici et encore ici

Pour commencer, je vais prendre l’exemple de mon hôte qui s’appelle srv1 et son service Linux_FileSystem_/data_Usage. J’ai 2 données de performances used et size pour ce service

Nous allons créer 3 virtual metric dans Centreon>Views>Graphs>Metrics, il faudra sélectionner pour les 3, le hôte srv1 et le service Linux_FileSystem_/data_Usage

Voici la première : D2

  • Nom : D2 (c’est un nom arbitraire qu’on peux changer mais à changer aussi dans predict)
  • Type : VDEF
  • RPN Function : used,LSLSLOPE
  • Metric Unit : B
  • Les seuils : on n’est pas obligé de remplir

la seconde : H2

  • Nom : H2 (c’est un nom arbitraire qu’on peux changer mais à changer aussi dans predict)
  • Type : VDEF
  • RPN Function : used,LSLINT
  • Metric Unit : B
  • Les seuils : on n’est pas obligé de remplir

La dernière : predict

  • Nom : predict (un nom arbitraire qu’on peux changer aussi)
  • Type : CDEF
  • RPN Function : used,POP,D2,COUNT,*,H2,+
  • Metric Unit : B
  • Les seuils : on n’est pas obligé de remplir
  • Hidden : ne pas cocher

Quand tout est fait, aller admirer votre graphe dans les Views en sélectionnant l’hôte et le service associé. La donnée predict n’est pas affichée par défaut, il faut cliquer sur un graphe pour voir apparaître le choix des Components

Elle n’est pas belle la vie…

Version 2.3 de FAN

Je suis fier de vous annoncer la sortie de FAN 2.3, l’ISO est toujours disponible sur le site officiel dans la rubrique Download en 32 et 64 bits :

L’annonce officielle :

Au programme, les logiciels phares ont été mis à jour notamment :

  • Centreon 2.3.3
  • Nagvis 1.6.3
  • L’OS qui est passé en centos 5.7

Au niveau de la mise à jour de la version 2.2 -> 2.3, une page est dédiée à ce sujet. Il y a eu un gros travail de fait pour le passage à Nagvis 1.6. La mise à jour des maps se fait de manière transparente lorsqu’on update le rpm.

Dans la configuration du distribué, une nouvelle fonctionnalité fait son apparition : la possibilité de réceptionner des trap SNMP par un poller. Cette fonction n’est pas très bien connue des utilisateurs de Centreon et souvent pas assez documenté sur son utilisation. Vous allez donc pouvoir l’utiliser avec FAN, tout est expliquer ici :

Au niveau de la sauvegarde, le paquet rpm fan-backup a été remis à jour afin de fonctionner sous les différentes install de FAN, l’infos de trouve dans la FAQ.

Il y a aussi quelques fix au niveau des bugs qui ont été remontés. Je vous invite à lire le changelog pour plus de détail.


Thruk une alternative au cgi de Nagios

Vous connaissez très certainement les CGI de Nagios, l’interface web très sobre (même si elle a un peu évoluée) qui présente l’état des indicateurs de supervision. Elle a beaucoup de défaut, voici un petit panel :

  • ses très faibles performances lorsqu’on a des dizaines de milliers de services à afficher
  • non conçue pour le mode distribué. Elle peut l’être avec un peu de gymnastique entre nsca et du mode passif. Bref un gros bordel à configurer
  • s’appuie sur des fichiers locaux pour récupérer l’état des services, d’où sa lenteur
  • ne possède pas de filtres avancés (genre je veux tous les services hard, avec notification, qui sont en CRITICAL dont aucun downtime n’est planifié)
  • génère de la latence à Nagios

Bref, on peut en citer encore mais je vais m’arrêter là. C’est pourquoi je préfère utiliser Thruk. Une application web codée en perl et qui a l’avantage d’être performante et très rapide.

Ses atoûts :

  • elle s’appuie sur livestatus pour récupérer l’état des services et host. Livestatus étant un broker voulant d’être très rapide
  • Encore grâce à Livestatus, thruk peut afficher les indicateurs de plusieurs Nagios. Elle fonctionne donc très bien avec le mode distribuée
  • Possède des filtres avancés
  • Permet de sauvegarder en tant que favoris ces propres tableaux de bord
  • On peut changer son apparence. Il y a les thèmes Vautour, le Nagios Classic (tout moche !), Nuvola
  • Compatible avec Icinga et Shinken
  • s’installe facilement avec OMD

Bon, y a pas que des avantages je vous dirai, j’ai noté quelques inconvénients mais ça reste très soft :

  • des dépendances à Perl à satisfaire si vous voulez pas que l’installeur vous insulte. Mais il propose aussi de les télécharger et les installer pour vous 😉
  • en terme de mise à jour, il faut faire quelques manip pour retrouver ses favoris, les logos, sa configuration
  • intégrer thruk avec Apache nécessite l’installation de fast-cgi ou
  • Thruk c’est un démon supplémentaire. Bon ok celui-là c’est pas réellement un inconvénient.


Voici quelques screenshots :

Vous n’êtes pas convaincu, alors voici une démo. Login nagiosadmin / nagiosadmin

Quelques doc pour l’installer :

Lancer des scénarios avec Centreon Web Application Analytics

Centreon Web Application Analytics est un plugin très intéressant que j’ai trouvé sur la forge communautaire de Centreon.

Il permet de lancer des scénarios Web grâce à Selenium. Comment cela fonctionne :

Son exécution se déroule techniquement en 3 étapes :

  • Nagios exécute la sonde check_centreon_waa avec comme paramètre le scénario web fourni sous forme de fichier
  • La dite sonde se connecte au serveur Selenium et demande l’exécution des actions du scénario
  • Le serveur Selenium lance sur la machine un navigateur web (Firefox) pour effectuer les actions

L’enregistrement du scénario web se fait à partir du module Selenium IDE qu’il faut installer dans son firefox.

La doc d’installation et de configuration est présente sur

$ ./check_centreon_waa -c 60 -w 50 -d /var/lib/centreon_waa/ -t -r localhost:4444
CHECKWEB OK - Execution time = 9.93s Test Ok 6/6 |'time'=9.93s;50;60;0; 'availability'=100%;;;0;100


L’intégration dans Centreon permet de sortir les graphes suivants :


Les plus par rapport à cucumber-nagios :

  • L’interface conviviale de Selenium IDE pour créer et tester ces scénarios Web
  • Le plugin sait communiquer avec un selenium server via un port TCP. On peut donc dédier une machine (VM par ex) uniquement pour le Selenium Server (machine virtuelle java) afin de ne pas installer le tout sur un poller Nagios
  • L’utilisation du serveur X virtuel Xvfb pour le lancement de firefox

Bientôt, j’écrirai une petite doc pour l’installation des outils pour FAN.


FAN 2.2 est version stable

J’ai le plaisir de vous annoncer la nouvelle version de FAN en version stable 2.2

Comme toujours, vous pouvez télécharger l’iso sur :

Vous pouvez aussi tester FAN sur le site de FAN Demo

Pas de gros changements depuis la RC1 plutôt des corrections de bugs :

  • Mise à jour NagVis 1.5.10
  • BugFix #3424410 : Error adding poller with centreon 2.2
  • BugFix #3415945 : SNMP Community hardcoded in Centreon
  • BugFix #3415929 : Fix centreon command check_san consistency
  • BugFix #3415889 : Fix centreon command check_centreon_nb_connections misconfiguration
  • BugFix #3415883 : Installation misspell and contistency
  • BugFix #3415877 : Fix centreon command check_manubulon_snmp_mem misconfiguration
  • BugFix #3386657 : No .bashrc for root in FAN 2.2 RC1
  • BugFix #3367029 : Fix centreon command check_snmp definition wrong

Comme pour la release candidate, cette version s’accompagne du support en 64bits et la configuration de la supervision en distribuée. Les plus importants liens à consulter :

Un grand merci à kult pour avoir testé la FAN 2.2 et remonté des bugs Si vous rencontrez le moindre problème, n’hésitez pas à les remonter dans le tracker ; venir rechercher des solutions sur le forum ou IRC

La RC1 de FAN 2.2 est sortie


C’est avec un mois de juillet pluvieux cet été que j’ai pris le temps de travailler sur la nouvelle version de FAN 2.2 et non de bronzer sur la plage 😉

Dans cette première release candidate, le plus gros changement est très certainement sur le support des architectures 64 bits. Cette fonctionnalité a été très longuement demandée comme nous le montre les [ideas de FAN||en|FAN IDEAS]. On va aussi retrouver comme changement :

  • Nagios 3.3.1
  • Centreon 2.2.2
  • NagVis 1.5.9
  • MKLivestatus broker

L’article officielle de la news de trouve ici

Pour l’utilisation du broker Mklivestatus, une page est dédiée à ce sujet. Attention, NDO doit être toujours utilisé étant donnée que le monitoring dans Centreon se base sur celui-ci.

Pourquoi une RC et non une version stable ?

Même si il n’y a pas de gros changement dans cette version, les raisons sont dûes à la nouvelle version de Nagios qui est sorti la semaine dernière et le support 64 bits.

Pour finir un grand merci à:

  • kult pour avoir remonter pas mal de bugs et tester la FAN 64 bits