Vous êtes ici:

NSCA (Nagios Service Check Acceptor) est un protocole de communication sécurisé permettant d’envoyer des informations à destination des contrôles passifs d’une supervision Nagios ou équivalente.
Les hôtes envoient les informations par l’intermédiaire d’un exécutable et le serveur de supervision réceptionne le résultat par l’intermédiaire d’un daemon NSCA. Celui-ci envoie les informations dans le fichier des commandes externes. le moteur de supervision traitera ensuite les informations selon ses disponibilités.Il est obligatoire d’activer les commandes externes du moteur de supervision.
MAJ du 29 juin 2019, dépoussiérage de mon article avec la nouvelle version de Centreon 19.04.x
MAJ du 25 juillet 2019 avec l'agent NSCLIENT ++

1 Installation de NSCA sur le serveur de supervision

L’installation de NSCA nécessite l’utilisation d’un service comme inetd ou xinetd afin d’optimiser les ressources. xinetd est vivement conseillé car il permet de sécuriser au mieux les connections avec l’extérieur. Nous devrons télécharger le paquet NCSA (actuellement la dernière version est la 2.9.2) se trouvant sur le site de Nagios. Pour CentOS, il n'est pas possible d'utiliser le rpm car celui-ci est lié à Nagios et donc incompatible avec Centreon.

1.1 Moteur Nagios

1.1.a Compilation

Vérifiez l’installation du service inetd ou xinetd. Privilégiez l’installation de xinetd.

apt-get install xinetd -y

Téléchargez les prérequis.

apt-get install wget libmcrypt-dev -y

Décompressez l’archive NSCA dans le dossier /usr/local/src

cd /usr/local/src
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nsca-2.9.2.tar.gz
tar xzf nsca-2.9.2.tar.gz
cd nsca-2.9.2

Préparez la compilation

./configure

La préparation de la compilation doit retourner ce résultat.

*** Configuration summary for nsca 2.9.2 12-07-2016 ***:

 General Options:
 -------------------------
 NSCA port:  5667
 NSCA user:  nagios
 NSCA group: nagios


Review the options above for accuracy.  If they look okay,
type 'make all' to compile the NSCA daemon and client.

Le port NSCA sera le port par défaut 5667 et nous utiliserons le même groupe et le même utilisateur que le moteur de supervision nagios. Compilez NSCA.

make all

Copions les fichiers dans le dossier du moteur nagios. Adaptez en fonction de votre configuration.

cp src/nsca /usr/local/nagios/bin
chown nagios:nagios /usr/local/nagios/bin/nsca
chmod +x /usr/local/nagios/bin/nsca
cp sample-config/nsca.cfg /usr/local/nagios/etc
chown nagios:nagios /usr/local/nagios/etc/nsca.cfg

1.1.b Configuration inetd

Modifiez le fichier /etc/inetd.conf si vous utilisez inet.d, rajoutez la ligne.

nsca    stream  tcp     nowait  nagios /usr/sbin/tcpd /usr/local/nagios/bin/nsca -c /usr/local/nagios/etc/nsca.cfg --inetd

Relancez inetd.

service openbsd-inetd restart

1.1.c Configuration xinetd

Créez un fichier nsca dans le dossier /etc/xinetd.d

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

Appliquez la nouvelle configuration

service xinetd reload

1.2 Moteur Centreon

Installation à privilégier
Actuellement, au vu des performances de Centreon, c'est l'installation à privilégier. Nous avons le choix d'installer xinetd ou de créer un service avec systemd.

1.2.a Installation avec xinetd

Vérifiez l’installation du service inetd ou xinetd. Privilégiez l’installation de xinetd.

Debian

apt-get install xinetd -y

CENTREON

yum install xinetd -y

1.2.b Installation et compilation de NSCA

Téléchargez les prérequis. Attention pour Centreon sur CentOS, il faut installer provisoirement le dépôt epel pour la librairie libmcrypt.

Debian

apt-get install wget libmcrypt-dev -y

CENTREON

yum install epel-release -y
yum install gcc wget libmcrypt-devel -y
yum remove epel-release -y

Décompressez l’archive NSCA dans le dossier /usr/local/src

cd /usr/local/src
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nsca-2.9.2.tar.gz
tar xzf nsca-2.9.2.tar.gz
cd nsca-2.9.2

Préparez la compilation

./configure --with-nsca-user=centreon-engine --with-nsca-grp=centreon-engine

La préparation de la compilation doit retourner ce résultat.

