Supervision : Comprendre et utiliser les templates
I. Présentation
Après avoir étudié les notifications en supervision, nous allons voir comment utiliser des templates dans un système de supervision open source. Je me suis basé sur la configuration de Naemon, mais c’est parfaitement applicable sur d’autres systèmes comme Nagios, Inciga1 ou Shinken.
Les templates sont indispensables pour optimiser la configuration d’un système de supervision. Un template est enfaite un modèle (ou modèle/patron, prenez le terme qui vous convient) sur lequel vous vous baserez pour créer vos objets.
II. Comment ça marche ?
Le template n’a de sens que si vos objets sont créés avec des paramètres identiques. Le principe est que votre template contient les paramètres qui seront communs à vos objets. Ensuite, vous ferez référence à ces templates dans vos objets finaux pour qu’ils héritent des paramètres. Vous pourrez utiliser le système de template sur tout type d’objet.
Pour créer un template, rien de plus simple. Vous créez un objet de manière classique qui comporte les paramètres communs que vous voulez transmettre. Vous aurez ensuite besoin de jouer uniquement avec trois paramètres : name, register et use.
Sans surprise, le paramètre name servira à donner un nom à votre template. Le paramètre use lui permet d’utiliser un template en spécifiant son nom. Le paramètre register prend deux valeurs, 0 et 1. Votre système se servira de ce paramètre pour savoir s’il doit enregistrer l’objet comme objet ou non
- La valeur 1 indiquera qu’il faut créer l’objet, il apparait dans mon système de supervision (valeur par défaut).
- La valeur 0 indiquera qu’il ne faut pas créer l’objet, il n’apparaitra pas dans mon système de supervision.
Dans les deux cas, vous pourrez utiliser votre objet comme modèle.
Qu’est-ce que ça change alors ?
Ça change que nous pouvons créer des objets "incomplets" que nous utiliserons comme modèle de base pour créer d’autre objet.
Je vous explique ça tout de suite, voici un exemple :
define host {
name modele_host
check_period 24x7
contacts michel, pascal, beatrice
contact_groups administrateurs
register 0
}
Ici j’ai créé un template pour mes hôtes, son nom est défini par le paramètre name. Il s’appelle donc modele_host. Maintenant j’utilise mon template pour créer deux serveurs :
define host {
host_name SRV1
address 192.168.1.101
use modele_host
}
define host {
host_name SRV2
address 192.168.1.102
use modele_host
}
J’ai créé deux serveurs qui héritent des paramètres du template modele_host en utilisant le paramètre use. Voici à quoi ressemble mon objet SRV1 après héritage des paramètres :
host_name SRV1 address 192.168.1.101 check_period 24x7 contacts michel, pascal, beatrice contact_groups administrateurs
Le paramètre register ne s’hérite pas, l’objet SRV1 est donc créé, car il sera défini à 1. J’aurais pu utiliser une autre stratégie en "dupliquant" mes objets. Exemple avec SRV1, je le crée puis je l’utilise pour créer SRV2 :
define host {
host_name SRV1
address 192.168.1.101
check_period 24x7
contacts michel, pascal, beatrice
contact_groups administrateurs
name modele_srv register 1 #valeur par défaut, pas obligé de le spécifier
}
Je viens de créer SRV1, il est enregistré dans mon système comme objet (register 1, vous vous souvenez ?). Je lui ai donné un nom de modèle avec le paramètre name. Maintenant je créer SRV2 à partir de mon objet SRV1 :
define host {
host_name SRV2
address 192.168.1.102
use modele_srv
}
Dans l’héritage nous avons un conflit avec deux paramètres, address et host_name. Hé oui, nous les avons définis une première fois dans l’objet SRV1. Alors comment ça se passe dans ce cas ? Si un paramètre existe déjà dans l’objet qui hérite, l’héritage du paramètre sera bloqué. Notre hôte SRV2 aura donc les paramètres suivants après héritage :
host_name SRV2 address 192.168.1.102 check_period 24x7 contacts michel, pascal, beatrice contact_groups administrateurs
III. Les cascades
Vous pouvez aussi multiplier et mettre en cascade vos héritages. Suivez donc l’exemple à suivre, toujours pour créer notre hôte SRV1 :
define host {
contacts michel, pascal, beatrice
check_period holidays
name heritage1
register 0
}
define host {
check_period 24x7
use heritage1
name heritage2
register 0
}
define host {
host_name SRV1
address 192.168.1.101
use heritage2
}
Alors que s’est-il passé ? Prenons l’objet final, celui qui sera créé avec le nom SRV1. Il hérite des paramètres du template heritage2. Heritage2 contient un paramètre et hérite des paramètres du template heritage1. Et j’aurais pu encore continuer longtemps, ça devrait être suffisant pour comprendre le principe j’espère. Quelque part on peut dire que nous faisons de l’inception d’objets :p
Mais je viens de remarquer ça, dans les deux templates on a le paramètre check_period avec deux valeurs différentes. Quelle valeur aura-t-il pour l’objet SRV1 ? C’est vrai, dans ce cas on applique le principe de l’héritage classique, c’est-à-dire que le template heritage2 va couper l’héritage du paramètre check_period. Il aura donc la valeur 24x7 pour notre hôte SRV1.
IV. Multiples sources
C’est sympa l’inception d’objet en tout cas, mais on ne s’est pas un peu compliqué la vie ? Maintenant que vous le dites, on pouvait faire plus simple en héritant les deux templates directement sur l’objet final, comme ceci :
define host {
host_name SRV1
address 192.168.1.101
use heritage2, heritage1
}
Pas mal, et dans ce cas-ci nous n’avons pas d’héritage direct, il devient quoi mon paramètre check_period ? Bonne question. Ici vu que le paramètre est en conflit au même niveau entre le template heritage1 et heritage2, c’est le premier template du paramètre use qui a la priorité. Dans notre exemple l’hôte SRV1 va récupérer le paramètre check_period du template heritage2 avec la valeur holidays. Allé je sens qu’un petit schéma ne fera pas de mal 🙂
Alors de quelle couleur sera chaque cercle ? Sachant que le gris indique que le cercle n’a pas de paramètre couleur définie
- Commençons par le début avec le cercle color1. Color1 n’a aucune couleur de définie. Il aurait pris la couleur par défaut s’il y en avait un
- Color2 et 3 sont respectivement de couleur bleu et vert.
- Pour le cercle color4, nous avons un héritage par color1 et 2 avec une priorité sur color1. Vu que la couleur n’est pas définie sur color1 ça sera le bleu de color2 qui sera hérité.
- Color5 est hérité de color3, mais vu qu’il a déjà sa couleur jaune il bloc l’héritage du vert de color3.
- Color6 prend l’hérite de color4 et 5 avec une priorité sur color4. Color4 est de couleur bleue par héritage donc il aurait pu hériter la couleur bleue à color6 si il n’avait pas déjà la couleur rouge. Color6 bloque donc l’héritage de 4 et 5 et reste rouge.
- Color7 ne bloque pas l’héritage de couleur étant donné qu’il n’en a pas de défini, il gagne donc la couleur rouge de color6.
- Et enfin color8 est et reste violet en bloquant l’héritage.
Les templates sont indispensables pour créer ses objets de manière efficace. Étant très flexible, à vous de trouver l’organisation qui vous convient. L’avantage du template c’est aussi que si vous avez une modification d’envergure à faire sur vos objets, en modifiant vos templates vous faites votre modification d’une seule manipulation. N’hésitez pas à nous faire part de vos interrogations 😉
