Page History

Concept général

Shinken Entreprise permet d'effectuer des remplacements dynamiques de contenu dans les objets de configuration ( autrefois appelé "MACRO" ). Ces remplacements sont utilisés pour permettre une factorisation de la configuration, ainsi que pour fournir une grande flexibilité dans la création et modification d'une configuration de supervision.

Un exemple pour illustration :

On dispose d'une commande qui se charge de contacter un hôte pour déterminer si il est joignable ou non.

On veut donc que la commande récupère automatiquement l'adresse de l'hôte sans avoir à spécifier manuellement l'adresse pour chaque hôte.

Pour résoudre ce problème, on effectue un remplacement de contenu. Dans Shinken Entreprise, on peut utiliser la notation $HOSTADDRESS$ qui va contenir l'adresse de l'hôte courant.

Ainsi, en utilisant cette notation dans notre commande, lorsque celle-ci sera utilisée lors de la vérification d'un hôte, le mécanisme de remplacement dynamique va automatiquement remplacer la notation par l'adresse de l'hôte .

check_ping -H "$HOSTADDRESS$" (...autres paramètres)

check_ping -H "192.168.1.12" (...autres paramètres)

 Les différents types de contenu

Dans l'exemple précédent, la notation entre dollars ( $ ) est utilisée pour permettre le remplacement dynamique d'une donnée locale à l'hôte dans une commande.

Il s'agit seulement d'un exemple parmi les différents types de contenus existantexistan t. Ces contenus peuvent être séparés en 3 grandes catégories:

• Les données locales
• Les globales
• Les opérateurs, permettant un transfert de données

Les Variables vers les données et propriétés d'un élément

Les données locales désignent les données personnalisées et les propriétés d'un objet particulier.

Accès aux propriétés d'un élément

Parmi tous les éléments de Shinken Entreprise, il est possible d'accéder aux attributs des hôtes, des checks et des utilisateurs.

Dans le premier exemple, la notation entre dollars permet d'accéder à une propriété de l'hôte, par exemple l'adresse: $HOSTADDRESS$. 

On accède ici à la propriété "address" de l'objet HOST. On peut accéder aux autres attributs de l'hôte, mais aussi à ceux d'un check ou d'un utilisateur.

Il est donc possible d'accéder aux propriétés des hôtes, des checks ou bien des utilisateurs. Pour cela, il faut commencer le nom de la Variable par Variable par HOST, SERVICE ( pour les checks ) ou CONTACT ( pour les utilisateurs ).

Par exemple:

• $HOSTADDRESS$
• $SERVICEDISPLAYNAME$
• $CONTACTEMAIL$

Le schéma ci-dessus explique le cas du remplacement des données locales pour les checks et les hôtes.

Dans le cas des utilisateurs, plusieurs utilisateurs peuvent être accrochés sur un hôte ou un check. Ils sont utilisés pour envoyer les notifications lorsque l'hôte ou le check passe dans un état d'erreur.

Dans ce cas, une notification est envoyée à chaque utilisateur. La commande utilisée pour envoyer la notification peut alors utiliser un remplacement dynamique de contenu pour accéder aux informations de l'utilisateur qui va recevoir la notification.

Accès aux données personnalisées d'un élément

Shinken Entreprise permet d'ajouter des données personnalisées sur certains éléments, comme les hôtes, les checks, les utilisateurs, et bien sûr les modèles d'hôtes, de checks et d'utilisateurs. Ces données permettent des créés des propriétés personnalisées lorsque les propriétés par défaut de l'objet ne suffisent pas à le décrire complètement.

Par exemple, si un hôte possède deux interfaces réseau, les propriétés par défaut de l'objet ne permettent pas de spécifier deux adresses. Par contre, il est possible d'ajouter une donnée personnalisée qu'on appelle par exemple "ADDRESS_2" qui pourra être utilisée lorsqu'on aura besoin d'avoir la deuxième adresse de l'hôte dans un check.

Ces données sont accessibles dans un objet en utilisant la notation suivante :

