Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make by tools (01.00.01) - action=clean_macro_parameter
Scroll Ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-htmlfalse
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtruescroll-htmlfalse
Panel
titleSommaire

Table of Contents
stylenone

Concept

Un Tagger utilisant un module basé sur des les expressions régulières ( de type sync-regexp-tag ) s'applique sur les éléments, issus de l'import des sources, suivants  :sur les hôtes,

les

 clusters,

les modèles d'hôtes

ou

, les modèles de clusters, issus de l'import des sources.

  • Il utilise une expression régulière ( regexp ) sur une propriété ou une donnée pour sélectionner les éléments auxquels appliquer la modification configurée
pour le Tagger.

Il est notamment possible avec ce tagger de modifier la liste des modèles d'un hôte ou d'un cluster en fonction de son nom.

Configurer un Tagger

  • par son module.



Info

Pour résoudre les éléments qu'il doit modifier, ce Tagger peut utiliser n'importe quelle propriété ou donnée de l'élément à configurer. De plus, il n'est pas limité aux hôtes.

  • Ce que ne peut pas faire un Tagger utilisant un module basé sur les plages IP



Définir ou configurer un Tagger

Regarder :

L'activation d'un Tagger se fait en trois étapes :

  • Définir un Tagger qui utilise un module de type sync_ip_tag ( exemple : /etc/shinken/taggers/ip-tags.cfg ).
  • Configurer les règles du module ( exemple : /etc/shinken/modules/ip-tag-dmz.cfg ).
  • Déclarer le Tagger dans le Synchronizer  ( exemple : /etc/shinken/synchronizers/synchronizer-master.cfg ).( voir la page Définition du démon ( synchronizer-master.cfg ) )


Exemple : automatiquement assigner au royaume Bordeaux les hôtes/clusters dont le nom commence par bdx

Exemple 1 : mettre

la valeur

le nom du royaume directement dans la

valeur du

propriété définissant le royaume

Si les éléments dont le nom commence par la chaine bdx, sont situés à Bordeaux, il est pertinent de les assigner automatiquement au royaume Bordeaux. Cela permet une supervision plus efficace, par exemple en utilisant le Poller du royaume Bordeaux, autorisé par les pare-feux de ces serveurs.


Le module de type sync_regexp_tag suivant permet ce comportement :

  • SI la propriété host_name ( le nom ) de l'hôte/cluster commence par bdx
    • ALORS, on va écraser ( paramètre method à la valeur "set" ) la propriété realm ( paramètre "property" ) avec la valeur Bordeaux ( paramètre "value" ).
Code Block
languagejs
themeConfluence
define module{
  module_name       sync-regexp-tag-bordeaux-basic
  module_type       sync-regexp-tag

  # La regexp a appliquer
  matched_regexp    ^bdx.*
  
  # on va appliquer la regexp sur le nom de l'hote/cluster
  matched_prop      host_name

  # On va alors ecraser la propriete realm avec la valeur Bordeaux
  property          realm
  method            set
  value             Bordeaux

}
Warning
titleIMPORTANT

À noter que cette méthode est facile à appréhender, mais n'est pas une bonne pratique sur le long terme :

  • en effet, il pourra être nécessaire de modifier d'autres propriétés liées, en lien avec le datacenter de bordeaux dans le futur ( ajout d'utilisateur à notifier sur l'hôte, dépendances réseaux ... ), 
  • cela nécessitera d'ajouter des modules de Taggers de type sync-regexp-tag pour chaque nouvelle édition de propriété.

La bonne pratique est de définir un modèle d'hôte et de l'accrocher systématiquement aux équipements de ce datacenter.

  • Ainsi, vous pourrez avoir un modèle où mettre les futures spécificités du datacenter de bordeaux.
  • le prochain exemple en explique la mise en place.
Info
Shinken conseil de passer par des modèles d'hôtes, car ils permettent plus de flexibilité. Il suffit de faire évoluer le modèle dans le temps sans avoir besoin de modifier la configuration de Shinken. ( voir l'exemple suivant )

Exemple 2: plus flexible, rajouter un modèle "bordeaux", prioritaire sur les autres modèles

Si la méthode précédente fonctionne, elle n'est pas optimale :

  • en effet, changer le royaume par Bordeaux est utile, mais d'autres éditions de propriétés seront peut-être nécessaires dans le futur ( ajout d'utilisateur à notifier sur l'hôte, dépendances réseaux ... ).
  • Or la méthode précédente impose de créer un nouveau Tagger avec un nouveau module de type sync_regexp_tag pour chaque nouvelle édition de propriété.


Il est donc fortement recommandé de ne pas modifier les propriétés directement, mais plutôt de passer par des modèles d'hôtes/cluster.

Il sera ainsi facile de faire des changements sur toutes les machines situées à Bordeaux, en modifiant juste le modèle Bordeaux.


Le module de type sync_-regexp_-tag suivant permet ce comportement :

  • SI la propriété host_name ( le nom ) de l'hôte/cluster commence par bdx
    • ALORS, on va rajouter au début ( paramètre method à la valeur "prepend" ) de la propriété use ( paramètre "property"  ) la valeur bordeaux ( paramètre "value" ).
Code Block
languagejs
themeConfluence
define module{
  module_name       sync-regexp-tag-bordeaux-recomanded
  module_type       sync-regexp-tag

  # La regexp a appliquer
  matched_regexp    ^bdx.*
  
  # on va appliquer la regexp sur le nom de l'hote/cluster
  matched_prop      host_name

  # On va alors rajouter le template bordeaux au debut de use (prioritaire)
  property          use
  method            prepend
  value             bordeaux
}

Visualisation dans l'interface de configuration

Sur l'Interface de Configuration, les noms des Taggers listés , sont des liens cliquables qui .


Panel

Image Added


  • Ces liens redirigent sur leurs configurations.


Panel
Image Removed

Image Added

  • Un onglet permet de visualiser également un résumé des règles qui vont s'appliquer.


Panel
Image RemovedImage Added