Bonnes pratiques: pourquoi et comment utiliser les modèles de service

Dans l’article précédent nous vous avions expliqué que de notre point vue il fallait éviter d’attache un service à une groupe d’hôtes. En conclusion nous vous suggérions d’utiliser plutôt les templates de service pour organiser la configuration de votre plateforme de supervision. Vous trouverez donc dans l’article qui suit plusieurs raisons d’utiliser les templates de service (facilité, flexibilité…) et un exemple détaillé de façon de les utiliser efficacement. Les modèles de service se basent sur les principes de la programmation orientée objet : l’héritage et la surcharge.

Définition

Un modèle de service est un objet de supervision Centreon qui possède toutes les caractéristiques d’un service et peut être utilisé comme base pour la configuration d’un autre service. Un modèle de service est concrètement un service pré-configuré : certaines informations sont déjà intégrées. Il n’est pas obligatoire de définir toutes les informations d’un modèle de service. Un service possède des paramètres obligatoires : ils doivent être obligatoirement définis, sinon la configuration n’est pas acceptée. Un modèle de service n’a pas cette contrainte. Exemple :  pour définir un modèle de service, se rendre sur la page « Configuration → Services → Templates » puis cliquer sur le lien « add » :

01_creation_modele_de_service

Dans la capture d’écran ci-dessus, seules les deux premières lignes sont obligatoires : le nom du service (« Alias ») et le nom du modèle de service (« Service Template Model »). Des paramètres sont définis comme la commande de supervision (« Check command ») et des arguments (« args »).

Héritage avec les modèles de service

Un service peut « hériter » d’un modèle de service : lorsque je définis le service, j’indique qu’il fait référence à un modèle de service. Dès lors, il « hérite » de tous les paramètres définis dans le modèle de service parent. Exemple : lorsque je crée un service, je peux choisir le modèle de service dont hérite ce service grâce à la ligne « Service template » :

02_creation_service_base_sur_modele

Dans la capture d’écran ci-dessus, un service est créé et se base sur le modèle « SNMP-DISK-/ ».

Surcharge

Lorsqu’un service hérite d’un modèle de service, il est possible de « surcharger » un paramètre : il s’agit de forcer un paramètre d’un service spécifique même si celui‑ci est déjà défini dans le modèle de service initial. Dès lors, le paramètre réellement utilisé par ce service sera le paramètre forcé/surchargé.

Héritage d’un modèle de service par un modèle de service

Un modèle de service peut lui aussi hériter d’un modèle de service. Le fonctionnement est le même que ci‑dessus : héritage et surcharge. Cette fonctionnalité est importante car elle permet d’affiner la configuration au fur et à mesure. Exemple :

03_heritage_modele_de_service

Dans l’exemple ci‑dessus, le modèle de service nommé « SNMP-DISK-/ » se base sur un modèle de service « generic-service ».

Exemple d’héritage hiérarchique

Soit un modèle de service appelé « generic-service », dont le but est de définir un modèle générique. Il doit contenir tous les paramètres par défaut. Voici sa configuration type.

Nom du paramètre
Valeur du paramètre
Commentaire
Alias
generic-service
Paramètre obligatoire : il définit le nom du service tel qu’il apparaîtra dans la supervision
Service Template Name
generic-service
Paramètre obligatoire : il définit le nom du modèle de service
Is volatile
No
Par défaut, aucun de mes service n’est volatile
Check Period
24×7
Par défaut, tous mes services sont supervisés en 24×7
Max Check Attempts
3
Par défaut, tous mes services disposeront de 3 tentatives consécutives en erreur avant d’être en statut d’erreur confirmée
Normal Check Interval
15
Par défaut, intervalle entre deux tests
Retry Check Interval
1
Par défaut, intervalle entre deux tests lorsque le statut d’erreur n’est pas confirmé
Active Checks Enabled
yes
Par défaut, tous mes tests sont actifs
Passive Checks Enabled
No
Par défaut, tous mes tests ne sont pas passifs
Notification Enabled
Yes
Par défaut, les notifications sont activées
Notification Interval
0
Par défaut, une et une seule notification est envoyée
Notifcation Period
24×7
Par défaut, la période de notification est 24×7
Notification Type
Warning, Critical
Par défaut, je ne notifie que sur les alertes « critiques » et « attention »

 

La configuration ci‑dessus est la configuration que je considère par défaut. Tous mes services doivent disposer de cette configuration.

