Page History

Contexte

Cette documentation a pour but de montrer comment un cluster peu peut superviser des hôtes et/ou des checks venant de royaumes différents. Exemple : Vous souhaitez superviser un site internet depuis 2 datacenter différents qui sont dans des royaumes différents et remonter l'information dans un cluster pour n'être alerté qu'en cas de défaillance des 2 datacenters.

Le concept est d'utiliser le module receiver-module-webservice pour envoyer des traps.

La solution proposée permettra de remonter n’importe quel résultat de checks ou d'hôtes le cluster.

• Il s'agit cependant d'un contournement et une utilisation généralisée sur tous les éléments supervisés sera fastidieuxfastidieuse.

Prenons par exemple la surveillance d'un site internet www.shinken-enterprise.com dans 2 royaumes différent et le résultat sera envoyé sur un hôte hôte_global dont les check checks seront appelé appelés via un cluster nommé cluster_global :

• Le dialogue se fera via le mécanisme du Gestionnaire d'événements qui, si paramétré sur l'hôte ou le check, enverra une commande définie sur le cluster ou le check du cluster.
• Ces commandes seront alors récupérées par le module receiver-module-webservice du daemon démon Receiver, et permettront le changement de l'état du cluster concerné.
• Il faudra définir sur le royaume principal, l'hôte avec les checks portant le même nom ainsi qu'un cluster pour que la remontée d'information ait bien lieu.

Architecture

Installation - Les étapes de mise en place

Pour cet exemple, basé sur le schéma ci-dessus, la supervision du site doit envoyer l'information à l'hôte sur le royaume principal, sur le même nom de check.

Mise en place de l'architecture Shinken sur le réseau isolé

• Installez Shinken Entreprise
• Mettez en place la supervision des éléments sur les différents royaumes
• Mettez en place la surveillance de l'hôte hote_global avec une commande de supervision, par exemple la commande check-host-alive
• Créez la commande qui enverra l'information au Receiver, depuis l'interface de configuration - page des commandes :

Dans notre exemple, pour un objet hôte, créons par exemple la commande ( dans l'interface de configuration ) ayant le nom "envoi-statut-hote" et avec la ligne de commande :

/var/lib/shinken-user/libexec/submit_host_result_to_receiver "$HOSTADDRESS$" $SERVICESTATEID$ "$SERVICEOUTPUT$" IP-RECEIVER-CENTRAL

Si on doit effectuer l'envoi du statut d'un check, voici l'exemple de la commande ayant le nom "envoi-statut-check" et avec la ligne de commande :

/var/lib/shinken-user/libexec/submit_check_result_to_receiver "$HOSTADDRESS$" "$SERVICEDISPLAYNAME$" $SERVICESTATEID$ "$SERVICEOUTPUT$" IP-RECEIVER-CENTRAL

Le contenu du script se trouve dans cette partie de la documentation : Script d'interprétation des traps avec le module receiver-module-webservice

• sur Sur hote_global: 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 Et sélectionnez la commande "envoi-statut-hote" pour la Commande lancée par le gestionnaire d’événement (ou via cfg, définie avec la propriété event_handler)

Paramétrage sur le réseau Central 

Configuration :

• Paramétrez votre Module receiver-module-webservice
• pensez 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 la propriété "Shinken accepte les états reçus depuis des outils externes pour cet hôte" à VRAI 
    
• ou via un fichier de définition CFG ( utilisation d'une source d'import ) :
  
  • active_checks_enabled 0
  • passive_checks_enabled 1

Pour

générer un retour CRITIQUE dans le cas

où l'hôte ne reçoit pas d'information externe, 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

reçues 
Pour un check, vous pouvez renvoyer un état UNKNOWN avec comme arguments : 3!Pas de données récentes

reçues

Pour que cette commande soit exécutée, dans l'onglet expert de H1, passez la propriété "Vérification que l'état

reçut 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 : check_freshness 1

et freshness_threshold 300 )

Et voilavoilà, à chaque changement d'états de l'hôte H1 du réseau isolé, la commande "envoi-statut-hote" sera lancée, et mettra à jour l'hôte de même nom sur le réseau central.

Troubleshoot

Commande manuelle

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

curl -u user:password -X POST -d "time_stamp=`date +%s`&host_name=mon_hote&service_description=mon_check&return_code=0&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é.

Réseau

Au minimum, pour faire communiquer les deux infrastructures, il faut autoriser une communication entre l'IP hébergeant le daemon démon Reactionner qui enverra les commandes d'Event Handler, et l'IP hébergeant le daemon démon Receiver (port 7760 du module receiver-module-webservice) à l'écoute des commandes.