*** Configuration summary for nsca 2.9.1 01-27-2012 ***:

 General Options:
 -------------------------
 NSCA port:  5667
 NSCA user:  centreon-engine
 NSCA group: centreon-engine


Review the options above for accuracy.  If they look okay,
type 'make all' to compile the NSCA daemon and client.

Le port NSCA sera le port par défaut 5667 et nous utiliserons le même groupe et le même utilisateur que le moteur de supervision centengine. Compilez NSCA.

make all

Copions les fichiers dans le dossier du moteur centengine. Adaptez en fonction de votre configuration.

cp src/nsca /usr/share/centreon/bin
chown centreon:centreon /usr/share/centreon/bin/nsca
chmod +x /usr/share/centreon/bin/nsca
cp sample-config/nsca.cfg /etc/centreon
chown centreon:centreon /etc/centreon/nsca.cfg

1.2.c Configuration

Modifiez le fichier de configuration de NSCA pour adapter le chemin des commandes externes du moteur de supervision.

vi /etc/centreon/nsca.cfg

Modifiez la ligne suivante.

command_file=/var/lib/centreon-engine/rw/centengine.cmd

Vous avez le choix de lancer le démon avec xinetd ou systemd.

1.2.d Configuration xinetd

Créez un fichier nsca dans le dossier /etc/xinetd.d

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

Seulement pour CentOS ajoutez la ligne suivante dans le fichier /etc/services

CENTREON

nsca	5667/tcp	#Nagios Service Check Acceptor

Appliquez la nouvelle configuration

Debian

systemctl reload xinetd

CENTREON

systemctl start xinetd

1.2.e Configuration systemd

Créez le fichier nsca.service dans le dossier /lib/systemd/system.

vi /lib/systemd/system/nsca.service

Ajoutez les lignes suivantes :

[Unit]
Description=Enable service provided nsca :  Nagios Service Check Acceptor
After=syslog.target network.target auditd.service
ConditionPathExists=/usr/share/centreon/bin/nsca
 
[Service]
ExecStart=/usr/share/centreon/bin/nsca -c /etc/centreon/nsca.cfg --daemon
ExecReload=/bin/kill -HUP $MAINPID
Type=forking
TimeoutSec=0
 
[Install]
WantedBy=multi-user.target

Appliquez la nouvelle configuration

systemctl daemon-reload
systemctl start nsca

1.3 vérification

On vérifie que notre serveur de configuration écoute bien avec le protocole NSCA

netstat -at | grep nsca
tcp        0      0 *:nsca                  *:*                     LISTEN

Protocole nsca
Le protocole nsca est un protocole TCP et son numéro de port par défaut est le 5667. Normalement, la distribution Debian Whezzy reconnait ce protocole. Si cela n’était pas le cas, éditez le fichier /etc/services et rajoutez la ligne suivante.

nsca            5667/tcp                        # Nagios Agent - NSCA

2 Installation du client NSCA sur les hôtes à superviser

2.1 Linux

2.1.a Installation du client

Il y a plusieurs solutions pour installer le client de votre hôte Linux. La plus facile, vous avez la même distribution que votre serveur de supervision. le client est déjà compilé et prêt à l’emploi. Il suffit de copier le binaire à l’emplacement que vous voulez sur l’Hôte. Dans notre exemple, nous utiliserons le serveur weblamp de la maquette duchmol et le dossier d’installation sera /usr/local/nsca. Il faut copier l’exécutable et le fichier de configuration.

scp /usr/local/src/nsca-2.9.2/src/send_nsca root@10.0.0.51:/usr/local/nsca
root@10.0.0.51's password:
send_nsca                                                                                             100%   72KB  72.3KB/s   00:00

scp /usr/local/src/nsca-2.9.2/sample-config/send_nsca.cfg root@10.0.0.51:/usr/local/nsca
root@10.0.0.51's password:
send_nsca.cfg                                                                                         100% 1628     1.6KB/s   00:00

La deuxième méthode sera de compiler directement sur la machine hôte en reprenant les points précédents et copier les deux fichiers send_nsca et send_nsca.cfg

2.1.b Test du client

Maintenant, vérifions le fonctionnement de NSCA. Lancez cette commande dans le dossier du client nsca.

echo -e "supervision\ttest_nsca\t2\ttest\n" | ./send_nsca -H 10.0.0.49 -c send_nsca.cfg

La commande doit vous retourner le résultat suivant.

1 data packet(s) sent to host successfully

