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 :

[root@rhel ~]# yum update
[root@rhel ~]# yum install nsca-client

Sous debian-like :

[root@debian ~]# apt-get update
[root@debian ~]# apt-get install nsca-client

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 :

[root@rhel ~]# yum update
[root@rhel ~]# yum install nsca xinetd

Sous debian-like :

[root@debian ~]# apt-get update
[root@debian ~]# apt-get install nsca xinetd

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

# default: on
# description: NSCA
service nsca
{
Flags = REUSE
socket_type = stream
wait = no
user = centreon-engine
group = centreon-engine
server = /usr/bin/nsca
server_args = -c /etc/nsca.cfg --inetd
log_on_failure += USERID
disable = no
}

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

log_facility=daemon
pid_file=/var/run/nsca.pid
server_port=5667
server_address=xxx.xxx.xxx.xxx
nsca_user=centreon-engine
nsca_group=centreon-engine
debug=1
command_file=/var/lib/centreon-engine/rw/centengine.cmd
alternate_dump_file=/var/lib/centreon-engine/rw/nsca.dump
aggregate_writes=0
append_to_file=0
max_packet_age=30
decryption_method=1

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 :

nsca 5667/tcp # Nagios Agent - NSCA

On redémarre xinetd :

[root@nsca_server ~]# service xinetd stop
[root@nsca_server ~]# service xinetd start

On vérifie son fonctionnement avec :

[root@nsca_server ~]# netstat -at | grep nsca
tcp 0 0 *:nsca *:* LISTEN

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 :

[root@nsca_server ~]# chmod 755 /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 :

config_passif

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

pending2

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 :

root@uapachet:~# echo -e "uapachet\ttest_nsca\t0\tService OK" | send_nsca -H 192.168.124.248 -p 5667 -c /etc/send_nsca.cfg
1 data packet(s) sent to host successfully.

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

service_ok

La commande « send_nsca »

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

[root@client ~]# send_nsca

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 :

[root@nsca_client ~]# echo -e "serveur\ttest_nsca\t1\tX" | send_nsca -H serveur_centreon -p port -c /etc/nagios/send_nsca.cfg

ou de manière plus lisible :

[root@nsca_client ~]# echo "serveur;test_nsca;1;X" | send_nsca -H serveur_centreon -p port -c /etc/nagios/send_nsca.cfg -d ";"

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.

1 réponse
  1. rza
    rza dit :

    Bonjour,
    Je n’arrive pas à vous joindre sur votre autre tuto, installation de centreon 2.7
    J’ai suivi la procédure mais le centreon broker ne démarre pas
    systemctl start cbd.service failed

    systemctl start cbd
    Job for cbd.service failed because the control process exited with error code. See « systemctl status cbd.service » and « journalctl -xe » for details.

    systemctl status cbd
    â cbd.service – SYSV: Centreon Broker
    Loaded: loaded (/etc/rc.d/init.d/cbd)
    Active: failed (Result: exit-code) since lun. 2016-11-07 14:29:45 CET; 28s ago
    Docs: man:systemd-sysv-generator(8)
    Process: 60755 ExecStart=/etc/rc.d/init.d/cbd start (code=exited, status=1/FAILURE)

    nov. 07 14:29:45 localhost.localdomain systemd[1]: Starting SYSV: Centreon Broker…
    nov. 07 14:29:45 localhost.localdomain cbd[60755]: The cbd binary can’t be run.
    nov. 07 14:29:45 localhost.localdomain systemd[1]: cbd.service: control process exited, code=exite…s=1
    nov. 07 14:29:45 localhost.localdomain systemd[1]: Failed to start SYSV: Centreon Broker.
    nov. 07 14:29:45 localhost.localdomain systemd[1]: Unit cbd.service entered failed state.
    nov. 07 14:29:45 localhost.localdomain systemd[1]: cbd.service failed.
    Hint: Some lines were ellipsized, use -l to show in full.

    Comment fixer cette erreur svp ?

    Répondre

Laisser un commentaire

Participez-vous à la discussion?
N'hésitez pas à contribuer!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.