• $_HOSTNOMDELADONNEPERSONNALISEE$.
• $_SERVICENOMDELADONNEPERSONNALISEE$
• $_CONTACTNOMDELADONNEPERSONNALISEE$

Les Variables dites "globale"

Il est possible en effectuant un remplacement de contenu d'accéder aux données locales à un hôte, un check ou un utilisateur. Il est aussi possible dans Shinken Entreprise de définir des globales accessibles partout dans Shinken et qui ne dépendent pas d'un élément particulier.

Ces globales se définissent dans des fichiers de configuration, dont le détail sera expliqué dans la section qui traite l'utilisation pratique des remplacements dynamiques de contenu. Elles sont accessibles simplement par leur nom, sans avoir besoin de le préfixer de _HOST, _SERVICE ou _CONTACT.

Par exemple, une globale nommée MAGLOBALE sera accessible avec la notation $MAGLOBALE$.

Opérateurs

Nous avons vu que lorsque l'on remplace dynamiquement du contenu, il est possible de faire référence aux données locales ainsi qu'aux globales. Il existe également des opérateurs spéciaux, qui ne récupèrent pas les globales et les données locales d'un élément, mais qui permettent de transférer des données, notamment des arguments de commande.

Ces opérateurs spéciaux sont accessibles avec les notations $ARGn$ et $VALUEn$.

Référence aux arguments d'une commande

Shinken Entreprise permet aux hôtes et aux checks de spécifier des commandes qui seront utilisées pour la vérification de l'élément. Dans l'optique de rendre ces commandes les plus génériques possible, et de permettre de factoriser la configuration, des arguments peuvent être passés à ces commandes.

Ces arguments sont séparés par des points d'exclamation '!'.

Dans l'exemple, un check utilise la commande "ma_commande" et lui passe 3 arguments.

Dans la commande, on veut donc pouvoir récupérer la valeur des ces arguments pour pouvoir les utiliser dans le script.

Les notations $ARGn$ sont donc utilisées dans ce cas. La notation $ARGn$ permet simplement d'accéder à la valeur du n-ième argument.

Dans l'exemple, on utilise donc $ARG1$, $ARG2$ et $ARG3$ pour récupérer les valeurs du premier, deuxième et troisième argument.

Cas du Duplicate Foreach

La fonctionnalité avancée Dupliquer pour chaque valeur de la Donnée de l'hôte permet d'appliquer plusieurs fois le même check sur un hôte avec des paramètres différents, selon la valeur d'une donnée personnalisée sur l'hôte.

Sur chaque check utilisant la fonctionnalité Duplicate Foreach, est affecté une clé, et optionnellement des paramètres.

check1$(valeur1)$$(valeur2)$$(valeur3)$

La valeur de la clé est accessible avec la notation $KEY$, et les arguments sont accessible grâce aux notations $VALUEn$.

Le tableau suivant récapitule les notations permettant d’accéder aux valeurs de la donnée Duplicate Foreach:

Utilisation pratique des remplacements dynamiques de données

Les données locales

Définir des données personnalisées

Les données locales peuvent être définies sur les hôtes, checks, utilisateurs et leurs modèles respectifs de 2 manières:

• Par fichier de configuration
• Par l'interface de configuration

Dans un fichier de configuration, les données sont définies en préfixant un _ à leur nom. Le nom d'une donnée peut contenir seulement des caractères alphanumériques ( A-Z0-9 ), des tirets ( - )  ou ou underscore ( _ ). Aussi, le nom d'une donnée sera toujours en majuscules.

define host {
    host_name    mon_hote
    address		 192.168.0.12


    _DONNEE_PERSONNALISEE      valeur_de_la_donnée
}

Dans l'interface de configuration, l'ajout et la modification de données personnalisées s'effectuent grâce à l'onglet "Données".

Cette capture d'écran montre l'édition de données personnalisées dans le cas d'un hôte. Les mêmes manipulations sur les données personnalisées sont possibles pour les modèles d'hôtes, clusters, modèles de clusters, checks, modèles de check, utilisateurs et modèles d'utilisateurs.