Etudions la ligne de commande. On envoie une chaine de caractères dans la commande send_nsca par l’intermédiaire d’un pipe. Cette commande utilise un fichier de configuration pour connaître le mode de cryptage pour envoyer l’information. La chaine de caractère est une suite de paramètres séparée par une fabulation et se terminant par un retour chariot. Particularité : si vous voulez envoyer des données de performances, elles devront être séparées par un pipe. Voici une explication des paramètres.

name host <tab> name service <tab> state service <tab> description [| donnée de performance]<cr>

C’est bien beau tout ça, mais comment je vérifie que ma commande est bien arrivée et traitée sur le serveur de supervision ? Pas de souci, éditez le fichier de configuration nsca.cfg et modifiez la ligne suivante.

debug=1

Pour Debian, surveillez vos logs avec tail -f /var/log/syslog et relancez la ligne de commande sur l’hôte. Vous deviez voir ces lignes.

Feb 26 18:32:33 centreon254 nsca[4691]: Handling the connection...
Feb 26 18:32:34 centreon254 nsca[4691]: Time difference in packet: 0 seconds for host supervision
Feb 26 18:32:34 centreon254 nsca[4691]: SERVICE CHECK -> Host Name: 'supervision', Service Description: 'test_nsca', Return Code: '2', Output: 'test'
Feb 26 18:32:34 centreon254 nsca[4691]: Attempting to write to nagios command pipe
Feb 26 18:32:34 centreon254 nsca[4691]: End of connection...

Pour Centos, surveillez vos logs avec tail -f /var/log/messages et relancez la ligne de commande sur l’hôte. Vous deviez voir ces lignes.

Jun 29 10:08:49 centreon1904 xinetd[2941]: START: nsca pid=10270 from=::ffff:192.168.1.48
Jun 29 10:08:49 centreon1904 nsca[10270]: Handling the connection...
Jun 29 10:08:50 centreon1904 nsca[10270]: Time difference in packet: 0 seconds for host supervision
Jun 29 10:08:50 centreon1904 nsca[10270]: SERVICE CHECK -> Host Name: 'supervision', Service Description: 'test_nsca', Return Code: '2', Output: 'test'
Jun 29 10:08:50 centreon1904 nsca[10270]: Attempting to write to nagios command pipe
Jun 29 10:08:50 centreon1904 nsca[10270]: End of connection...
Jun 29 10:08:50 centreon1904 xinetd[2941]: EXIT: nsca status=0 pid=10270 duration=1(sec)

Sinon encore plus simple, surveillez votre fichier de log du moteur de supervision et vérifiez l'affichage d'une commande externe.

tail -f /var/log/centreon-engine/centengine.log

résultat

[1561789907] [5759] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;supervision;test_nsca;2;test
[1561789907] [5759] Warning:  Passive check result was received for service 'test_nsca' on host 'supervision', but the host could not be found!

Le deuxième message indique que l'ordonnanceur (moteur de supervision) n'a pas trouvé l'hôte correspondant à la commande nsca.

2.2 Windows avec le client NSCA

Il existe plusieurs outils pour réaliser un client NSCA. Si vous voulez utiliser un client NSCA pour envoyer une information au serveur de supervision à la suite d’un événement non planifié, je vous conseille d’utiliser NSCA Win32 Client. Il n’est pas très récent et fonctionne en 32 bits, néanmoins il fait bien ce qu’on lui demande. Si vous êtes courageux, vous avez à disposition les sources pour l’améliorer. Par contre, si vous utilisez le client NSCA pour des vérifications récurrentes et/ou planifiées, préférez l’agent NSClient ++ dans son mode de fonctionnement en NSCA.
Nous utiliserons NSCA Win32 Client dans cet article, NSClient ++ fait l’objet d’une série d’article à part.

2.2.a Installation

Récupérez le binaire sur le site exchange.nagios.org à cette adresse http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=550&cf_id=24.

Dézippez les fichiers dans le dossier de votre choix (dans notre exemple c:\scripts)

2.2.b Test du client

Pour testez notre client, nous utiliserons un fichier de commande MS-DOS. Nous utiliserons deux paramètres obligatoires, le premier pour le niveau de criticité de l’alerte et le deuxième pour le commentaire. Et enfin, un paramètre optionnel pour les données de performances. Voici le script test_nsca.cmd :

@echo off
rem script test nsca
rem on envoie un test a la supervision Nagios-Centreon
rem Eric Coquard
rem 02/03/2015 
rem %1 criticité alerte 0-OK 1-Warning 2-critical
rem %2 description
rem %3 Données de performances

