Ces règles permettent, lors de l'import, de mettre en relation un champ de l'API VMware avec une propriété ou une donnée de Shinken en fonction du type de l'élément ( hôte, modèle d'hôte, etc. ).
Elles peuvent être visualisées depuis l'onglet "Mapping vers les propriétés et les données de Shinken" de l'interface de la source.
|
Pour ajouter une règle utilisateur d'application des modèles, il faut éditer le chemin suivant :
/etc/shinken-user/source-data/source-data-[nom de la source]/configuration/mapping/user_mapping_rules_vm.json /etc/shinken-user/source-data/source-data-[nom de la source]/configuration/mapping/user_mapping_rules_esx.json |
/etc/shinken-user/source-data/source-data-synchronizer-collector-vmware/configuration/mapping/user_mapping_rules_vm.json |
Comme pour les règles d'application des modèles, les règles de mapping sont écrites au format JSON.
La source VMware ne concerne que les hôtes, donc les fichiers sources commenceront toujours par "hosts".
Elles doivent respecter le format suivant :
Une propriété est une information nécessaire au moteur Shinken.
|
Une donnée est une valeur qui va être ajoutée en complément des propriétés.
|
Il est possible d’ajouter le suffixe [FORCE] ( sans espace ) à la clé d’import d'un élément Shinken afin de forcer la valeur associée ( voir la page Forcer la valeur des noms des éléments et des propriétés de type liste (comme la propriété des modèles hérités) ).
Exemple :
{
"hosts": {
"name": "host_name[FORCE]",
"shinken.ipAddress" : "address"
}
} |
Lorsqu’une propriété est marquée avec [FORCE], elle est traitée de la manière suivante par le mélange des sources :
Ajouter [FORCE] à une clé d'import contenant une liste ( comme la propriété "members" servant à définir les membres d'un groupe d'utilisateurs ) aura pour effet de remplacer complètement la liste des autres sources par celle fournie avec l'option [FORCE].
{
"hosts": {
"name": "host_name",
"shinken.ipAddress" : "address",
"shinken.machine_type": "DATA(MACHINE_TYPE)",
"config.product.osType": "DATA(OS_TYPE)",
"shinken.tags": "DATA(TAGS)"
}
} |
Il existe 5 règles de mapping définies :
| Clé VMware | Clé Shinken | Description du mapping |
|---|---|---|
| name | host_name | La valeur VMware "name" deviendra le nom de l'hôte ( propriété host_name ). |
| shinken.ipAddress | address | La valeur VMware "shinken.ipAddress" sera prise en compte comme adresse pour l'hôte ( propriété address ). |
| shinken.machine_type | DATA(MACHINE_TYPE) | La valeur VMware "shinken.machine_type" deviendra une donnée nommée MACHINE_TYPE sur l'hôte. |
| config.product.osType | DATA(OS_TYPE) | La valeur VMware "config.product.osType" deviendra une donnée nommée OS_TYPE sur l'hôte. |
| shinken.tags | DATA(TAGS) | La valeur VMware "shinken.tags" deviendra une donnée nommée TAGS sur l'hôte. Vu que la valeur de shinken.tags est une liste dans l'API de VMware, la valeur de la donnée TAGS vaudra la liste des tags séparés par des virgules. Exemple : La valeur de shinken.tags ['Linux','Bordeaux','France'] deviendra la valeur Linux,Bordeaux,France dans TAGS. |
|
Les opérateurs des règles de mapping permettent de transformer les données collectées afin de les adapter au format de Shinken et aux besoins de la supervision.
La source VMware peut fournir des champs dont les valeurs sont des listes ( par exemple le champ "shinken.tags" ).
Pour faire correspondre une valeur de liste dans un champ de Shinken, il est possible d'utiliser l'opérateur : "VALUES".
Une VM possède la liste de tags suivants : LINUX, FR, DATACENTER_42 Le mapping suivant :
va permettre de créer un hôte avec comme données :
|
La syntaxe de la condition dans "VALUES(condition)" est la suivante :
| Signification | Syntaxe | Description | Exemple |
|---|---|---|---|
| Index | nombre | Récupère l'élément à l'index indiqué. L’index doit être un nombre appartenant à l’ensemble des entiers naturels, incluant 0. Cette règle admet une seule exception afin de rendre possible le choix du dernier élément d’une liste, en utilisant l’index -1. L’index 0 récupérera le premier élément de la liste, 1 le deuxième, 2 le troisième, etc. |
|
| Contient | = texte | La condition signifie que l'élément choisi doit CONTENIR le texte. |
|
| Commence par | =^ texte | Si l'expression commence par le caractère "^", la condition signifie que l'élément choisi doit COMMENCER par le texte. |
|
| Termine par | = texte $ | Si l'expression se termine par le caractère "$", la condition signifie que l'élément choisi doit TERMINER par le texte. |
|
| Est strictement égal | = ^ texte $ | Si l'expression commence par "^" ET se termine par "$", la condition signifie que l'élément choisi doit être l'expression EXACTE. |
|
| Inversion | = !^ texte $ | Ajouter un " ! " avant une autre expression provoque l'effet inverse de celle-ci : • = ! texte --> L'élément choisi ne contient pas "texte" • = ! ^ texte --> L'élément choisi ne commence pas par "texte" • = ! texte $ --> L'élément choisi ne se termine pas par "texte" • = !^ texte $ --> L'élément choisi n'est pas strictement égal à "texte" |
|
|
L'opérateur TRANSFORM permet de modifier la valeur d'un champ VMware lors du mapping.
Son utilisation se fait avec la syntaxe suivante : champ_vmware>TRANSFORM(valeur_initiale=>nouvelle_valeur)
Une VM possède la donnée "config.product.osType" avec la valeur "linuxGuest". On souhaite que dans Shinken, cette donnée vaille "Linux". Le mapping suivant :
va permettre de créer un hôte avec comme donnée : |
|
L'opérateur CONCAT permet de fusionner plusieurs champs VMware ou du texte fixe dans une seule propriété ou donnée Shinken.
Syntaxe : CONCAT(champ1, " texte ", champ2)
Il est possible de surcharger les règles de mapping définies par défaut par l'application ( ex : le nom de l'hôte, son adresse IP, etc. ).
Pour cela, il suffit de créer, dans l'un des fichiers de mapping utilisateur ( 1 ), une règle possédant la même clé que celle à surcharger ( 5 ).
Avant :
|
Après :