Utiliser des données locales

Lorsqu'on veut accéder à des données locales, il faut différencier l'utilisation de la notation entre dollars ($) donnant accès aux données personnalisées et celles permettant l'accès à certains attributs de l'élément.

La liste des propriétés disponibles pour chaque élément ( hôtes, check checks et utilisateurs ) est présente dans la section section Propriétés accessibles dans les remplacements de contenu

Les globales

Définir des données globales

Les données globales peuvent être définies uniquement par fichiers de configuration.

Par défaut, un certain de nombre de globales sont définies dans le dossier /etc/shinken/resource.d, dans lequel sont présents tous les fichiers qui déclarent des globales. Au démarrage de Shinken, ces fichiers sont donc chargés et les globales qui y sont définies sont alors disponibles.

La syntaxe pour la déclaration des globales est la suivante:

# Commentaire: les lignes commencant par # seront ignorées
# Les noms de globales doivent être entourés de $


$NOMDELAGLOBALE$=valeur

Comme pour les données locales, les noms de globaux ne peuvent contenir que des caractères alphanumériques (A-Z0-9), des tirets (-) et des underscore (_). Comme pour les données locales, le nom d'une globale sera toujours en majuscules.

Pour permettre à l'utilisateur de faire ses propres packs et faciliter l'import d'une configuration externe, il est possible de déclarer des globales dans une source. Pour cela, il faut placer les fichiers .cfg dans un dossier source_data de la source.

Les fichiers de déclaration de globaux seront donc copiés dans /etc/shinken/resource.d/ et disponibles comme les autres globales.

Utiliser des données globales

Les globales sont accessibles en spécifiant seulement le nom de la globale entourée par des dollars ($).

La globale "MAGLOBALE" est donc accessible par la notation $MAGLOBALE$.

Remarques sur la notation entre dollars ($)

Propriétés accessibles dans les remplacements de contenu

Propriétés des hôtes

Propriétés des checks

Propriétés des utilisateurs

Globales prédéfinies

Certaines globales présentes ci-dessous sont définies par Shinken et accessibles comme n'importe quelle autre globale.

Limites lors de l'évaluation des variables dynamiques pour générer une ligne de commande

Il peut arriver que le résultat de certaines variables dynamiques nécessite l'évaluation d'autres variables dynamiques pour être obtenu.

Pour éviter tout emballement récursif ( exemple: VARIABLE_1  nécessite VARIABLE_2  qui nécessite VARIABLE_3 qui nécessite VARIABLE_1 ), les limites suivantes sont appliquées lors de la résolution des variables dynamiques :

• il ne peut pas y avoir plus de 32 niveaux d'imbrication de variables, au delà de ce niveau, les variables ne sont plus résolues
• il ne peut pas y avoir plus de 255 variables à résoudre sur la ligne de commande, au delà de ce nombre, les variables ne sont plus résolues
• la ligne de commande générée après résolution des variables dynamiques ne peut pas excéder 65000 caractères.

Si un dépassement se produit, la résolution des variables est interrompue, et la ligne de commande est tronquée pour être remplacée par une commande remontant cette information.

Différences de comportement entre le Synchronizer (configuration) et le Scheduler (production)

Certaines données n'étant disponibles qu'en production, le Synchronizer se contente de simuler leur existence lors des essais de check ( exemple: $HOSTPERFDATA$,  $SERVICEPERFDATA$ ... )

En conséquence, certaines problématiques que l'ont peut rencontrer en production ne peuvent pas être testées ou observées depuis l'essai de check, , comme par exemple une variable dynamique qui se substitue par une multitude de variables dynamiques. 

En particulier, pendant les résolutions des variables dynamiques la différence suivante peut être observée :

• le Scheduler, en production, gère le nombre de variables dynamiques présentes sur la ligne de commande, à chaque étape de substitution
• le Synchronizer, lors de l'essai de check, ne gère pas le nombre de variables présentes sur la ligne de commande lors des substitutions, et il n'applique pas la règle limitant leur nombre à 255 à chaque étape de substitution.