if  "%~3"==""  goto  noperf
@echo Serv_Win;test_nsca;%1;%~2 ^^^| %~3 | "c:\scripts\send_nsca" -H 172.16.209.50 -d ; -c "c:\scripts\send_nsca.cfg"
goto exit

:noperf
@echo Serv_Win;test_nsca;%1;%~2 | "c:\scripts\send_nsca" -H 172.16.209.50 -d ; -c "c:\scripts\send_nsca.cfg"

:exit

Les informations en « dur » seront le chemin de send_nsca (c:\scripts), le nom d’hôte (Serv_Win), le nom du service (test_nsca), l’IP du serveur de supervision (172.16.209.50). Envoyons une commande, vous devriez avoir ce résultat. le tilde inséré au deuxième paramètre permet de récupérer une chaine de caractères protégée par des double-quotes en les enlevant automatiquement dans le paramètre. les trois circonflexes avant le pipe est une astuce pour protéger celui-ci quand il est passé en paramètre.

C:\scripts>test.cmd 0 essai
1 data packet(s) sent to host successfully.

Le fonctionnement est pratiquement identique à l’agent Linux, seul la façon d’appeler l’agent diffère.

2.3 Windows avec le client NSCLIENT++

Nous allons étudier le fonctionnement avec l'agent NSCLIENT++. Nous utiliserons la version 0.5x. Modifions le fichier de configuration nsclient.ini. Tout d'abord, il faut charger les modules adéquats dans la section modules.

[/modules]
NSCAClient = enabled
Scheduler = enabled

Nous définirons le nom de l'hôte qui sera utilisé par Centreon. Dans notre exemple, le nom du serveur Windows sera préfixé par la chaîne win_

[/settings/NSCA/client]
hostname = win_${host}

Il faudra définir la cible du serveur Centreon. On peut aussi définir le mode de chiffrage ainsi qu'un éventuel mot de passe. Le fichier du démon NSCA sur le serveur devra être en corrélation.

[/settings/NSCA/client/targets/default]
address = 10.0.3.70
encryption = aes
password = centreon

Pour déclencher automatiquement un script pour NSCA, on active un scheduler. Il faut aussi le configurer, par défaut, on appliquera 5 minutes.

[/settings/scheduler/schedules/default]
interval = 5m

Nous ajouterons le ou les services qui devront être activé par le scheduleur. Les modules CheckSystem et CheckExternalScripts devront être activé.

[/settings/scheduler/schedules]
test_nsca = alias_cpu

Redémarrez le service NSCLIENT et vérifions le résultat dans le fichier de log de centreon-engine. La deuxième ligne est normale car le service n'existe pas dans Centreon.

[1564059784] [4834] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;win_WIN2008R2;test_nsca;0;OK: CPU load is ok.|'total 5m'=1%;80;90 'total 1m'=0%;80;90 'total 5s'=1%;80;90
[1564059784] [4834] Warning:  Passive check result was received for service 'test_nsca' on host 'win_WIN2008R2', but the service could not be found!

Si vous ne voyez rien dans ce fichier, vérifiez le fichier de log système (var/log/syslog pour Debian ou /var/log/message pour CentOS) s'il n'y a pas un problème de chiffrage comme cet exemple :

Jul 25 14:52:49 srv-ang-inf070 nsca[1520]: Received invalid packet type/version from client - possibly due to client using wrong password or crypto algorithm?

2.4 Un peu de sécurité

NSCA utilise deux niveaux de sécurité pour ses transactions :

premier niveau de sécurité : l’utilisation d’une chaine secrète, cette fonctionnalité n’est pas activée par défaut. La chaine doit être identique côté client et côté serveur.
deuxième niveau de sécurité : l’utilisation d’un système de cryptage, cette fonctionnalité est activée avec la méthode XOR par défaut. Elle n’est pas très sécurisée mais sa méthode de cryptage est très rapide et utilise très peu de temps processeur.

les modifications se font dans les fichiers cfg client et serveur.

# DECRYPTION PASSWORD
# This is the password/passphrase that should be used to descrypt the
# incoming packets.  Note that all clients must encrypt the packets
# they send using the same password!
# IMPORTANT: You don't want all the users on this system to be able
# to read the password you specify here, so make sure to set
# restrictive permissions on this config file!

#password=

