Qu'est-ce qu'une règle d'application des modèles ?

Une règle d'application des modèles permet de définir une ou plusieurs condition(s), permettant à la source d'attribuer un modèle à un hôte en fonction de la valeur d'un champ de l'API VMWare.

La source dispose de quelques règles d'application fournies par défaut, mais il vous est possible de :

  • créer vos propres règles d'application ;
  • de désactiver les règles par défaut ;

Définition d'une règle

Une règle d'application est écrite au format JSON ( clé <-> valeur ):

clécommentaire


name


Nom de la règle

  1. doit être unique dans le JSON



template


Nom du ou des modèle(s) qui seront attachés.

Les modèles peuvent être listés en les séparant par une virgule.


conditionX


Défini une condition d'application de la règle :

  • X étant le numéro de la condition.
  • Les conditions sont interprétées dans l'ordre.
  • Entre chaque condition, il s'agit d'un OU ce qui signifie qu'une règle vraie suffit pour appliquer la règle.


disable


  • Deux valeurs possibles ( Par défaut, la valeur est false ) :
    • true : la règle est désactivée, le modèle définit dans la règle ne sera pas appliqué.
    • false : la règle est activée.

Non obligatoire

(info) La valeur de la clé ne prends pas en compte les majuscules, false et False sont pareils.


Exemple

[
  {
    "name" : "rule 32 bit generation",
    "template" 	: "x86,32-bit",
    "condition1" : "config.product.osType=86",
	"disable" : "true"
  },
  {
    "name" : "windows Server 64bits",
    "template" : "windows_server,64-bit,x64",
    "condition1" : "config.product.osType=64 AND config.guestFullName=windows server",
    "condition2" : "config.product.osType=64 AND config.guestFullName=^Microsoft Server$",
	"condition3" : "config.product.osType=64 AND config.guestFullName=vista server"
  }
]

Dans l'exemple, nous pouvons voir qu'il y a deux règles qui sont définies.

  • Ici la première règle nommée "rule 32 bit generation" possède une condition sur le type du système, si cette condition est respectée alors les modèles "x86" et "32-bit" seront appliqués à l'élément crée via la source.
  • La seconde règle nommée "windows Server 64bits", fonctionne de la même manière que la première, mais avec plus de conditions.

Les Commentaires

Il est possible d'ajouter des commentaires dans ce fichier. 

Toutes les lignes qui commencent par le caractère # seront considérées comme des commentaires.

Syntaxe d'une condition d'une règle d'application

Une condition est séparée en 2 parties et utilise le caractère "=" comme symbole séparateur :

  • à gauche, le champ de l'API VMWare qui va être inspecté ;
  • à droite, la condition sur la valeur du champ de l'API à remplir ;


Cette valeur ne prend pas en compte les majuscules, ce qui fait que WINDOWS et windows sont pareils


Dans cet exemple pour que les modèles soient ajoutés, il faut que le nom de l'OS (système d'exploitation) contienne le texte "myOS".


Voici les syntaxes possibles pour les conditions des règles d'application des modèles :

SignificationSyntaxeDescriptionExemple
ContientNOM_DE_CHAMP=texteLa condition signifie que le champ VMWare choisi doit CONTENIR le texte.

os=myOS

Commence parNOM_DE_CHAMP=^texteSi l'expression commence par le caractère "^", la condition signifie que le résultat attendu doit COMMENCER par le texte

macvendor=^myMacVendor

Termine parNOM_DE_CHAMP=texte$Si l'expression termine par le caractère "$" la condition signifie que le résultat attendu doit TERMINER par le texte.

ostype=myType$

Est strictement égal NOM_DE_CHAMP=^texte$Si l'expression commence par "^" ET termine par "$", la condition signifie que le résultat attendu doit être l'expression EXACTE

osversion=^2.6.0$

