A quoi servent les modèles?
Il est très courant que de nombreuses informations soient redondantes parmi les éléments.
Le cas le plus flagrant concerne les hôtes : il est très probable qu'un certain nombre de machines partagent une logique de supervision commune.
Dès lors, il se pose un problème de maintenance : si cette logique doit évoluer, il se posera le problème de reporter les modifications sur tous les éléments.
De la même façon, si cette logique doit s'appliquer à un nouvel hôte, il faudra reporter toute la logique sur cet hôte.
Ces modifications sont simplifiées par l'utilisation de modèles.
Qu'est-ce qu'un modèle ?
Un modèle est un objet de configuration partiel, destiné à être réutilisé un certain nombre de fois.
Utiliser un modèle, ou hériter d'un modèle, permet de récupérer toute sa configuration : ses données, et dans le cas d'un modèle d'hôte, d'obtenir tous les checks qui lui sont attachés. Il est à noter qu'un modèle peut également hériter à son tour d'un autre modèle.
De cette façon, une configuration donnée peut être factorisée dans un modèle. Une fois factorisée, la configuration de ce modèle sera plus facile à maintenir, car les changements se répercuteront sur tous les éléments qui en héritent.
L'application des modèles
Un élément peut utiliser tout ou bien qu'une partie de la configuration de ses modèles. Il peut redéfinir (ou surcharger) des donnés qui étaient définies dans le modèle, ce qui permet la gestion de cas particuliers.
Enfin, un élément peut utiliser plusieurs modèles. La configuration de l'élément posséde toutes les valeurs (et tous les checks, dans le cas des hôtes) de ses modèles.
Si deux modèles définissent la même donnée, c'est le premier de la liste qui sera utilisé. Dans le cas des modèles d'hôtes, si deux modèles d'hôte ont deux checks de même nom, c'est le check du premier modèle qui sera utilisé.
Le schéma de droite illustre ce principe d'application des modèles. Ce calcul est réalisé par L'Arbiter.
Comment s'en sert-on ?
Pour hériter d'un modèle, il faut se placer sur l'élément final (par exemple un hôte).
Un sélecteur permet de saisir les modèles à hériter :
- en vert : les modèles sont utilisables
- en orange : les modèles sont existants mais désactivés
- en gris : les modèles n'existent pas
Dans le cas des hôtes, si ceux-ci ont des checks appliqués, ils seront affichés dans l'onglet check de la page de l'hôte.
Les propriétés héritées sont affichées en violet dans l'interface.
Un bouton permet de désactiver ou de réactiver l'héritage d'une propriété.
Si cette propriété est définie dans l'élément final, elle est surchargée et l'héritage est donc désactivé. Cela est signalé par un fond noir.
Gestion des conflits
Il peut arriver que lors de l'application des modèles, plusieurs checks de même nom soit accrochés sur l'hôte par des moyens différents (héritage ou accrochage direct).
Dans ce cas, Shinken Entreprise définit un ordre de priorité pour décider quel sera le check utilisé.
L'ordre de priorité est le suivant:
- Check directement accroché sur l'hôte
- Check directement accroché sur le premier modèle
- Check accroché sur le premier modèle (par héritage)
- Checks accrochés sur les modèles suivants (en suivant l'ordre d'application des modèles)
- Checks accrochés sur l'hôte par l'intermédiaire d'un groupe d'hôtes
Si Shinken Entreprise ne peut pas résoudre le problème grâce à l'ordre de priorité, une erreur de configuration sera remontée indiquant qu'il est impossible de décider quel check choisir.
Dans le schéma ci-contre, on remarque plusieurs choses:
- L'ordre d'application des modèles est important. En effet, dans le schéma, le modèle d'hôte 1 aura la priorité sur le modèle d'hôte 2 car il est appliqué en premier sur l'hôte.
- Il n'y a pas de notion d'ordre sur les groupes d'hôtes. Si il y a un conflit de nom au niveau de checks accrochés sur les groupes d'hôtes, une erreur de configuration sera générée. Shinken Entreprise ne peut pas définir de priorité sur les groupes et ne peut donc pas déterminer quel check à appliquer sur l'hôte.