# DECRYPTION METHOD
# This option determines the method by which the nsca daemon will
# decrypt the packets it receives from the clients.  The decryption
# method you choose will be a balance between security and performance,
# as strong encryption methods consume more processor resources.
# You should evaluate your security needs when choosing a decryption
# method.
#
# Note: The decryption method you specify here must match the
#       encryption method the nsca clients use (as specified in
#       the send_nsca.cfg file)!!
# Values:
#
#       0 = None        (Do NOT use this option)
#       1 = Simple XOR  (No security, just obfuscation, but very fast)
#
#       2 = DES
#       3 = 3DES (Triple DES)
#       4 = CAST-128
#       5 = CAST-256
#       6 = xTEA
#       7 = 3WAY
#       8 = BLOWFISH
#       9 = TWOFISH
#       10 = LOKI97
#       11 = RC2
#       12 = ARCFOUR
#
#       14 = RIJNDAEL-128
#       15 = RIJNDAEL-192
#       16 = RIJNDAEL-256
#
#       19 = WAKE
#       20 = SERPENT
#
#       22 = ENIGMA (Unix crypt)
#       23 = GOST
#       24 = SAFER64
#       25 = SAFER128
#       26 = SAFER+
#

decryption_method=1

3 Configuration de Centreon

Il reste à réaliser la configuration de notre service dans Centreon. Nous aurons besoin d’un service passif et nous utiliserons une version 19.04 avec les plugins pack free.

3.1 Modèle de service passif

Nous utiliserons le modèle déjà créé par les plugins-pack, le modèle generic-passive-service-custom. Les paramètres de ce modèle hérite du modèle en lecture seule generic-passive-service.

3.1a Création d'un modèle de service passif

Pour info, si vous n'avez pas les plugins pack, les commandes clapi pour créer un modèle de service passif

Centreon-Clapi

centreon -u admin -p password -o STPL -a add -v "service-generique-passif;service-generique-passif;"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;check_period;24x7"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;check_command;check_centreon_dummy"
centreon -u admin -p password -o STPL -a setparam -v 'service-generique-passif;check_command_arguments;!0!OK'
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;max_check_attempts;1"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;normal_check_interval;1"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;retry_check_interval;1"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;active_checks_enabled;0"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;passive_checks_enabled;1"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;notifications_enabled;1"
centreon -u admin -p password -o STPL -a addcontactgroup -v "service-generique-passif;Supervisors"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;notification_interval;0"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;notification_period;24x7"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;notification_options;w,c,r,f,s"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;first_notification_delay;0"
centreon -u admin -p password -o STPL -a setparam -v "service-generique-passif;service_check_freshness;1"

3.1 le service test_nsca

3.1.a configuration

Nous pourrions créer un template de service NSCA mais pour notre exemple, il sera plus simple de créer directement un service. Nous appellerons ce service test_nsca et il sera associé à l’hôte weblamp.

création du service test_nsca

3.1.b application de la configuration

Une fois la configuration appliquée sur votre serveur, vous pouvez visualiser le service dans la page Monitoring Services.

Le service est mode pending et restera dans ce mode tant qu’une opération d’acquittement ou d’envoi de commande NSCA ne soient pas réalisés.

Acquittez le service.

Votre service est opérationnel.

4 Vérifications et essais avec le client nsca

Testons notre installation. Connectez vous sur le serveur servdebian et testez en envoyant les lignes de commandes suivantes.

4.1 état warning

root@servdebian:/usr/local/nsca# echo -e "servdebian\ttest_nsca\t1\ttest warning\n" | ./send_nsca -H 192.168.1.42 -c send_nsca.cfg
1 data packet(s) sent to host successfully.

Vous trouverez dans les logs du moteur

[1561792220] [7323] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;servdebian;test_nsca;1;test warning
[1561792223] [7323] PASSIVE SERVICE CHECK: servdebian;test_nsca;1;test warning
[1561792223] [7323] SERVICE ALERT: servdebian;test_nsca;WARNING;HARD;1;test warning

4.2 état critique

root@servdebian:/usr/local/nsca# echo -e "servdebian\ttest_nsca\t2\ttest critique\n" | ./send_nsca -H 192.168.1.42 -c send_nsca.cfg
1 data packet(s) sent to host successfully.

Vous trouverez dans les logs du moteur

[1561792442] [7323] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;servdebian;test_nsca;2;test critique
[1561792443] [7323] PASSIVE SERVICE CHECK: servdebian;test_nsca;2;test critique
[1561792443] [7323] SERVICE ALERT: servdebian;test_nsca;CRITICAL;HARD;1;test critique

4.3 état OK

