| Scroll Ignore |
|---|
| scroll-viewport | true |
|---|
| scroll-pdf | true |
|---|
| scroll-office | true |
|---|
| scroll-chm | true |
|---|
| scroll-docbook | true |
|---|
| scroll-eclipsehelp | true |
|---|
| scroll-epub | true |
|---|
| scroll-html | false |
|---|
|
|
Un Tagger utilisant un module basé sur les plages IP ( de type sync_ip_tag ) s'applique sur les hôtes, issus de l'import des sources.
- Il permet de modifier un hôte, si son adresse est comprise dans la plage d’adresses IP définie par son module.
| Info |
|---|
Ce Tagger résout les noms DNS dans l'adresse des hôtes avant de vérifier si l'adresse est comprise dans la plage d’adresses IP. - Ce qui permet à ce Tagger de fonctionner avec une définition d'une plage IP, ce que ne peut pas faire un Tagger basé sur des expressions régulières.
|
Exemple : automatiquement assigner au royaume Bordeaux les hôtes/clusters dont l'IP est dans la plage 192.168.0.1/24
Exemple 1 : ip-tag-bordeaux - mettre le nom du royaume directement dans la propriété définissant le royaume
Si les serveurs dans la plage IP 192.168.0.1/24 se trouvent dans le datacenter de 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_ip_tag suivant permet ce comportement :
- Si l’adresse IP définie dans la propriété address de l’hôte appartient à la plage 192.168.0.0/24
- 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 |
|---|
| language | js |
|---|
| theme | Confluence |
|---|
|
define module{
|
Vous pouvez définir un tagger qui utilise les plages IP pour détecter automatiquement des éléments et leur appliquer une règle.
Pour chaque règle, vous devez définir un nouveau module et l'ajouter dans la configuration ip-tags .
Vous pouvez copier l'exemple /etc/shinken/modules/ip-tag-dmz.cfg et le modifier
| Code Block |
|---|
define module{dc1bordeaux
module_type sync_ip_tag
# La plage IP de l'hôte ( propriété address )
ip_range 192.168.0.0/24
# Liste des noms d'hôte qui seront ignorés par le Tagger ( propriété host_name )
# ignore_hosts
# |
On va alors écraser la propriété realm avec la |
valeur Bordeaux
property realm
method |
| Warning |
|---|
|
À 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_ip_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.
|
Exemple 2 : ajouter un modèle "bordeaux", mis en premier dans la liste des modèles ( pour être 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_ip_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.
- 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_ip_tag suivant permet ce comportement.
- SI l’adresse IP définie dans la propriété address de l’hôte appartient à la plage 192.168.0.0/24
- 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 |
|---|
| language | js |
|---|
| theme | Confluence |
|---|
|
define module{
module |
Les propriétés sont :
- module_name: doit être unique
- module_type: doit être égal à sync-regexp-tag
matched_prop: la propriété qui doit correspondre.Par défaut, la propriété est le host_name (Nom de l'objet hôte)
matched_regexp: Regexp auquel l'objet doit correspondre
- method: comment vous voulez modifier l'objet détecté:
- replace: mettre la valeur si aucune en place
- append: ajouter la valeur à la FIN du template
- prepend: ajouter la valeur au DEBUT du template
- set: mettre juste la valeur, en écrasant la valeur précédente .
- property: quelle propriété modifier
- value: quelle valeur prendre en compte
Vous devez ensuite éditer la définition du tagger pour la lier au nouveau module dans le fichier /etc/shinken/taggers/ip-tags.cfg:
| Code Block |
|---|
define tagger {
tagger-tags
order-tag-bordeaux
module_type sync_ip_tag
# La plage IP de l'hôte ( propriété address )
ip_range 192.168.0.0/24
# Liste des noms d'hôte qui seront ignorés par le Tagger ( propriété host_name )
# ignore_hosts
# On va alors écraser la propriété realm avec la valeur Bordeaux
property |
Visualisation dans l'interface de configuration
Sur l'Interface de Configuration, les noms des Taggers listés sont des liens cliquables.
| Panel |
|---|
 Image Added
|
- Ces liens redirigent sur leurs configurations.
| Panel |
|---|
 Image Added |
Un onglet permet de visualiser également un résumé des règles qui vont s'appliquer.
| Panel |
|---|
 Image Added
|
| Info |
|---|
La propriété tagger_name ne doivent pas contenir les caractères suivants: - <
- >
- "
- '
|
Vous devez ensuite redémarrer votre synchronizer.