...
Les délais sont volontairement très courts pour de petites installations ( Voir paramètres de configuration des Démons pour plus d'information ).
Illustration :
External commands dispatching
...
Distribution par Commande Externe
L'administrateur doit envoyer des ordres aux Schedulers (comme par exemple un nouveau statut pour un check passif).
Dans Shinken Enterprise, l'administrateur envoie uniquement l'ordre à l'Arbiter, c'est tout. Les commandes externes sont de 2 types :
- commandes qui concernent tous les Schedulers.
- commandes qui sont spécifiques à un seul élément (hôte/check).
Pour chaque commande, Shinken Enterprise détecte si c'est global ou particulier:
- si global, il envoie les ordres à tous les Schedulers.
- Si particulier, il détecte quel Scheduler gère l'élément concerné par la commande (hôte/check) et envoie l'ordre au bon Scheduler.
Dès réception de l'ordre par les Schedulers, il est appliqué.
Différents types de Pollers: poller_tag
L'architecture de Shinken Enterprise est très pratique quand on utilise le même type de Poller pour tous les checks. Mais il peut également être nécessaire d'avoir plusieurs types de Poller, comme par exemple un GNU/Linux et un Windows.Nous avons déjà vu que tous les Pollers communiquent avec tous les Schedulers. En fait, les Pollers peuvent être caractérisés ("tag") afin qu'ils n'exécutent que certains checks définis.
C'est très utile quand un utilisateur a des hôtes dans le même Scheduler (comme les dépendances) mais nécessite de lancer des checks depuis un Poller dédié.
Ces checks peuvent être caractérisés à 3 niveaux :
- Hôte
- Check
- Commande
Le paramètre pour caractériser une commande,un hôte ou un check, est le "poller_tag". Si un check utilise une valeur "tagged" ou une commande "untagged", il utilise le "poller_tag" de ce couple hôte/check
- commands that are global to all schedulers
- commands that are specific to one element (host/check).
For each command, Shinken Enterprise knows if it is global or not. If global, it just sends orders to all schedulers. For specific ones, it searches which scheduler manages the element referred by the command (host/check) and sends the order to this scheduler. When the order is received by schedulers they just need to apply them.
Different types of Pollers: poller_tag
The current Shinken Enterprise architecture is useful for someone that uses the same type of poller for checks. But it can be useful to have different types of pollers, like GNU/Linux ones and Windows ones. We already saw that all pollers talk to all schedulers. In fact, pollers can be "tagged" so that they will execute only some checks.
This is useful when the user needs to have hosts in the same scheduler (like with dependencies) but needs some hosts or checks to be checked by specific pollers (see usage cases below).
These checks can in fact be tagged on 3 levels :
- Host
- Check
- Command
The parameter to tag a command, host or check, is "poller_tag". If a check uses a "tagged" or "untagged" command in a untagged host/check, it takes the poller_tag of this host/check. In a "untagged" host/check, it's the command tag that is taken into account.
The pollers can be tagged with multiple poller_tags. If they are tagged, they will only take checks that are tagged, not the untagged ones, unless they defined the tag "None".
Use cases
Les Pollers peuvent être caractérisés par plusieurs "poller_tag". Si ils sont caractérisés, ils prendront uniquement les checks correspondant, excepté si la valeur du tag est "none". .
Cas d'usage
Cette fonctionnalité est très utile pour une DMZThis capability is useful in the DMZ case.
In the first case, it can be useful to have a windows box in a domain with a poller daemon running under a domain account. If this poller launches WMI queries, the user can have an easy Windows monitoring.
...