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

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

Install NFS packages

1
# yum install nfs-utils nfs-utils-lib

Configuration NFS /etc/exports

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

Restart NFS daemon

1
# /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

1
2
perfdata_spool_filename = perfdata-server1
log_level = 1

Restart NPCD daemon

1
# /etc/init.d/npcd restart

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

1
2
3
touch /var/www/.thruk
chown apache:apache /var/www/.thruk
vi /var/www/.thruk

Paste the content :

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

Restart thruk

1
# /etc/init.d/thruk restart

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

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

Restart Nagios

1
# /etc/init.d/nagios restart

Server2

To use npcdmod.o module, we need install pnp4nagios

1
# yum install pnp4nagios

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

1
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

1
# mount /var/spool/pnp4nagios

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

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

Server3

To use npcdmod.o module, we need install pnp4nagios

1
# yum install pnp4nagios

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

1
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

1
# mount /var/spool/pnp4nagios

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

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

How NCP daemon works ?

pnp4nagios

  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

Server1

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

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

Thruk interface :  http://server1/thruk/

thruk_001

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

log_level=-1

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

Installation de Rudder

Logo-Rudder-fond-transparent-1

Un article pour aborder l’installation et la configuration de Rudder que j’ai testé il y a cela un an, puis je viens de découvrir les dernières nouveautés de la version 2.8. Rudder est ce qu’on appelle un outil de gestion de configuration et il s’appuie notamment sur CFEngine 3. Lorsqu’on a un parc de serveurs assez conséquent qu’il soit hétérogène ou non, il devient très fastidieux de faire des tâches répétitives. Par exemple, s’assurer que la configuration des routes soient bonnes, la gestion du fichier /etc/hosts (lorsqu’on n’a pas de DNS), appliquer la même politique du sécurité sur le serveur ssh, installer un package… La liste est très longue 🙂

Sans rentrer dans les détails, Rudder se compose de 2 gros composants :

  • Rudder Agent : une intégration de l’agent CFEngine et de celui de FusionInventory, qui en se connectant au Rudder Server, va récupérer les rules (promises) à appliquer et envoyer l’inventaire de la machine.
  • Rudder Server : Qui se compose de CFEngine et d’une interface Web. Cette dernière qui reste très intuitive va nous permettre d’intégrer les agents Rudder, composer ces rules et les appliquer sur un ou plusieurs groupes d’agents.

Pourquoi Rudder ? CFEngine est un outil très puissant dont l’apprentissage du langage reste très difficile lorsqu’on commence à l’utiliser. Sa configuration se base essentiellement sur des fichiers textes. Et c’est là que Rudder tire toute sa puissance ! Grâce à son interface web et des promises pré-définies, vous allez pouvoir créer très facilement vos propres promises et choisir les agents sur lesquels les appliquer. D’ailleurs personnellement j’ai encore du mal avec la syntaxe de CFEngine et Rudder accélère énormément le déploiement de mes config.

Pour faire une petite comparaison, Rudder c’est un peu comme Puppet Dashboard mais il n’existe pas de version Enterprise avec une limitation des nodes !

Je vais utiliser 2 vm que j’appelerai rudder-server et rudder-agent. Des packages touts prêt existents pour Debian/Ubuntu, Centos/Redhat et SLES.

Mon installation se fera sur une Centos 6 et je vais utiliser la dernière version du Rudder de dispo. A ce jour, c’est le 2.8 (sorti le 07/11/2013)

Installation du Server

Si vous n’avez pas de DNS, il faut modifier le fichier /etc/hosts et rajouter les informations relatives aux 2 VMs

Un exemple :

192.168.122.10 rudder-server
192.168.122.15 rudder-agent

 

Configuration du repository YUM :

1
rudder-server # vi /etc/yum.repos.d/rudder.repo

copier les informations suivantes :

1
2
3
4
5
[Rudder_2.8]
name=Rudder 2.8 Repository
baseurl=http://www.rudder-project.org/rpm-2.8/RHEL_6/
gpgcheck=1
gpgkey=http://www.rudder-project.org/rpm-2.8/RHEL_6/repodata/repomd.xml.key

Puis lancer l’install :

1
rudder-server # yum install -y rudder-server-root

Après l’installation, une première configuration est nécessaire, lancer la commande suivante :

1
rudder-server # /opt/rudder/bin/rudder-init.sh

Répondez aux questions, à titre d’exemple :

  • Hostname : rudder-server (nom du serveur)
  • Allowed networks : 192.168.122.0/24 (le réseau à autoriser)
  • sample data : no (Information de demo)
  • LDAP database : yes (promises à installer)

J’ai rencontré un soucis au premier lancement, j’ai dû redémarrer le serveur ldap puis relancer la commande :

rudder-server # /etc/init.d/slapd restart

 