Soit un deuxième modèle de service appelé « p1-services » : les services de priorité 1, que l’on supervise de manière plus fréquente :

Nom du paramètre
Valeur du paramètre
Commentaire
Alias
p1-service
Paramètre obligatoire : il définit le nom du service tel qu’il apparaîtra dans la supervision
Service Template Name
p1-service
Paramètre obligatoire : il définit le nom du modèle de service
Service Template Model
generic-service
Le modèle de service « p1-service » hérite du modèle de service « generic-service »
Normal Check Interval
5
Paramètre surchargé ! Intervalle entre deux tests plus court : service prioritaire.

 

Soit un troisième modèle de service appelé « p2-services » : les services de priorité 2, que l’on supervise de manière moins fréquente :

Nom du paramètre
Valeur du paramètre
Commentaire
Alias
p2-service
Paramètre obligatoire : il définit le nom du service tel qu’il apparaîtra dans la supervision 

Service Template Name
p2-service
Paramètre obligatoire : il définit le nom du modèle de service
Service Template Model
generic-service
Le modèle de service « p2-service » hérite du modèle de service « generic-service »

 

Je ne touche aucun autre paramètre : le paramètre par défaut convient très bien.

Soit un quatrième modèle de service appelé « p3-services » : les services de priorité 2, que l’on supervise de manière encore moins fréquente :

Nom du paramètre
Valeur du paramètre
Commentaire
Alias
p3-service
Paramètre obligatoire : il définit le nom du service tel qu’il apparaîtra dans la supervision
Service Template Name
p3-service
Paramètre obligatoire : il définit le nom du modèle de service
Service Template Model
generic-service
Le modèle de service « p3-service » hérite du modèle de service « generic-service »
Normal Check Interval
60 

Paramètre surchargé ! Intervalle entre deux tests plus long : service beaucoup moins prioritaire.

 

Un modèle de service permettant de superviser un processus important de mon système :

Nom du paramètre
Valeur du paramètre
Commentaire
Alias
proc-syslog
Paramètre obligatoire : il définit le nom du service tel qu’il apparaîtra dans la supervision
Service Template Name
SNMP-PROC-SYSLOG
Paramètre obligatoire : il définit le nom du modèle de service
Service Template Model
p1-service
Le modèle de service hérite du modèle de service « p1-service » car le processus syslog est critique pour moi
Check Command
check_centreon_process
Utilisation de la commande permettant de superviser un processus
Args
SNMP version : 2c
community : public
process name: syslogd
Arguments de la commande

 

L’intérêt du cas ci-dessus est de présenter une organisation simple, à titre d’exemple : la configuration standard est synthétisée dans le modèle de plus haut niveau (« root object »). Tous les modèles de service héritent de ce modèle par défaut.

Stratégie

Bien utilisés, ces modèles apportent une valeur ajoutée aux administrateurs : simplicité et souplesse de conception. Pour cela, il est nécessaire de disposer d’une bonne stratégie. Par expérience, nous rencontrons régulièrement deux comportements différents :

  1. le plus fréquent : un trop grand découpage ! Il y a 5 niveaux hiérarchiques entre le modèle de plus haut niveau et le service. Les modèles sont tellement découpés que la configuration en devient illisible, que pour modifier un service il est nécessaire de modifier plusieurs modèles de services.
  2. Le moins fréquent : trop peu de découpage. Il n’y a qu’un seul niveau hiérarchique entre le modèle de plus haut niveau et le service. En fait, tous les modèles de service définissent tous les paramètres. Il y a une factorisation mais très légère. Il est nécessaire de factoriser la configuration des modèles de service en plus de factoriser la configuration des services par des modèles.

Il n’y a pas de « meilleur chiffre » pour le nombre total de modèles ou le nombre de niveaux hiérarchiques. Tout dépend du nombre d’équipements différents, de l’organisation du Système d’information et des équipes. Cependant, nous pouvons dire qu’il faut au moins 2 niveaux hiérarchiques dans les modèles de service et avoir plus de 5 niveaux est trop complexe à gérer.

Incoming search terms:

  • centreon tuto utilisation modele

Une réflexion au sujet de « Bonnes pratiques: pourquoi et comment utiliser les modèles de service »

  1. Bonjour,

    Le meilleur moyen est de ne pas supprimer les services mais de les désactiver. Cela permet de rajouter seulement les nouveaux services lors de l’ajout d’un nouveau modèle d’hôte ou d’appliquer une modification unitaire.

Leave a Reply