root@servdebian:/usr/local/nsca# echo -e "servdebian\ttest_nsca\t0\ttest OK\n" | ./send_nsca -H 192.168.1.42 -c send_nsca.cfg
1 data packet(s) sent to host successfully.

Vous trouverez dans les logs du moteur

[1561793120] [7323] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;servdebian;test_nsca;0;test OK
[1561793123] [7323] PASSIVE SERVICE CHECK: servdebian;test_nsca;0;test OK
[1561793123] [7323] SERVICE ALERT: servdebian;test_nsca;OK;HARD;1;test OK

4.4 données de performances et graphes

echo -e "servdebian\ttest_nsca\t2\ttest critique et performances|nbcritical=1\n" | ./send_nsca -H 192.168.1.42 -c send_nsca.cfg
1 data packet(s) sent to host successfully.

Vous trouverez dans les logs du moteur

[1561794549] [7323] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;servdebian;test_nsca;2;test critique et performances|nbcritical=1
[1561794553] [7323] PASSIVE SERVICE CHECK: servdebian;test_nsca;2;test critique et performances
[1561794553] [7323] SERVICE ALERT: servdebian;test_nsca;CRITICAL;HARD;1;test critique et performances

On constate la création de la métrique nbcritical dans le détail du service

Il est possible d'avoir un graphe.

4.5 commandes sous Windows

Pour informations, voici les mêmes commandes sous Windows.

Warning

C:\scripts>test.cmd 1 "etat warning"
1 data packet(s) sent to host successfully.

Critical

C:\scripts>test.cmd 2 "etat critique"
1 data packet(s) sent to host successfully.

C:\scripts>test.cmd 0 "etat OK"
1 data packet(s) sent to host successfully.

Données de performances

C:\scripts>test.cmd 2 "etat critique et performances" "nbcritical=1"
1 data packet(s) sent to host successfully.

Voici un exemple de processus CFT dont les alarmes étaient reportées dans le serveur de supervision avec le protocole NSCA, celui-ci a fonctionné pendant quatre ans sans souci avec un gain de temps appréciable aux administrateurs systèmes pour la recherches de dysfonctionnements.

Gestion des fichiers CFT sur un serveur Windows

Le résultat d’une erreur CFT dans Centreon

5 Vérifications et essais avec le client NSCLIENT++

Nous utiliserons la même configuration qu'au paragraphe 3.1.a. Par contre, nous ajouterons les modifications suivantes. Pour contrôler le fonctionnement du service passif, vous utiliserons le rafraîchissement des données. Si aucune donnée n'arrive dans un laps de temps défini, on appliquera la commande du service associé avec l'état critique.

création du service test_nsca

Onglet Data Processing

On applique la configuration et on obtient ce service passif.

Lorsque l'agent NSCLIENT envoie les données, le serveur Centreon récupère les informations.

Ce sont les informations CPU et nous récupérons les informations de performances.

Si l'agent NSCLIENT n'envoie plus de données, le service sera en état Critical tant que le celui-ci n'envoie pas d'autres données.

L’article est terminé, il ne vous reste plus qu’à mettre en place votre commande NSCA. Elle peut être insérée dans un script pour déclencher une alerte ou dans une option d’une application tierce si celle-ci est capable de l’exécuter. Il est temps de mettre votre imagination en marche :-)

Retour en haut

Vous êtes ici:

Le service NSCA

Menu

1 Installation de NSCA sur le serveur de supervision

1.1 Moteur Nagios

1.1.a Compilation

1.1.b Configuration inetd

1.1.c Configuration xinetd

1.2 Moteur Centreon

1.2.a Installation avec xinetd

1.2.b Installation et compilation de NSCA

1.2.c Configuration

1.2.d Configuration xinetd

1.2.e Configuration systemd

1.3 vérification

2 Installation du client NSCA sur les hôtes à superviser

2.1 Linux

2.1.a Installation du client

2.1.b Test du client

2.2 Windows avec le client NSCA

2.2.a Installation

2.2.b Test du client

2.3 Windows avec le client NSCLIENT++

2.4 Un peu de sécurité

3 Configuration de Centreon

3.1 Modèle de service passif

3.1a Création d'un modèle de service passif

3.1 le service test_nsca

3.1.a configuration

3.1.b application de la configuration

4 Vérifications et essais avec le client nsca

4.1 état warning

4.2 état critique

4.3 état OK

4.4 données de performances et graphes

4.5 commandes sous Windows

5 Vérifications et essais avec le client NSCLIENT++