| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Concept
Comment définir un tagger
Configurer un Tagger
L'activation d'un Tagger se fait en trois étapes
- Définir un Tagger qui utilise un module de type sync_ip_tag ( ex : /etc/shinken/taggers/ip-tags.cfg ).
- Configurer les règles du module ( ex : /etc/shinken/modules/ip-tag-dmz.cfg).
- Déclarer le Tagger dans le Synchronizer (/etc/shinken/synchronizers/synchronizer-master.cfg ).
( voir la page Voir la documentation comment configurer le tagger : Module ip-tag-dmz
Cas des champs address des hôtes qui sont des noms DNS
).
Le Taggercompare les adresses IP des hôtes à une plage d’adresses définie. Si un hôte utilise un nom DNS comme adresse, le module effectue une résolution DNS afin de déterminer son adresse IP.
Exemple
Le tagger est fait pour comparer des IP par rapport à des ranges d'IP.
Si le champ address d'un hôte est rempli avec un nom DNS, alors le tagger va tenter de le résoudre via une résolution DNS système classique, et prendra comme valeur l'IP ainsi récupérée.
Cas d'exemple: automatiquement assigner au royaume Bordeaux les hôtes/clusters dont l'
ipIP est dans
le rangela plage 192.168.0.1/24
Exemple 1 : mettre la valeur du royaume directement dans la valeur du royaume
Si on sait que les les serveurs dans le range la plage IP 192.168.0.1/24 sont se trouvent à Bordeaux, il est intéressant pertinent de l’assigner les assigner automatiquement au royaume Bordeaux, ce qui permettra de les superviser au plus proche possible ( et donc avoir les bonnes règles de firewall par exemple pour lancer les sondes vers les serveurs ).
On peut donc définir le module suivant qu'on accroche au tagger ( comme indiqué précédemment ).
Il va fonctionner ainsi :
. 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 SI l'IP correspondant au champ address de l'hôte/cluster est dans le range 192.168.0.0/24
- ALORS, on va on va écraser ( paramètre
method=set) le champ realm (propertyà la valeur"set""property") avec la valeur Bordeaux( paramètre"value").
- ALORS, on va on va écraser ( paramètre
| Code Block | ||||
|---|---|---|---|---|
| ||||
define module{
module_name ip-tag-bordeaux-basic
module_type sync_ip_tag
# La rangeplage IP de l'hotehôte (champ propriété address )
ip_range 192.168.0.0/24
# Liste #des onnoms vad'hôte appliquerqui laseront regexpignorés surpar le nomTagger de l'hote/cluster
matched_prop host_name( propriété host_name )
# ignore_hosts
# On va alors ecraserécraser la proprietepropriété realm avec la valeur Bordeaux
property realm
method set
value Bordeaux
} |
| 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. |
Exemple 2 :
plus flexible, rajouterajouter un modèle "bordeaux"
(, prioritaire
sur lesaux autres modèles
)Si la méthode 1 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 la localisation à Bordeaux va peut-être demander à ce qu'une équipe locale ait les droits d'accès et de notifications sur la machine par exemple.Il faudrait alors faire un second module, ce n'est pas l'idéal( 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/cluster.
Il sera ainsi facile de faire des changements en masse sur toutes les machines situées à Bordeaux, en modifiant juste le modèle Bordeaux.
On peut donc définir le module suivant qu'on accroche au tagger ( comme indiqué au-dessus ).
Il va :
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 SI l'IP correspondant au champ address de l'hôte/cluster est dans le range 192.168.0.0/24
- ALORS, on va rajouter au début ( paramètre
method=à la valeur"prepend") le champ de la propriété use ( paramètre"property") avec la valeur bordeaux ( paramètre"value").
- ALORS, on va rajouter au début ( paramètre
| Code Block | ||||
|---|---|---|---|---|
| ||||
define module{
module_name ip-tag-bordeaux-advancedbasic
module_type sync_ip_tag
# La rangeplage IP de l'hotehôte (champ propriété address )
ip_range 192.168.0.0/24
# Liste #des onnoms vad'hôte appliquerqui laseront regexpignorés surpar le nomTagger de l'hote/cluster
matched_prop host_name( propriété host_name )
# ignore_hosts
# On va alors rajouterécraser lela templatepropriété bordeauxrealm auavec debutla de use (prioritaire)valeur Bordeaux
property userealm
method prepend
value bordeauxBordeaux
} |
Visualisation dans l'interface de configuration
Il est possible de consulter la configuration des différents taggers sur nom d'hôtes présent sur le Synchronizer sur la page d'accueil en cliquant sur regexp-tagsSur l'Interface de Configuration, les noms des Taggers listés, sont des liens cliquables qui redirigent sur leurs configurations.
| Panel |
|---|
|
Un onglet permet de visualiser également un résumé des règles qui vont s'appliquer.
| Panel |
|---|
|
