Vous êtes ici:

Menu

Stacks Image 9724
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 équivalent.
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.

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.1) se trouvant sur le site de Nagios.

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
Décompressez l’archive NSCA dans le dossier /usr/local/src
cd /usr/local/src
tar xzf nsca-2.9.1.tar.gz
cd nsca-2.9.1
Préparez la compilation
./configure
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:  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/xinet.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

1.2.a Compilation

Vérifiez l’installation du service inetd ou xinetd. Privilégiez l’installation de xinetd.
apt-get install xinetd
Décompressez l’archive NSCA dans le dossier /usr/local/src
cd /usr/local/src
tar xzf nsca-2.9.1.tar.gz
cd nsca-2.9.1
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/local/centreon-engine/bin
chown centreon-engine:centreon-engine /usr/local/centreon-engine/bin/nsca
chmod +x /usr/local/centreon-engine/bin/nsca
cp sample-config/nsca.cfg /usr/local/centreon-engine/etc
chown centreon-engine:centreon-engine /usr/local/centreon-engine/etc/nsca.cfg

1.2.b Configuration

Modifiez le fichier de configuration de NSCA pour adapter le chemin des commandes externes du moteur de supervision.
vi /usr/local/centreon-engine/etc/nsca.cfg
Modifiez la ligne suivante.
command_file=/var/lib/centreon-engine/rw/centengine.cmd

1.2.c Configuration xinetd

Créez un fichier nsca dans le dossier /etc/xinet.d
# default: on
# description: NSCA 
service nsca
	{
		Flags           = REUSE
		socket_type     = stream
		wait            = no
		user            = centreon-engine
		group           = centreon-engine
		server          = /usr/local/centreon-engine/bin/nsca
		server_args     = -c /usr/local/centreon-engine/etc/nsca.cfg --inetd
		log_on_failure += USERID
		disable         = no
	}
Appliquez la nouvelle configuration
service xinetd reload

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
Stacks Image 36643
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.1/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.1/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 compilé 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
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...

2.2 Windows

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.
Stacks Image 35621
Dézippez les fichiers dans le dossier de votre choix (dans notre exemple c:\scripts)
Stacks Image 35642

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 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 le modèle de la maquette duchmol.

3.1 Modèle de service passif

Créons le modèle de service passif
Stacks Image 19641
Les bulles indiquent les commandes clapi
Centreon-Clapi

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

3.1 le service NSCA

3.1.a configuration

Nous pourrions créer un template de service NSCA mais il sera plus simple de créer directement un service. Nous appellerons ce service test_nsca et il sera associé à l’hôte weblamp.
Stacks Image 19700
Associez le service au template Model-service-passif
Stacks Image 19734
Associez le service à l’hôte weblamp
Stacks Image 19717
On empêche la remise à OK toutes les 5 minutes (option par défaut pour les traps SNMP)

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.
Stacks Image 10457
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.
Stacks Image 19773
Acquittez le service.
Stacks Image 19786
Votre service est opérationnel.

4 Vérifications et essais

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

4.1 état warning

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

4.2 état critique

root@weblamp:/usr/local/nsca# echo -e "weblamp\ttest_nsca\t2\ttest critical\n" | ./send_nsca -H 10.0.0.49 -c send_nsca.cfg
1 data packet(s) sent to host successfully.
Stacks Image 19858

4.3 état OK

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

4.4 données de performances et graphes

root@weblamp:/usr/local/nsca# echo -e "weblamp\ttest_nsca\t2\ttest critical et performances|nbcritical=1\n" | ./send_nsca -H 10.0.0.49 -c send_nsca.cfg
1 data packet(s) sent to host successfully.
Stacks Image 19903
Stacks Image 19916

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.
OK
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.
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 :-)
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.
Stacks Image 35679
Gestion des fichiers CFT sur un serveur Windows
Stacks Image 35692
Le résultat d’une erreur CFT dans Centreon
comments powered by Disqus
 Vous êtes ici: