Introduction

Une utilisation fréquemment rencontrée lors de la mise en place d'une architecture Shinken distribuée contenant plusieurs royaumes est la gestion de plusieurs services/clients.

Supposons qu'on se trouve dans le scénario suivant:

  • La plateforme de supervision est mise en place par une équipe dédiée à la supervision
  • L'équipe de supervision dispose d'une interface de Visualisation permettant de visualiser l'ensemble des hôtes présents dans la configuration
  • Les hôtes supervisés correspondent à des machines/service dédiées à certains clients
  • L'équipe de supervision veut pouvoir mettre à disposition une interface de Visualisation à chaque client qui lui permet de visualiser ses hôtes (mais pas ceux des autres clients)


Une solution dans ce cas de figure est de créer un royaume dans lequel est positionné un Broker.

Architecture mise en place

Dans cette page de documentation, on a pour objectif de mettre en place l'architecture suivante:

  • L'architecture comporte d'abord un royaume principal (All) qui supervise un certain nombre d'éléments
  • Un sous royaume "Client 1" s'occupe de superviser les éléments concernant le client 1.
  • L'interface de Visualisation sur le royaume permet de visualiser l'ensemble des hôtes, y compris ceux du royaume "Client 1".
  • L'interface de Visualisation du royaume "Client 1" sera mise à disposition au client et ne permet de visualiser que les éléments supervisés par le royaume "Client 1"



Configuration des démons

La première étape pour la mise en place de cette architecture est la mise en place des démons.

On suppose dans notre exemple que les démons du royaume All sont hébergés sur une machine "server_1" et les démons du royaume "Client 1" sont hébergés sur une machine "server_2".

La configuration se fera alors en majeure partie sur "server_1", puisque c'est la on est situé le démon Arbiter qui gère la configuration des démons.

Création des royaumes

Sur "server_1", on commence alors par créer le royaume "Client 1". Pour cela, on crée le fichier /etc/shinken/realms/client1.cfg qui aura le contenu suivant:

define realm {
    # Realm name. Must be unique
    realm_name          Client 1

    # default:  0 = this realm is not the default one
    #           1 = this realm is the default, so an element or a daemon is missing a
    #               realm property, then this one will be used
    default             0

    # List of sub-realms for this realm
    #realm_members
}

Le royaume "Client 1" est un sous-royaume du royaume All. Il faut pour qu'il soit considéré comme un sous royaume modifier la configuration du royaume All pour le spécifier, comme dans l'exemple suivant :

define realm {
    # Realm name. Must be unique
    realm_name          All

    # default:  0 = this realm is not the default one
    #           1 = this realm is the default, so an element or a daemon is missing a
    #               realm property, then this one will be used
    default             1

    # List of sub-realms for this realm
    realm_members Client 1
}


Création des démons du royaume "Client 1"

Une fois le royaume "Client 1" créé, il faut ensuite créer les démons qui font partie de ce royaume.

Cette création des démons se fait en 3 temps.

  • On commence d'abord par créer les fichiers .ini des démons sur "server_2"

    shinken-daemons-create --ini --type=scheduler --port=7768 --name=scheduler-client-1
shinken-daemons-create --ini --type=poller --port=7771 --name=poller-client-1
shinken-daemons-create --ini --type=broker --port=7772--name=broker-client-1


  • On créé ensuite les fichiers de configuration sur l'Arbiter ("server_1")

    shinken-daemons-create --cfg --type=scheduler --port=7768 --name=scheduler-client-1 --address=<adresse_server_2>
shinken-daemons-create --cfg --type=poller--port=7771 --name=poller-client-1 --address=<adresse_server_2>
shinken-daemons-create --cfg --type=broker--port=7772 --name=broker-client-1 --address=<adresse_server_2>


  • On modifie la propriété "realms" des fichiers de configuration de ces démons pour les mettre dans le royaume "Client 1" (/etc/shinken/schedulers/scheduler-client-1.cfg, /etc/shinken/brokers/broker-client-1.cfg, /etc/shinken/pollers/poller-client-1.cfg).
    Par exemple, pour le Scheduler:

    define scheduler {
    #======== Daemon name and address =========
    # Daemon name. Must be unique
    scheduler_name            scheduler-client-1

    # IP/fqdn of this daemon (note: you MUST change it by the real ip/fqdn of this server)
    address                   <adresse_server_2>


    ... Contenu coupé ...



    #======== Realm and architecture settings =========
    # Realm to set this daemon into
    realm                    Client 1

    # In NATted environments, you declare each satellite ip[:port] as seen by
    # *this* scheduler (if port not set, the port declared by satellite itself
    # is used)
    #satellitemap            poller-1=1.2.3.4:1772, reactionner-1=1.2.3.5:1773



    #======== Enable or not this daemon =========
    # 1 = is enabled, 0 = is disabled
    enabled                  1

}


Gestion des métriques

Duplication du module Graphite-Perfdata et WebUI pour faire pointer chaque Broker vers le bon Graphite

Gestion des SLA

On laisse par défaut (localhost) ca marche. En plus on peut pas pour le moment configurer la sauvegarde de SLA par royaume donc ca règle le problème