Page History

Description

Le module Named Pipe, via le named-pipe permet à Shinken de récupérer des informations via un fichier "passe plat" FIFO (First In First Out) shinken.cmd, va permettre à Shinken de récupérer les entrées ou commandes externes( un pipe ) que l'on peut remplir de la manière de notre choix.

Par exemple, ce module peut envoyer des informations à des hôtes possédant des checks passifs (checks qui au lieu d'effectuer une vérification régulière, va attendre de recevoir des données, plus d'informations sur les checks passifs ici : Mode actif et mode passif ).

Pour un exemple d'utilisation du module, veuillez vous référer à la section exemple d'utilisation.

Activation du module

Le module named-pipe est un module qui peut être activé sur le démon Receiver et de l'Arbiter.

• L'activation du module s'effectue en ajoutant le nom de ce module dans le fichier de configuration du démon Receiver ( ou de l'Arbiter ).
• Pour ce faire, ouvrer le fichier de configuration du Receiver à l'emplacement /etc/shinken/receivers/, et ajouter le nom de votre module "named-pipe".

Exemple: par défaut, nous livrons un module dont le nom est "named-pipe":

define receiver {
    [...]
    modules                   Module 1, Module 2, named-pipe
    [...]
}

Pour prendre en compte le changement de configuration, redémarrer l'Arbiter:

service shinken-arbiter restart

Configuration

Vous trouverez une configuration par défaut ici : named-pipe.cfg 

Il faut ensuite placer ce fichier avec les autres modules /etc/shinken/modules/

Détails des sections composant le fichier de configuration

Identification du module

Il est possible de définir plusieurs instances de module de type named-pipe dans votre architecture Shinken.

• Chaque instance devra avoir un nom unique.

module_name 

module_type 

Configuration du fichier passe-plat

Exemple d'utilisation du module

• Il faut rajouter la définition du module. Si elle n'est pas présente:
• Dans le répertoire /etc/shinken/modules/
• Copier le fichier named-pipe.cfg et modifier les droits :
  
  

chown shinken:shinken named-pipe.cfg
chmod 644 named-pipe.cfg

• Ensuite on va accrocher le module au receiver
• Ouvrir le fichier /etc/shinken/receivers/receiver-master.cfg
• Ajouter named-pipe à la ligne modules
• modules             named-pipe
  
• Redémarrer Shinken via la commande service shinken restart

Création de l'élément de supervision en configuration

• Dans l’interface de configuration, il faut à présent créer le check à associer à un hôte, en passif, non actif, et volatile, car si nous souhaitons recevoir une notification dès un changement d'état. L'expiration de l'état de fraîcheur doit également être paramétrée.
  • Voici un exemple avec la syntaxe via fichiers cfg, modèle de check dédié au modèle d'hôte "TRAP-modele" :  

define service{
        service_description     TRAP
        check_command           check-host-alive
        host_name               TRAP-modele
		is_volatile             1
        passive_checks_enabled  1
		active_checks_enabled  	0
		check_freshness			1
		freshness_threshold		300
        register                0
        check_interval      	1
        retry_interval      	1
}
 
define host{
        name    				TRAP-modele
        register        		0
}

• Appliquer le modèle d'hôte à un hôte accessible sur le réseau (le paramètre "adresse" doit être rempli), par exemple un hôte "test-trap"
  
  
  

Script interpréteur des traps

• Maintenant il faut un script (plugin) qui va se charger d’interpréter les futures traps SNMP reçues pour les envoyer à Shinken (à travers le module named-pipe et le fichier shinken.cmd).
• Ajouter le script suivant que l’on appellera submit_check_result dans le dossier des plugins Shinken (/var/lib/shinken-user/libexec/):
   

#!/bin/bash

# Arguments:
# $1 = host_name (Short name of host that the service is associated with)
# $2 = svc_description (Description of the service)
# $3 = return_code (An integer that determines the state of the service check, 0=OK, 1=WARNING, 2=CRITICAL,3=UNKNOWN).
# $4 = plugin_output (A text string that should be used as the plugin output for the service check)

echocmd="/bin/echo"

CommandFile="/var/lib/shinken/shinken.cmd"

# get the current date/time in seconds since UNIX epoch
datetime=`date +%s`

# create the command line to add to the command file
cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4"

# append the command to the end of the command file
$echocmd "$cmdline" >> $CommandFile

• On le rend exécutable et on le donne à l’utilisateur Shinken :
  

chown shinken:shinken /var/lib/shinken-user/libexec/submit_check_result_to_receiver
chmod +x /var/lib/shinken-user/libexec/submit_check_result_to_receiver

• Pour tester le script et simuler une réception d'un trap translaté au format Shinken, il suffit d’exécuter la commande suivante qui va faire passer le service en état critique :

/var/lib/shinken-user/libexec/submit_check_result test-trap TRAP 2 "test envoi trap - CRITIQUE"

• Le check devrait passer en critique, et si au bout de la période du seuil de fraîcheur, aucun nouveau trap n'a été reçu, alors la commande check-host-alive fera repasser le check à OK ( si bien sur l'hôte est accessible via le réseau ).