Versions Compared

Old Version 5

changes.mady.by.user David Labardin

Saved on

compared with

New Version Current

changes.mady.by.user Guillaume ROY

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contexte

 

Il peut arriver qu'un réseau sécurisé soit complètement isolé du réseau central et que vous ayez besoin de distribuer les alertes des équipements et services supervisés de ce réseau isolé, vers le réseau central. 

Nous vous conseillons alors de mettre en place une

architecture

installation Shinken Entreprise sur ce réseau isolé (

qui sera également accessible depuis l'intérieur de ce réseau

dont la politique de supervision est définie par les administrateurs de ce réseau) et de la faire dialoguer avec votre

architecture

installation Shinken

en Central. En suivant cette procédure, il sera possible de n'autoriser au minimum qu'un seul flux réseau (entre 2 IP spécifiques), dans le sens réseau isolé vers réseau

Entreprise Central.

Le concept est que l'installation déportée va pousser ses résultats vers l'installation centrale.

  • Le flux réseau ne sera donc ouvert que dans le sens Déporté vers Central.
  • Les installations dans des zones sécurisées n'auront donc pas de connexion entrante.

La solution proposée permettra de remonter n’importe quel résultat de checks ou d'hôtes vers l'installation centrale.

  • Il s'agit cependant d'un contournement et une utilisation généralisée sur tous les éléments supervisés sera fastidieux.
  • Nous vous conseillons de faire des clusters et de remonter seulement les informations des clusters pour avoir une vue agrégée en central.

Prenons par exemple la surveillance de l'hôte H1 dans l'infrastructure Shinken du réseau isolé

.

:

L'objectif est d'obtenir sur l'architecture centrale Shinken la réplique de H1 (avec un objet qui a exactement le même nom, et qui est en mode passif), et que son état en central soit un miroir des états réels déterminés depuis les Pollers/Scheduler du réseau isolé.

  • Le dialogue
pourra
  • se
faire via deux mécanismes possibles :
  • les commandes Event Handlers (gestionnaire d'évènements) fera via le mécanisme du Gestionnaire d'événements qui, si paramétrés paramétré sur l'hôte ou le check, enverra une commande définie sur cet hôte ou ce check.
  • les commandes OCSP/OCHP (Obsessive Compulsive Service Processor / Obsessive Compulsive Host Processor) qui permet de doubler toutes les commandes de checks ou d'hôtes, par une autre commande, globale, définie dans le fichier de configuration central.
  • Ces commandes seront alors récupérées par le module ws-arbiter du daemon Receiver en central, et permettront le changement de l'état de l'hôte ou du check concerné.
Panel
titleSommaire

Table of Contents

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.

  • Il faudra définir de chaque coté un élément avec le même nom (hôtes ou couple hôte/check) pour que la remontée d'information ait bien lieu.

 

 

 

 

Panel
titleSommaire

Table of Contents


InfoLe paramétrage des Events Handler peut être entièrement réalisé via l'UI de configuration (aussipossible via fichier CFG).

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

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


Panel
titleArchitecture Shinken Central / Distant

Image RemovedImage Added


Installation - Les étapes de mise en place

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

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

  • Installez Shinken Entrprise
  • Mettez en place la surveillance

 

  • 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 Créez la commande qui enverra l'information au Receiver du réseau Shinken central, depuis la 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 :

Code Block
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 voici l'exemple de la commande ayant le nom "envoi-statut-check" et avec la ligne de commande :

Code Block
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" 
 définie via 
  • pour la Commande lancée par le gestionnaire d’événement (ou via cfg, définie avec 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

    •  Panel
    Image Added
    Redémarrez Shinken pour la prise en compte de ces nouveaux paramètres.

    Paramétrage sur le réseau Central 
    • Configuration 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 la propriété "Shinken accepte les états reçus depuis des outils externes pour cet hôte" à 
     VRAI  (
        •  VRAI  
      • ou via un fichier de définition CFG ( utilisation d'une source d'import ) :
        •  active_checks_enabled 0
     et passive
        • passive_checks_enabled 1
    )

     Panel
    Image Added

    • Pour génèrer un retour CRITIQUE dans le cas ou l'hôte ne reçoit pas d'information externe, nous 
    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 qui génère un retour CRITIQUE dans le cas ou l'hôte ne reçoit pas d'information externe. 
    • recues 
      Pour un check, vous pouvez renvoyer un état UNKNOWN avec comme arguments : 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 : check_freshness 1 et freshness_threshold 300 )
     

     Panel
    Image Added

    Et voila, à 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 ws-arbiter, vous pouvez exécuter simplement cette commande depuis un terminal :
     Code Block
    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é. 
    Réseau
    Au minimum, pour faire communiquer les deux infrastructures, il faut autoriser une communication entre l'IP hébergeant le daemon Reactionner (port 7769) qui enverra les commandes d'Event Handler, et l'IP hébergeant le daemon Receiver (port 7773) à l'écoute des commandes.