Règles de nommage des objets

Liste des forces en présence

Préambule

Il n’est pas rare d’avoir des pages Centreon avec une liste interminable d’indicateur. Quand nous utilisons l’ascenseur de notre indicateur et que nous sommes en bas de la page le menu disparaît et c’est la cata 😀 Je vais donc vous présenter un méthode perfectible mais simple d’identifier l’objet que vous êtes en train de manipuler. Le chois de préfixer les objets est simple. Cela permet :
  • De ne pas modifier les templates fournis par centreon ( facilitant les mise à jours de Centreon)
  • De faire dépendre nos templates préfixés des templates Centreon en les surchargeant selon nos besoins et en prenant en compte les correctifs que les mises à jours pourraient apporter.
  • De faciliter la maintenance des objets structurant permettant de déploiement des indicateurs

Les Objets de supervision

Quels sont les objets ?

Même si Centreon à ces début s’appuyait sur les fichiers de configuration de Nagios, il a apporté beaucoup d’objets que n’agios n’apportait pas. Pour les identifier facilement, il est important de préfixer les objets de configuration. Pour chaque objet vous aurez :
  • Le nom de l’objet
  • Le préfixe à appliquer à l’objet de configuration

Les objets de Nagios

Les utilisateurs

  • Contact groups –> CG_
  • Time Periods –> TP_

Les services

  • Service groups –> SG_
  • Service Templates –> TS_
  • Service Categories –> SC_
Mais pourquoi tu nous dits TS_ et non ST_ , dit donc ? C’est un choix purement personnel, les autres articles utiliseront donc ce préfixe 😀 Nous pourrions palabrer des heures sur la pertinence de tel où tel préfixe. Ce qui est important c’est que les préfixes soient partagés par tous. Donc si vous préférez ST_ ca marche aussi 🙂

Les hôtes

  • Host Template –> TH_
  • Host groups –> HG_
  • Host categories –> HC_
Pour les chois sur les préfixes cf plus haut 🙂 Les dépendances Si vous n’utilisez que les dépendances de services :
  • Vous pouvez utiliser le préfixe DEP_ ou DP_
  • Il est important de mentionner :
    • Le nom du serveur
    • Le nom du service maitre
Par exemple :
  • DEP_Serveur1_Ping pour une dépendance des services sur le ping du Serveur1
  • DEP_Serveur1_SNMP pour une dépendance des services supervisés en SNMP, sur le service SNMP,  sur le Serveur1
  • DEP_Serveur1_SSH pour une dépendance des services supervisés en SSH, sur le service SSH, sur le Serveur1
Généralement :
  1. Je fait une dépendance du ping sur tous les vecteurs de supervision utilisés
  2. Une dépendance de chaque vecteur en fonction du vecteur utilisé pour l’indicateur
Il est important d’utiliser l’héritage de dépendances pour avoir la route cause du dysfonctionnement d’un indicateur

Les Objets Centreon

Les ACLs

Il n’est pas rare de mettre en place des ACLs pour permettre de présenter des indicateurs en fonction de l’expertise des utilisateurs de Centreon et des routes cause ayant un impacte sur son domaine d’expertise (Je ferais un sujet sur la visibilité de la supervision). Personnellement, j’utilise les ACLs via des groupes dans l’AD pour 2 choses :
  1. Plus besoin de gérer les utilisateurs dans Centreon ( Autant utiliser l’AD pour cela, une simple demande d’habilitation suffit, et c’est du travail en moins pour l’administrateur 😀 )
  2. Un nouvel utilisateur sera créé automatiquement dans Centreon avec la vue pertinente en fonction de son expertise.
nous avons donc 4 type d’objets à gérer :
  • Access Groups –> AG_
  • Menus Access –> MA_
  • Resources Access –> RA_
  • Actions Access –> AA_
Table des matières
WordPress Appliance - Powered by TurnKey Linux