Après l’installation, prenez votre navigateur préféré et aller sur l’url : https://rudder-server/rudder/

Identifiant : jon.doe/secret

Sélection_013

Si tout se passe bien, vous devriez avoir cette page ensuite :

Sélection_015

Le serveur d’application Jetty peut mettre un certain temps à se démarrer. Si vous rencontrez des soucis, analyser le fichier de log

1
rudder-server # tail -f -n 20 /var/log/rudder/webapp/YYY_MM_DD.stderrout.log

Installation de l’Agent

Répéter les mêmes actions que pour la partie server : configuration du fichier /etc/hosts et yum.

Puis lancer l’install :

rudder-agent # yum install -y rudder-agent

Configurer l’agent rudder en renseignant le nom du serveur Rudder à contacter :

rudder-agent # echo rudder-server &gt; /var/rudder/cfengine-community/policy_server.dat

Démarrage l’agent :

rudder-agent # /etc/init.d/rudder-agent start

Forcer la communication avec le serveur Rudder si vous ne souhaitez pas attendre que l’agent le fasse de lui-même :

rudder-agent # /var/rudder/cfengine-community/bin/cf-agent -KI

Vous pouvez vérifier que la communication s’est bien faite en lançant cette commande sur le serveur rudder :

rudder-server # find /var/rudder/inventories -name "*.ocs"

Vous devriez voir l’inventaire de fusion dans /var/rudder/inventories/incoming

Petite subtilité : si vous n’avez pas de DNS, il faut impérativement que l’agent puisse résoudre le nom du serveur rudder et inversement. Auquel cas, vous allez rencontrer des difficultés de communication entre l’agent et le serveur.

Visualisation de l’Agent depuis Rudder Server

Depuis l’interface, vous devriez voir votre Agent dans Node Management > Accept new nodes. Ce dernier doit être accepté afin de pouvoir l’utiliser.

Sélection_016

Cochez puis cliquer sur Accept into Rudder

Si vous partez maintenant dans Node ManagementList nodes vous devriez le voir apparaitre :

Sélection_017

Si vous cliquez sur l’agent, vous allez retrouvez plusieurs information dont notamment l’inventaire effectué par FusionInventory.

Utilisation de Rudder

L’installation de Rudder (serveur et l’agent) a été plus tôt simple. Nous allons voir maintenant comment utiliser l’interface et les possibilités qu’elle offre. Je vais prendre 2 exemples corrects :

  • Sur l’ensemble de mon parc de serveurs j’ai notamment quelques Centos 5 et 6. Afin de ne pas trop solliciter notre bande passante internet, j’ai créé un miroir en local des dépôts de Centos. Je souhaite donc pousser sur tous mes serveurs Centos la config yum associé à mon dépôt local.
  • Second exemple : n’ayant pas de DNS il faut gérer le fichier /etc/hosts afin que mes serveurs Centos puisse joindre mon serveur de dépot yum

Tout d’abord, il faut connaitre les objets que Rudder utilise :

  • Les Groups : ils vont nous permettre de rassembler des Nodes (Agents), tous mes serveurs linux, ou CentOS. On verra qu’ils peuvent être dynamiques ou statiques
  • Les Techniques : on peut voir cela comme des templates de Promises. Rudder propose un panel de techniques permettant de gérer différentes configuration. Par exemple, la configuration du service ssh, avec toutes les options qui la composent.
  • Les Directives : On instancie une directive à partir d’une technique. Une directive offre la possibilité de paramétrer des valeurs. C’est un peu l’équivalent d’une promise. Par exemple, dans une configuration particulière du service ssh , je désire que root n’a pas le droits de s’y connecter, l’authentification se fait uniquement par clé ssh, l’authentification par mot de passe est désactivée.
  • Les Rules : c’est l’application d’une ou plusieurs Directives sur un ou plusieurs Groups. A travers du menu de gestion des Rules on peut voir leur état. Si Rudder les a bien déployé ou non.

Les Groups

Je vais créer 2 groupes que je vais nommer Centos 5 et Centos 6. Dans l’interface il faut aller : Node Management > Groups > Create a new item

Sélection_018

Il faut donner un nom “Centos 5”, une description et pour ma part je coche Dynamic comme type et pour finir, Save

Sélection_032

Prochaine étape paramétrer ce groupe en effectuant des filtres :

  • Operating System Name = CentOS
  • Operating System Version Regex 5.*
  • pour finir cliquer sur Search pour visualiser les nodes qui correspondent aux critères.

Dans le cadre d’un groupe dynanique, les nouveau node du type CentOS 5 seront automatiquement rattachés à ce groupe.

Pour finir, cliquer sur Save et ajouter si nécessaire un commentaire.

La création du prochain groupe les CentOS 6 se fait de la même manière mais on va utiliser la fonctionnalité de clonage de groupe et changer les critères :

