Versions Compared

Old Version 2

changes.mady.by.user David Labardin

Saved on

compared with

New Version 3

changes.mady.by.user David Labardin

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 recevoir 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 Shinken sur ce réseau isolé (qui sera également accessible depuis l'intérieur de ce réseau par les administrateurs) et de le faire dialoguer avec le réseau Shinken Central. De cette manière, il sera possible de n'autoriser qu'un seul flux réseau (entre 2 IP spécifiques), dans le sens réseau isolé vers réseau central.

Prenons par exemple la surveillance de l'hôte H1 et de son check C1 dans l'infrastructure Shinken du réseau isolé.
L'objectif est d'obtenir sur l'architecture centrale Shinken la réplique de H1 et C1 (avec des objets qui ont exactement les mêmes noms), et que leurs états en central soient un mirroir des états réels déterminés depuis les Pollers/Scheduler du réseau isolé.

Le dialogue pourra se fera via le mécanisme des faire via deux mécanismes possibles :

  • les commandes Event Handlers (gestionnaire d'évènements) qui, si paramétrés 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.

 

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. Leurs paramétrages est possibles 

 

Info
Le paramétrage des Events Handler est possible via fichier CFG mais peut être également entièrement paramétré via l'UI de configuration.

OCSP (checks) /OCHP (hôtes)

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

exemple : obsess_over_services=1

obsess et obsess_over_hosts=1

Cette valeur détermine 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 en suivant.

 

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

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

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

Cette commande est exécutée après les commandes "Event Handler" et les commandes de notification. The command argument is the short name of a command definition that you define in your object configuration file.La valeur des propriétés est le nom court d'une commande qui est définie dans vos objets Shinken.

 

Architecture

Panel
titleArchitecture Shinken Central / Distant

Installation - Les étapes de mise en place

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


Récupération et extraction des données

Shinken Entreprise vous a transmis un fichier TAR.GZ contenant des dossiers et exécutables qui vous permettront de procéder à l'installation d'un Poller sur Windows.

Se connecter en administrateur sur le serveur, et extraire ce TAR.GZ sur le serveur Windows. (7Zip par exemple peut vous permettre d'effectuer cette extraction sur Windows)

 

Installations des dépendances

Afin de mettre en place le Poller il faut installer les

dépendances

suivantes (contenues à la racine du dossier):

  • python-2.7.6.amd64.msi [à installer en premier ]
  • pywin32-217.win-amd64-py2.7.exe
  • pycurl-7.19.3.1.win-amd64-py2.7.exe
  • egenix-pyopenssl-0.13.3.1.0.1.6.win-amd64-py2.7.msi
  • psutil-5.2.1.win-amd64-py2.7.exe

Note : laisser les chemins d'installations par défaut
 

Installation manuelle:

installation de CherryPy-3.2.4

:

  • Ouvrir une commande DOS en Administrateur
    • Se déplacer dans le répertoire CherryPy-3.2.4

     

  • Exécuter la commande c:\python27\python.exe setup.py install
  • Depuis l'explorateur Windows :
    • Copier le répertoire "shinken" vers C:\shinken
    • Copier tools\srvany.exe dans c:\shinken\srvany\ [remplacer le fichier]
    • Copier context.json dans c:\shinken\var [remplacer le fichier]
    • Ouvrir le fichier C:\shinken\var\context.json avec le bloc noteModifier la valeur current_version par la version de votre installation - par exemple : 02.04.00-137.fr

    Installation du service Automatique Windows 

     Ouvrir une commande DOS en Administrateur puis exécuter la commande :

    sc create "Shinken-Poller" binpath= "c:\shinken\srvany\srvany.exe" DisplayName= "Shinken-Poller"

  • (ATTENTION: les espaces après les = sont nécessaires)

    • Depuis l'explorateur Windows :

  • Importer le fichier poller.reg dans votre registre en double cliquant dessus
  • Depuis la console MMC des services Windows (depuis les Outils d'Administration ou via la commande services.msc), changer le service Shinken-Poller en "Automatique" depuis les propriétés du service et changer le compte qui va exécuter le service (via un compte administrateur local ou de domaine)
  • Démarrer alors le service en cliquant sur "démarrer" sur la ligne du service Shinken-Poller de la console MMC ou via la commande : net start Shinken-Poller
    • Vérifier qu'il est lancé avec :
  • 1/ le log C:\shinken\var\pollerd.log
  • 2/ le port 7771 qui doit être ouvert, vérifiable avec netstat -an
    • 3/ une fois le nouveau Poller déclaré en configuration, depuis votre installation centrale, exécuter la commande shinken-healthcheck : vos Pollers doivent être valides et accessibles.Note : une à deux minutes sont parfois nécessaires afin que la configuration soit diffusée

    Mise à jour

    Stopper le daemon poller:

    • net stop Shinken-Poller

    Afin de mettre à jour une ancienne installation, il est nécessaire de mettre à jour une nouvelle dépendance qui n'était pas installée à l'origine:

    • psutil-5.2.1.win-amd64-py2.7.exe

    De plus, il faut placer le fichier context à son emplacement:

    Copier context.json dans c:\shinken\var

     

    [remplacer le fichier]
  • Ouvrir avec le bloc note C:\shinken\var\context.json et modifier la valeur current_version par la version de votre installation - par exemple : 02.04.00-137.fr

    • Il faut supprimer l'ancien code de Shinken en supprimant le dossier suivant:

    c:\shinken\shinken
    ATTENTION: il ne faut PAS supprimer le répertoire c:\shinken en entier, mais seulement le répertoire "shinken" à l'intérieur.

    Il faut placer le nouveau code shinken:

    • windows - XXX\shinken\shinken à copier dans c:\shinken\shinken
    • Vérifier que le fichier c:\shinken\shinken\daemon.py est bien présent (pour vérifier que les répertoires sont au bon endroit).

    Relancer le daemon avec:

    • net start Shinken-Poller

    Troubleshooting

    Configuration SSL

    Pour paramétrer le daemon en SSL, il faut modifier le fichier c:\shinken\etc\daemons\pollerd-windows.ini et modifier le bloc suivant #-- HTTPS  configuration --

    Vous pourrez alors activer le

    SSL

    et paramétrer vos certificats.

     

    Démarrage manuel du Poller - pour test

     Si le service Windows ne démarre pas, pour débugger, vous pouvez lancer le démarrage du Poller, ouvrir une commande DOS en Administrateur et tester le démarrage en exécutant la commande:

    c:\Python27\python.exe c:\shinken\bin\shinken-poller.py -c c:\shinken\etc\daemons\pollerd-windows.ini

    Réseau

    Bien vérifier que la communication réseau entre votre architecture Shinken et ce nouveau Poller Windows est opérationnelle.
    En effet, un firewall pourrait bloquer des communications importantes, ce qui pourrait provoquer des problèmes entres les différents démons.
    Le port d'écoute 7771 doit être également ouvert sur le Poller Windows.
    Si besoin, suivant les définitions des démons de votre configuration, la résolution de nom doit également permettre au Poller Windows de communiquer avec les autres démons et inversement.

    Droits

     

    Réseau

     

    Droits

     Lors de vos installations, bien penser à être connecté en administrateur local de la machine, ou administrateur du domaine si le serveur est sur un domaine.