Page History

Contexte

Mécanismes

Le choix du mécanisme est important dans votre architecture.

Les Event Handlers sont paramétrables par check et par hôtes, via l'UI de configuration, alors que les commandes OCSP et OCHP sont paramétrables de manière globale dans Shinken, via le fichier /etc/shinken/shinken.cfg

Si vous décidez d'envoyer absolument tous les résultats vers le Shinken central, de la même manière, via une même commande, alors les commandes OCSP et OCHP seront plus rapidement mises en place, et vous n'aurez pas à vous soucier d'un paramétrage par hôtes ou checks.

Par contre, si vous souhaitez n'envoyer que certains résultats vers le central, il sera plus judicieux de passer par les Event Handlers.

Les Event Handlers

Les Event Handlers sont expliqués dans la documentation ici.

OCSP (checks) /OCHP (hôtes)

Les options sont à définir dans /etc/shinken/shinken.cfg :

obsess_over_services=1

obsess_over_hosts=1

Ces valeurs déterminent si Shinken va, à chaque exécution de la commande de supervision de l'hôte ou du service, exécuter une autre commande.

Cette commande est également à définir de manière globale dans le fichier shinken.cfg.

Pour la commande "obsession" des checks : ocsp_command=ma-commande-OCSP-checks

Pour la commande "obsession" des hôtes : ochp_command=ma-commande-OCHP-hotes

Cette commande est exécutée après les commandes "Event Handler" et les commandes de notification. La valeur des propriétés est le nom court d'une commande qui est définie dans vos objets Shinken. Pour information, cette commande est exécutée par le Reactionner, après les commandes "Event Handler" et les commandes de notification. 

Architecture

Installation - Les étapes de mise en place

Pour cet exemple, basé sur le schéma ci dessus, le check C1 sur la supervision de l'hôte H1 du réseau isolé doit envoyer l'information en central, sur un le même nom de check de ld'hôte du même nom H1 (mirroirmiroir).

Mise en place de l'

architecture Shinken sur le réseau isolé

• Installation Shinken complète (tous les démons)
• Mise en supervision de l'hôte H1 avec une commande de supervision, par exemple la commande check-host-alive

• Création de la commande qui enverra l'information au Receiver du réseau Shinken central, depuis la page des commandes :

Dans notre exemple, pour un objet hôte, créons par exemple la commande "envoi-statut-hote" :

curl -d "host_name=$HOSTNAME$&return_code=$SERVICESTATEID$" --data-urlencode "output=Statut de l hote recupere" http://IP-RECEIVER-CENTRAL:7760/push_check_result

Si on doit effectuer l'envoi du statut d'un check, créons par exemple la commande "envoi-statut-check" :

curl -d "host_name=$HOSTNAME$&service_description=$SERVICEDESC$&return_code=$SERVICESTATEID$" --data-urlencode "output=Statut du check recupere" http://IP-RECEIVER-CENTRAL:7760/push_check_result

Ensuite, comme vu précédemment, deux choix de mécanismes s'offrent à vous ici :

Event Handler :

• sur H1: depuis l'interface de configuration, dans l'onglet Expert, activez le Gestionnaire d'événement (ou via un cfg passez la propriété event_handler_enabled à 1) et sélectionnez la commande "envoi-statut-hote" check attaché appelé C1sur C1 : event_handler_enabled 1 et commande définie via la propriété event_handler
  
  

OCSP/OCHP :

• dans le fichier /etc/shinken/shinken.cfg , ajoutez : obsess_over_hosts=1 et ochp_command=envoi-statut-hote
• si besoin, pour l'envoi des statuts de checks : ajoutez : obsess_over_services=1 et ocsp_command=envoi-statut-check
• Redémarrez Shinken pour la prise en compte de ces nouveaux paramètres.
  
  

Paramétrage sur le réseau Central 

• Paramétrez votre module ws-arbiter et pensez bien à l'appeler depuis la définition de votre Receiver dans la propriété module. Redémarrez Shinken pour la prise en compte du module.
• Créez l'hôte H1 (attention, le nom doit être exactement le même que celui défini dans l'architecture Shinken du réseau isolé)
• Passez H1 en mode Passif : depuis l'interface de configuration, onglet Supervision, via la propriété "Les commandes de vérifications sont ordonnancées et lancées par Shinken" à mettre à FAUX et "Shinken accepte les états reçus depuis des outils externes pour cet hôte" à VRAI  (ou via CFG : active
• création de H1 et C1 (attention, les noms doivent être identiques)
• sur C1  : Mode Passif : active_checks_enabled 0 et passive_checks_enabled 1)
• Nous vous conseillons de définir la commande de supervision de H1 par la commande "Check Dummy" avec par exemple en argument : 2!Pas de données récentes recues     ce C1 doit appeler une commande qui génère un retour unknown "retour inconnu" (CRITIQUE dans le cas ou il l'hôte ne recoit reçoit pas d'information externe). Pour un check, vous pouvez renvoyer un état UNKNOWN avec : 3!Pas de données récentes recues par exemple.
• Pour que cette commande soit exécutée, dans l'onglet expert de H1, passez la propriété "Vérification que l'état reçu des outils externes ne soit pas expiré" à VRAI et passez la propriété "Seuil d'expiration des états reçus des outils externes ( x secondes )" à 300 (ou via CFG : checkFraicheur : check_freshness 1 et freshness_threshold 300 )-> si au bout de 300s je n'ai pas recu d'information via les outils externes -> retour statut "retour inconnu"

Troubleshoot

Pour tester le bon fonctionnement du module ws-arbiter, vous pouvez exécuter simplement cette commande depuis un terminal :

curl -d "host_name=mon_hote&return_code=0" --data-urlencode "output=Statut OK" http://IP-DU-RECEIVER:7760/push_check_result  

Vérifiez alors que l'état de votre hôte depuis l'interface de visualisation de votre réseau Shinken Central a bien été modifié.