Sélection_034

  • Operating System Name = CentOS
  • Operating System Version Regex 6.*

Si vous cliquez sur Search, vous devriez voir apparaitre le node rudder-agent

Directives

Pour la création d’une nouvelle directive, il faut aller dans Configuration Policy > Directives. Pour le moment, il n’y a de technique qui gère les repo YUM alors que pour APT, il en existe une dans Application management > APT package manager configuration. C’est pas grave, on va utiliser Distributing files > Enforce a file content.

Sélection_023

On clique que Create Directive

Sélection_024

On donne un nom et une description par ex. : “yum config local miroir centos 5/6” puis cliquer sur Configure

Sélection_026

En terme de configuration, j’ai choisi :

  • Path : /etc/yum.repos.d/CentOS-Base.repo
  • Enforce the content of the file” coché
  • File Content
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# YUM repo Centos configuration
# Don't change this file
# it is managed by rudder
 
[base]
name=CentOS-$releasever - Base
baseurl=http://mirrorcentos/centos/$releasever/os/$basearch/
gpgcheck=1
enabled=1
 
[updates]
name=CentOS-$releasever - Updates
baseurl=http://mirrorcentos/centos/$releasever/updates/$basearch/
gpgcheck=1
enabled=1
 
[extras]
name=CentOS-$releasever - Extras
baseurl=http://mirrorcentos/centos/$releasever/extras/$basearch/
gpgcheck=1
enabled=1

On clique sur Save pour finaliser la configuration de la directive.

On attaque la création de la seconde directive selon le même principe. Mais cette fois-ci, il faudra gérer le fichier /etc/hosts afin de connaitre le host mirrorcentos. Son adresse ip par ex est 192.168.122.99

On va utiliser la technique System settings > Networking > Hosts settings

Sélection_027

On renseigne un nom et une description

Sélection_028

 

Dans Hosts setting #1 il faut renseigner les informations associées au host. Si besoin, on peut en rajouter un autre en cliquant sur Add another.

Rules

On va maintenant créer notre première rule il faut aller dans “Configuration Policy” > Rules > “Add a new rule”

Sélection_029

Au niveau du paramétrage :

Sélection_030

Rien de plus simple, on va sélectionner les 2 directives créées et les 2 groupes dynamiques :

  • rule : yum config local miroir centos 5/6
  • rule : mirrorcentos host
  • group : Centos 5
  • group : Centos 6

Cliquer sur Save pour créer la rule. Il faut attendre quelques minutes pour que la rule s’applique sur le node. Mais si vous n’avez pas de problème de résolution de noms (agent et serveur), voire de syncho NTP vous devriez voir les rules s’appliquer sans problème :

Sélection_031

On peut aussi vérifier que les modifications ont bien été déployées :

rudder-agent # cat /etc/hosts
rudder-agent # cat /etc/yum.repos.d/CentOS-Base.repo

Pour aller plus loin

Il est possible d’écrire ces propres Techniques et l’intégrer dans Rudder une doc est disponible. Il faut au minimum connaitre la syntaxe de CFEngine. Pas très pratique pour un débutant ou soit passé par une formation.

CFengine sous Windows : l’agent existe mais il est payant. La société Normation (éditrice de la solution Rudder) propose une version de leur agent pour Windows. Perso, je ne l’ai pas testé.

Il existe aussi CFEngine en version Enterprise, voici un comparatif https://cfengine.com/cfengine-comparison

Si vous souhaitez discuter avec les développeurs et la communauté un channel irc est disponible : #rudder sur Freenode. Une forge est aussi disponible pour remonter des bugs ou des features.

Références :

http://www.rudder-project.org

https://cfengine.com/docs/3.5/index.html

http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/

FAN 2.4

[Français]

Bonjour,

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 http://www.fullyautomatednagios.org/wordpress/download/

Les nouveautés :

[English]

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 : http://www.fullyautomatednagios.org/wordpress/download/

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
display=Name

[checkhpeva physicaldiskgroup]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAPhysicalDiskGroup where Name="{_arg1}"
display=DriveLatencyus
display=DriveQueueDepth
display=ReadKBPers
display=ReadLatencyus
display=ReadReqPers
display=WriteKBPers
display=WriteLatencyus
display=WriteReqPers
perf=DriveLatencyus||DriveLatencyus
perf=DriveQueueDepth||DriveQueueDepth
perf=ReadKBPers|KB/s|ReadKBPers
perf=ReadLatencyus||ReadLatencyus
perf=ReadReqPers|/s|ReadReqPers
perf=WriteKBPers|KB/s|WriteKBPers
perf=WriteLatencyus||WriteLatencyus
perf=WriteReqPers|/s|WriteReqPers

