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 🙂

schema-supervision-01

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 😉

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Cyprien Santana

Geek raisonnable, passionné par le "bidouillage" et les nouvelles technologies. Je viens ici pour partager mes connaissances avec vous ! Je travaille beaucoup sur les réseaux et la sécurité, avec une petite touche supervision. Je viens aussi en tant que lecteur sur IT-Connect pour augmenter mon capital connaissance ;)

    cyprien has 9 posts and counting.See all posts by cyprien

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

     

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.