Les checks passifs dans Centreon.

Introduction

Il y a deux types de checks dans Centreon, les checks actifs (par défaut) et les checks passifs.

La plupart des checks effectués par Centreon sont des checks actifs. C’est le serveur Centreon qui initie l’action de vérifier l’état d’un service.

Dans le cas d’un check passif c’est le client qui met à jour la valeur d’un service. C’est intéressant dans les cas suivants :

• il est compliqué d’ouvrir les accès dans le sens serveur centreon -> serveur monitoré, mais c’est plus facile dans l’autre sens
• on veut monitorer la sortie d’un cron/d’un script. Pour récupérer l’état de sortie d’un script de backup par exemple
• monitorer un service qui est asynchrone

La mise en place est très simple, il faut installer et configurer NSCA côté serveur et côté client.

Installation côté client

On met à jour la liste des paquets et on installe le paquet nsca-client. Pour Redhat le paquet se trouve dans le dépôt EPEL :

Sous debian-like :

On configure ensuite le client NSCA en créant le fichier /etc/send_nsca.cfg. Les paramètres sont :

• password : qui définit une phrase pour encoder les requêtes sur le réseau
• decryption_method : qui définit l’encodage sur le réseau

Attention : le password est le même sur l’ensemble des clients et sur le serveur. Il est encodé sur le réseau, mais apparaît en clair dans le fichier de configuration. Il faut donc faire attention au droit de ce fichier.

Installation côté serveur

On met à jour la liste des paquets et on installe le paquet nsca-client. Pour Redhat le paquet se trouve dans le dépôt EPEL :

Sous debian-like :

On crée le fichier /etc/xinetd.d/nsca pour configurer xinetd avec nsca :

On crée le fichier /etc/nsca.cfg pour configurer NSCA :

Le paramètre server_address correspond à l’adresse ip sur laquelle le serveur écoute.

On met à jour le fichier /etc/services en ajoutant la ligne :

On redémarre xinetd :

On vérifie son fonctionnement avec :

On donne les droits d’exécution à l’utilisateur centreon-engine (c’est l’utilisateur définit dans le fichier /etc/nsca.cfg) sur /usr/bin/nsca :

La configuration de NSCA côté serveur est terminé.

Configuration dans Centreon

Dans ce partie, je vais utiliser les valeurs suivantes, qui correspondent à mon environnement :

• serveur centreon : 192.168.124.248
• port nsca serveur centreon : 5667
• client ncsa : uapachet
• service « passifs »: test_nsca

On se rend dans Configuration -> Services, on clique sur « Add » et on configure notre service ainsi :

Une fois le service configuré et le poller relancé, on remarque que l’état de ce service est dans un état « Pending » :

C’est une valeur d’attente avant la première initialisation. Depuis le serveur monitoré on utilise alors la commande « send_nsca » pour mettre à jour la valeur du service :

On constate alors que l’état du service est passé de « Pending » à « Ok » :

La commande « send_nsca »

La commande send_nsca permet d’envoyer un signal configurable au serveur centreon. Voici la syntaxe de la commande :

NSCA Client 2.9.1
Copyright (c) 2000-2007 Ethan Galstad (www.nagios.org)
Last Modified: 01-27-2012
License: GPL v2
Encryption Routines: AVAILABLE

Usage: send_nsca -H [-p port] [-to to_sec] [-d delim] [-c config_file]

Options:
= The IP address of the host running the NSCA daemon
[port] = The port on which the daemon is running – default is 5667
[to_sec] = Number of seconds before connection attempt times out.
(default timeout is 10 seconds)
[delim] = Delimiter to use when parsing input (defaults to a tab)
[config_file] = Name of config file to use

Note:
This utility is used to send passive check results to t
0: ok
1: warning
2: criticalhe NSCA daemon. Host and
Service check data that is to be sent to the NSCA daemon is read from standard
input. Input should be provided in the following format (tab-delimited unless
overriden with -d command line argument, one entry per line):

Service Checks:
[tab][tab][tab][newline]

Host Checks:
[tab][tab][newline]

When submitting multiple simultaneous results, separate each set with the ETB
character (^W or 0x17)

Les signaux ont la syntaxe suivante :

host:delim:services:delim:status:delim:output

Le délimiteur par défaut est la tabulation, mais on peut en définir un différent avec l’option -d. Le statut prend les valeurs suivantes :

0: Ok
1: Warning
2: Critical

Si on veut signifier au serveur centreon que le service test_nsca de la machine serveur est warning avec une valeur de X, il faudra exécuter la commande suivante :

ou de manière plus lisible :

Conclusion

Les checks passifs sont très faciles à mettre en place sous Centreon. De par leur facilité d’intégration (simple commande à glisser dans un script, dans un cron), ils élargissent les possibilités de monitoring de Centreon.