Une condition
et l'autre sont remplies		Condition1 AND Condition2Le modèle sera appliqué si la condition 1 et 2 sont rempliesos=myOS AND osversion=^2


Note : c'est le 1er '=' qui sépare le nom du champ et le texte. 

config.guestFullName est le nom du champ VMWare

linus=(Ubuntu) est le texte recherché



Au lieu de supprimer une ligne, il est possible de la rendre inutile en la commentant grâce au signe "#".


Surcharge des règles par défaut

Les règles par défaut peuvent être surchargées en créant une règle avec le même nom.

Le modèle ajouté pour la règle set template for virtual machines sera maintenant vmware virtual host


Noter qu'une surcharge ne possédant pas au minimum un nom et un modèle ne sera pas prise en compte




[
  {
    "name" : "set template for virtual machines",
	"template" : "vmware virtual host"
  }
]


Il est possible de désactiver les règles par défaut en créant une règle avec le même nom et la clé disable à true.
( dans ce cas, le modèle n'est pas nécessaire )


[
  {
    "name" : "set template for virtual machines",
	"disable" : "true"
  }
]


Lors d'une surcharge, si les clés template ou condition ne sont pas spécifiés, les valeurs par défaut de celle-ci sont récupérées si la règle est activée. 

Exemple avec la règle set template for virtual machines définies à droite :


[
  {
    "name" : "set template for virtual machines",
	"template" : "vmware virtual host",
	"disable" : "false"
  }
]


Avant surcharge de la règle set template for virtual machines


Après surcharge de la règle set template for virtual machines


Chemin du fichier de définition des règles d'application

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/host_template_binding/host_template_binding_rule.json


/etc/shinken-user/source-data/source-data-synchronizer-collector-vmware/configuration/host_template_binding/host_template_binding_rule.json



Retrouvez la liste complète des champs collectés par la source sur la page Liste complète des champs collectés auprès des VCenters ou ESXs


Visualiser les règles d'application ( Onglet "Règles d'application des modèles" )

Pour visualiser la liste des règles définies pour cette source, rendez-vous dans l'onglet "Règles d'application des modèles". 

Dans cet onglet, vous trouverez le chemin du fichier de définition des règles d'application des modèles utilisateur ( 1 ).

  • (warning) Un message d'avertissement apparaîtra si le fichier n'existe pas. Pour résoudre ce problème, créer le fichier avec le chemin indiqué sur l'interface puis appuyer le bouton de rafraîchissement ( 2 ).
    Si le fichier de définition est vide alors les valeurs par défaut seront utilisées. 
  • (warning) Si une règle est désactivée, les erreurs sur là cette règle ne seront pas affichées.

Dans l'en-tête, vous trouverez aussi le bouton de rafraîchissement de la liste des règles ( 2 ).

  • Ce bouton permet de rafraîchir cette liste sans devoir redémarrer le Synchronizer.
  • Il faudra relancer un import pour réappliquer les nouvelles règles sur les éléments importés.

La liste des règles ( 3 ) comporte à la fois les règles définies par l'utilisateur et les règles par défaut.
La liste affiche pour chaque règle : 

  • Le type de la règle ( Utilisateur, par défaut ou désactivé par l'utilisateur )
  • Le numéro qui correspond à l'ordre d'application de la règle.
  • Le nom de la règle
  • La condition
  • Les modèles qui seront appliqués



En bas à droite ( 4 ) se trouve le bouton pour afficher l'aide de la page.

Cette page d'aide explique le fonctionnement de l'onglet et peut être ouverte en appuyant sur la touche F1.

En utilisant la syntaxe de définition des règles, vous pourrez définir vos propres règles ou surcharger celles existantes par défaut. 

  • Les règles utilisateur apparaîtront en bleu dans la liste.
  • Les règles désactivées apparaîtront en gris ( 5 ).

Avant


Après


Si un champ obligatoire est manquant ou erroné, un Avertissement ou une Erreur apparaîtra sur la règle en question.