[checkhpeva listhostportstatistics]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostPortStatistics
display=Name|#

[checkhpeva hostportstatistics]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostPortStatistics where Name="{_arg1}"
display=AvQueueDepth
display=ReadKBPers
display=ReadLatencyus
display=ReadReqPers
display=WriteKBPers
display=WriteLatencyus
display=WriteReqPers
perf=AvQueueDepth||AvQueueDepth
perf=ReadKBPers|KB/s|KB_Read_From_Cache_Per_Second
perf=ReadLatencyus||ReadLatencyus
perf=ReadReqPers|/s|ReadReqPers
perf=WriteKBPers|KB/s|KB_Write_Per_Second
perf=WriteLatencyus||WriteLatencyus
perf=WriteReqPers|/s|WriteReqPers
[checkhpeva listhostconnection]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAHostConnection
display=Name|#

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

[checkhpeva liststoragearray]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageArray
display=Name|#

[checkhpeva storagearray]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageArray where Name="{_arg1}"
display=TotalhostKBPers
display=TotalhostReqPers
perf=TotalhostKBPers|KB/s|Total_Host_KB_Per_Second
perf=TotalhostReqPers|/s|Total_Host_Requests_Per_Second

[checkhpeva liststoragecontroller]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageController
display=Name|#

[checkhpeva storagecontroller]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAStorageController where Name="{_arg1}"
display=PercentDataTransferTime
display=PercentProcessorTime
perf=PercentDataTransferTime|%|PercentDataTransferTime
perf=PercentProcessorTime|%|PercentProcessorTime
  [checkhpeva listvirtualdisk]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAVirtualDisk
display=Name|#

[checkhpeva virtualdisk]
query=Select * from Win32_PerfRawData_EVAPMEXT_HPEVAVirtualDisk where Name like "%{_arg1}%"
display=ReadHitKBPers
display=ReadHitLatencyus
display=ReadHitReqPers
display=ReadMissKBPers
display=ReadMissLatencyus
display=ReadMissReqPers
display=WriteKBPers
display=WriteLatencyus
display=WriteReqPers
perf=ReadHitKBPers|KB/s|ReadHitKBPers
perf=ReadHitLatencyus||ReadHitLatencyus
perf=ReadHitReqPers|/s|ReadHitReqPers
perf=ReadMissKBPers|KB/s|ReadMissKBPers
perf=ReadMissLatencyus||ReadMissLatencyus
perf=ReadMissReqPers|/s|ReadMissReqPers
perf=WriteKBPers|KB/s|WriteKBPers
perf=WriteLatencyus||WriteLatencyus
perf=WriteReqPers|/s|WriteReqPers

 

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$/check_wmi_plus.pl -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$/check_wmi_plus.pl -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$/check_wmi_plus.pl -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$/check_wmi_plus.pl -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$/check_wmi_plus.pl -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$/check_wmi_plus.pl -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 :

http://IP/centreon/include/views/graphs/generateGraphs/generateImage.php?username=<USER>&akey=<KEY>&hostname=<HOST>&service=<SERVICE>

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 : http://demo.fullyautomatednagios.org/thruk/

 

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 : http://www.fullyautomatednagios.org/wordpress/download/

L’annonce officielle : http://www.fullyautomatednagios.org/wordpress/2012/03/06/fan-2-3-available/

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 : http://www.fullyautomatednagios.org/wordpress/how-to-manage-trap-by-a-poller/

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 http://forge.centreon.com/projects/centreon-web-application-analytics/wiki

$ ./check_centreon_waa -c 60 -w 50 -d /var/lib/centreon_waa/ -t 01-webtest-lkco.gezen.fr -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.

 

Dotclear 2 WordPress

Après quelques années pour avoir utilisé Dotclear, j’ai décidé de changer mon moteur de blogging pour WordPress. Bien que je suis attaché à utiliser des produits développés par des communautés françaises, j’ai trouvé que Dotclear commençait à s’essouffler et ne proposait pas autant de fonctionnalités que WordPress. J’avoue que j’ai un peu craqué pour WordPress car

  • il y a de nombreux plugins disponibles
  • sa convivialité pour son panel d’administration
  • Les thèmes proposés dont Mystique que je trouve génial pour personnalisé le skin

La migration de Dotclear vers WordPress s’est fait très facilement grâce au plugin dc22wp2. Pour ma part, l’étape a consisté de :

  1. installer un wordpress 3.0.4 (dernière version WP supporté par le plugin dc22wp2)
  2. installer le plugin dc22wp2
  3. effectuer la migration
  4. et pour finir upgradé wordpress 3.0.4 à la dernière version 3.3.1

Il reste encore quelques articles à retaper mais la majeure partie a été récupérée.

Le dotclear reste néanmoins disponible sur http://lkco.gezen.fr/dotclear/