| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Fonctionnement
Comment définir une nouvelle 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{
module_name ip-tag-dc1
module_type sync_ip_tag
ip_range 192.168.0.0/24
method append
property use
value dc1
} |
Les propriétés sont :
- module_name: le nom du module ( doit être unique ).
- module_type: doit être égal à sync_ip_tag.
- ip_range: si l'adresse de l'hôte (champ address) est dans la plage IP fourni, on applique la modification ci après.
- method: Comment la modification de la propriété va avoir lieu sur l’élément :
- replace: si aucune valeur n’était définie dans la propriété à vérifier, le contenu de
valuesera mis dans la propriété visée, c.a.d.property. - append: ajoute le contenu de
valueà la fin dans la propriété visée, c.a.d.property. - prepend: ajoute le contenu de
valueau début de la propriété visée, c.a.d.property. - set: force le contenu de
valuedans la propriété visée, c.a.d.property.
- replace: si aucune valeur n’était définie dans la propriété à vérifier, le contenu de
- property: quelle propriété modifier
- value: la liste des modèles qui seront ajoutés.
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_name ip-tags
order 1
modules ip-tag-dmz,ip-tag-dc1
description This tagger will tag hosts based on their ip range
}
|
| Info |
|---|
La propriété tagger_name ne doit pas contenir les caractères suivants:
|
Concept
Un Tagger utilisant un module basé sur les expressions régulières ( de type sync-regexp-tag ) s'applique sur les hôtes, clusters, les modèles d'hôtes, 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 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.
|
Définir ou configurer un Tagger
Regarder :
- La page Les modules taggers, pour mettre en place un Tagger ou en modifier un.
- La page Module de type sync-regexp-tag, pour créer ou modifier l'action faite, par le module, sur les éléments configurés.
Exemple
Une fois votre fichier sauvegardé, vous devez l'ajouter dans la liste des taggers du Synchronizer concerné ( par exemple /etc/shinken/synchronizers/synchronizer-master.cfg )
| Code Block |
|---|
define synchronizer {
[ ... ]
# Taggers:
# ip-tags
# regexp-tags
taggers ip-tags, regexp-tags, my-new-tagger
[ ... ]
} |
Pour que les modifications soient prises en compte, vous devez ensuite redémarrer le Synchronizer.
Si votre configuration est correcte, vous devriez retrouver votre tagger en bas de page de l'interface de configuration :
| Panel |
|---|
|
Cas des champs address des hôtes qui sont des noms DNS
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'ip est dans le range 192.168.0.1/24le nom commence par bdx
Exemple 1 : mettre
la valeurle nom du royaume directement dans la
valeur dupropriété définissant le royaume
Si nous savons que les serveurs dans le range IP 192.168.0.1/24 sont les éléments dont le nom commence par la chaine bdx, sont situés à Bordeaux, il est intéressant pertinent de le 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 ).
Nous pouvons donc définir le module suivant que nous accrochons 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_regexp_tag suivant permet ce comportement :
- SI la propriété host_name ( le nom ) SI l'ip correspondant au champ address de l'hôte/cluster est dans le range 192.168.0.0/24 commence par bdx
- ALORS, on va écraser ( paramètre
method=à la valeur "set") le champ la propriété realm ( paramètre "property") avec la valeur Bordeaux ( paramètre "value"
- ALORS, on va écraser ( paramètre
| Code Block | ||||
|---|---|---|---|---|
| ||||
define module{
module_name ipsync-regexp-tag-bordeaux-basic
module_type sync_ip_-regexp-tag
# La rangeregexp IP de l'hote (champ address)a appliquer
ipmatched_rangeregexp 192.168.0.0/24^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 | ||
|---|---|---|
| ||
À noter que cette méthode est facile à appréhender, mais n'est pas une bonne pratique sur le long terme :
La bonne pratique est de définir un modèle d'hôte et de l'accrocher systématiquement aux équipements de ce datacenter.
|
Exemple 2: plus flexible, rajouter un modèle "bordeaux"
(, prioritaire sur les 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
- ( 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_tagpour 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.
Nous pouvons donc définir le module suivant que nous accrochons au tagger ( comme indiqué au dessus ).
Il va:
Le module de type sync_regexp_tag suivant permet ce comportement :
- SI la propriété host_name ( le nom ) SI l'ip correspondant au champ address de l'hôte/cluster est dans le range 192.168.0.0/24
commence par bdx- ALORS, on va 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 ALORS on va rajouter au début ( paramètre
| Code Block | ||||
|---|---|---|---|---|
| ||||
define module{
module_name ip sync-regexp-tag-bordeaux-advanced
module_type sync_ip_-regexp-tag
# La rangeregexp IP de l'hote (champ address)a appliquer
ipmatched_rangeregexp 192.168.0.0/24^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.
| Panel |
|---|
|
- Ces liens redirigent sur leurs configurations.
| Panel |
|---|
|
- Un onglet
Vous pouvez 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-tags.
- permet de visualiser également un résumé des règles qui vont s'appliquer.
| Panel |
|---|
 |