Concept général
Les différents types de
macroscontenu
Dans l'exemple précédent, une macro 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 des parmi les différents types de macros existantescontenus existant. Ces macros contenus peuvent être séparées séparés en 3 grandes catégories:
- Les macros permettant un accès aux données locales
- Les macros permettant un accès aux données globales
- Les macros spécifiquesopérateurs, permettant un transfert de transférer les données
Les données locales
Les macros concernant les données locales permettent de faire référence à une donnée ou un attribut données locales désignent les données personnalisées et les propriétés d'un objet particulier. Ces données locales peuvent être des attributs d'un élément, ou bien des données personnalisées.
Accès aux
attributspropriétés d'un élément
Les macros concernant les données locales permettent d'accéder aux attributs 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.
Ce type de macro est déjà présent dans le premier exempleDans le premier exemple, la notation entre dollars permet d'accéder à un propriété de l'hôte, par exemple l'adresse: $HOSTADDRESS$.
On accède ici à l'attribut la propriété "address" de l'objet HOST. On peut accéder aux autres attributs de l'hôte, mais aussi à ceux du checkd'un check ou d'un utilisateur.
| Panel | ||
|---|---|---|
| ||
| ||
Il est donc possible Les macros permettent d'accéder aux attributs propriétés des hôtes, des checks ou bien des contactsutilisateurs. Pour cela, il faut commencer le nom de la macro 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 les macros 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 sur les modèles d'hôtes, de checks et d'utilisateurs. Ces données permettent des créer des attributs personnalisés propriétés personnalisées lorsque les attributs par 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 2 interfaces réseau, les attributs propriétés par défaut de l'objet ne permettent pas de spécifier 2 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 une macro de la manière un objet en utilisant la notation suivante:
- $_HOSTnomdeladonnéepersonnalisée$HOSTNOMDELADONNEPERSONNALISEE$.
- $_SERVICEnomdeladonnéepersonnalisée$SERVICENOMDELADONNEPERSONNALISEE$
- $_CONTACTnomdeladonnéepersonnalisée$CONTACTNOMDELADONNEPERSONNALISEE$
| Info | ||
|---|---|---|
| ||
On remarque la présence d'un underscore (_) avant HOST, SERVICE ou CONTACT, ce qui permet de différencier l'accès à un attribut une propriété de l'élément et l'accès à une donnée personnalisée. |
| Panel | ||
|---|---|---|
| ||
Les
donnéesglobales
Les macros permettent 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 données globales accessibles partout dans Shinken et qui ne dépendent pas d'un élément particulier.
Ces données globales se définissent dans des fichiers de configuration, dont le détail sera expliqué dans la section qui traite l'utilisation pratique des macrosremplacements 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 macro notation $MAGLOBALE$.
| Panel | ||
|---|---|---|
| ||
Opérateurs
Nous avons vu que les macros permettent lorsque l'on remplace dynamiquement du contenu, il est possible de faire référence aux données locales ainsi qu'aux données globales. Il existe également des macros particulièresopérateurs spéciaux, qui ne récupèrent pas les données globales et les données spécifiques locales d'un hôte élément mais qui permettent de transferer transférer des données, notamment des arguments de commande.
C'est le cas des macros Ces opérateurs spéciaux sont accessibles avec les notations $ARGn$ et $VALUEn$.
Référence aux arguments d'un 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.
| Panel |
|---|
Dans la commande, on veut donc pouvoir récupérer la valeur des ces arguments pour pouvoir les utiliser dans le script.
Les macros notations $ARGn$ sont donc utilisées dans ce cas. La macro 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.
| Panel |
|---|
| Panel | ||
|---|---|---|
| ||
| Info |
|---|
Comme dans Nagios, il est possible d'utiliser jusqu'a 32 arguments. Ainsi, les macros notations $ARG1$ à $ARG32$ sont utilisables. |
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.
| Code Block | ||
|---|---|---|
| ||
check1$(valeur1)$$(valeur2)$$(valeur3)$ |
La valeur de la clé est accessible avec la macro notation $KEY$, et les arguments sont accessible grâce aux macros notations $VALUEn$.
Le tableau suivant récapitule les macros notations permettant d'acceder d’accéder aux valeurs de la donnée Duplicate Foreach:
| Macro | Valeur |
|---|---|
| $KEY$ | check1 |
| $VALUE1$ | valeur1 |
| $VALUE2$ | valeur2 |
| $VALUE3$ | valeur3 |
| Panel | ||
|---|---|---|
| ||
| Info |
|---|
Il possible d'utiliser 16 valeurs différentes. Ainsi, les notations $VALUE1$ jusqu’à $VALUE16$ sont valides. |
Utilisation pratique des
macrosremplacements 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 underscore (_). Aussi, le nom d'une donnée sera toujours en majuscules.
| Code Block | ||
|---|---|---|
| ||
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'effectue grâce à l'onglet "Données".
| Panel | ||
|---|---|---|
| ||
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, 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 macros donnant accès aux données personnalisées et celles permettant l'accès à certains attributs de l'élément.
| title | Attributs de l'élément |
|---|
TODO: Référence vers la liste des macros qui existent
| Info |
|---|
Dans un fichier de configuration, une donnée personnalisée est définie précédée d'un underscore (_). Dans l'interface de configuration, cet underscore ne doit pas être spécifié car il s'agit seulement d'un moyen dans les fichiers de différencier une donnée personnalisée d'une propriété. La déclaration d'une donnée personnalisée depuis l'interface se fait seulement en spécifiant le nom de la donnée et sa valeur. |
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.
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
|
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
|
La liste des propriétés disponibles pour chaque élément (hôtes, check et utilisateurs) est présente dans la 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:
| Code Block | ||
|---|---|---|
| ||
# 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 globales 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 globales 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 global "MAGLOBALE" est donc accessible par la notation $MAGLOBALE$.
| Note |
|---|
Parce que les globales sont définies dans les fichiers de configuration, un ajout ou modification d'une globale dans ces fichiers nécessite un redémarrage de Shinken Entreprise pour que les modifications soient prises en compte. |
Remarques sur la notation entre dollars ($)
| Info |
|---|
Quelle que soit l'utilisation d'une valeur entre dollars, cette valeur doit toujours être en majuscule. Si à l'import des fichiers CFG ou lors de la modification sur l'interface de configuration, une valeur entre dollars comporte des minuscules, celles-ci seront converties en majuscules et un avertissement sera affiché. |
| Info | ||
|---|---|---|
| ||
Il est possible, lors de la définition d'une donnée personnalisée, de référencer une autre valeur accessible par une notation entre dollars. |
| Panel |
|---|
Propriétés accessibles dans les remplacements de contenu
| Anchor | ||||
|---|---|---|---|---|
|
Propriétés des hôtes
| Syntaxe | Description |
|---|---|
$HOSTNAME$ | Nom de l'hôte (propriété host_name) |
$HOSTDISPLAYNAME$ | Nom d'affichage de l'hôte (propriété display_name) |
$HOSTADDRESS$ | Adresse de l'hôte (propriété address) |
$HOSTSTATE$ | Etat courant de l'hôte (UP, DOWN, ou UNREACHABLE) |
| $HOSTSTATETYPE$ | Type d'état permettant la confirmation du statut d'un hôte (SOFT ou HARD) |
$HOSTSTATEID$ | Numéro correspondant à l'état courant de l'hôte (0=UP, 1=DOWN, ou 2=UNREACHABLE) |
$LASTHOSTSTATE$ | Etat précédent de l'hôte (UP, DOWN, ou UNREACHABLE) |
$LASTHOSTSTATEID$ | Numéro correspondant à l'état précédent de l'hôte (0=UP, 1=DOWN, ou 2=UNREACHABLE) |
$HOSTGROUPNAME$ | Nom du groupe d'hôte auquel appartient l'hôte. Si il appartient à plusieurs groupes d'hôtes, un seul sera retourné |
$HOSTGROUPNAMES$ | Liste des groupes d'hôtes auxquels appartient l'hôte, séparés par des virgules |
$LASTHOSTCHECK$ | Date au format timestamp de la dernière vérification de l'hôte |
$LASTHOSTSTATECHANGE$ | Date au format timestamp du dernier changement d'état de l'hôte |
$LASTHOSTUP$ | Date au format timestamp du dernier état UP de l'hôte |
$LASTHOSTDOWN$ | Date au format timestamp du dernier état DOWN de l'hôte |
$LASTHOSTUNREACHABLE$ | Date au format timestamp du dernier état UNREACHABLE de l'hôte |
$HOSTOUTPUT$ | Résultat de la dernière vérification de l'hôte |
$LONGHOSTOUTPUT$ | Résultat long de la dernière vérification de l'hôte |
$HOSTPERFDATA$ | Données de performances renvoyées par la dernière vérification de l'hôte |
$HOSTCHECKCOMMAND$ | Nom de la commande utilisée pour la vérification de l'hôte (avec les paramètres) |
$HOSTNOTESURL$ | URL externe de l'hôte (propriété notes_url) |
$HOSTBUSINESSIMPACT$ | Nombre entre 0 et 5 indiquant l'impact métier de l'hôte |
| Note |
|---|
On accède en général aux propriétés de l'hôte avec la notation entre dollars commençant par HOST (ex $HOSTADDRESS$). Dans le tableau, certaines entrées ne commencent pas par HOST sont présentes, mais font quand même référence à une propriété de l'hôte. |
Propriétés des checks
| Syntaxe | Description |
|---|---|
$SERVICEDESC$ | Nom/description du check |
$SERVICEDISPLAYNAME$ | Nom d'affichage du check (propriété display_name) |
$SERVICESTATE$ | Etat courant du check (OK, WARNING, UNKNOWN, CRITICAL) |
| $SERVICESTATETYPE$ | Type d'état permettant la confirmation du statut d'un check (SOFT ou HARD) |
$SERVICESTATEID$ | Numéro correspondant à l'état courant du check (0=UP, 1=DOWN, ou 2=UNREACHABLE) |
$LASTSERVICESTATE$ | Etat précédent du check (OK, WARNING, UNKNOWN, CRITICAL) |
$LASTSERVICESTATEID$ | Numéro correspondant à l'état précédent du check (0=UP, 1=DOWN, ou 2=UNREACHABLE) |
$SERVICEISVOLATILE$ | Booléen indiquant si le check est volatile (0=Non volatile, 1=Volatile) |
$LASTSERVICECHECK$ | Date au format timestamp de la dernière exécution du check |
$LASTSERVICESTATECHANGE$ | Date au format timestamp du dernier changement d'état du check |
$LASTSERVICEOK$ | Date au format timestamp du dernier état OK du check |
$LASTSERVICEWARNING$ | Date au format timestamp du dernier état WARNING du check |
$LASTSERVICEUNKNOWN$ | Date au format timestamp du dernier état UNKNOWN du check |
$LASTSERVICECRITICAL$ | Date au format timestamp du dernier état CRITICAL du check |
$SERVICEOUTPUT$ | Résultat de la dernière vérification du check |
$LONGSERVICEOUTPUT$ | Résultat long de la dernière vérification du check |
$SERVICEPERFDATA$ | Données de performances renvoyées par la dernière exécution du check |
$SERVICECHECKCOMMAND$ | Nom de la commande utilisée pour l'exécution du check (avec les paramètres) |
$SERVICENOTESURL$ | URL externe du check (propriété notes_url) |
$SERVICEBUSINESSIMPACT$ | Nombre entre 0 et 5 indiquant l'impact métier du check |
| Note |
|---|
On accède en général aux propriétés du check avec la notation entre dollars commençant par SERVICE (ex $SERVICEDESC$). Dans le tableau, certaines entrées ne commencent pas par HOST sont présentes, mais font quand même référence à une propriété du check. |
Propriétés des utilisateurs
| Syntaxe | Description |
|---|---|
| $CONTACTNAME$ | Nom de l'utilisateur (propriété contact_name) |
| $CONTACTEMAIL$ | Adresse mail de l'utilisateur (propriété email) |
| $CONTACTPAGER$ | Numéro de téléphone de l'utilisateur (propriété pager) |
Globales prédéfinies
Certaines globales présentes ci-dessous sont définies par Shinken et accessibles comme n'importe quelle autre globale.
| Syntaxe | Description |
|---|---|
$LONGDATETIME$ | Heure/date courante au format long (par ex Fri Oct 13 00:30:28 CDT 2000) |
$SHORTDATETIME$ | Heure/date courante au format court (par ex 10-13-2000 00:30:28) |
$DATE$ | Date courante (par ex 10-13-2000) |
$TIME$ | Heure courante (par ex 00:30:28) |
$TIMET$ | Heure courante au format timestamp |
| title | Données personnalisées |
|---|
Les données 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:
| Code Block | ||
|---|---|---|
| ||
# 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 globales 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 globales seront donc copiés dans /etc/shinken/resource.d/ et disponibles comme les autres globales.
QESSISPASS si jamais une donnée globale a un nom réservé ??? Ex $DATE$
Si 2 globales de meme nom sont définies, laquelle est prise ?
Utiliser des données globales
Les globales sont accessibles en spécifiant seulement le nom de la global entourée par des dollars ($).
La global "MAGLOBALE" est donc accessible par la macro $MAGLOBALE$.
| Note |
|---|
Parce que les globales sont définies dans les fichiers de configuration, un ajout ou modification d'une globale dans ces fichiers nécessite un redémarrage de Shinken Entreprise pour que les modifications soient prises en compte. |
Remarques sur la définition et l'utilisation des macros
Quelle que soit l'utilisation d'une macro, celle-ci doit toujours être en majuscule. Si à l'import des fichiers CFG ou lors de la modification sur l'interface de configuration, une macro comporte des minuscules, celles-ci seront converties et un avertissement sera affiché.
Inventaire des macros disponibles
Référence vers la doc Shinken readthedocs
A quoi servent les macros ?
L'une des caractéristiques qui rend Shinken Enterprise flexible, c'est sa capacité à utiliser des données dans la définition des Commandes. Ces données permettent de référencer des informations provenant des hôtes, des services, ou d'autres sources dans les commandes.
Remplacement de données
Avant d'exécuter une commande, Shinken Enterprise va remplacer toutes les données trouvées dans la définition de la commande avec leur valeurs correspondantes. Ce remplacement s'opère pour toute commande que Shinken Enterprise exécute : vérification d'hôte et de check, notification, exécution d'événements, etc .
Ce remplacement est récursif. Si une macro contient à son tour une macro, cette seconde macro sera résolue. Ce processus continue jusqu'à ce que la commande ne contienne plus de macro.
| Info |
|---|
L'utilisation littérale du caractère '$' nécessitera l'utilisation de '$$'. C'est également le cas dans les règles de Clusters, qui peuvent aussi contenir des macros. |
| Info |
|---|
Le nom d'une donnée peut contenir uniquement des caractères alphanumériques (a-zA-Z0-9). |
Exemple 1 : Adresse générique
Lorsque vous utilisez un hôte ou un service dans les données de définitions de commande , ils se réfèrent à des valeurs pour l'hôte ou le service pour lequel la commande est en cours d'exécution
Prenons un exemple. Imaginons que nous utilisons une définition de l'hôte "Linuxbox" qui est vérifié par une commande check_ping, qui est définie comme suit.
| Code Block |
|---|
/var/lib/Shinken Enterprise/libexec/check_ping -H $HOSTADDRESS$ -w 100.0,90% -c 200.0,60% |
Linuxbox a pour adresse 192.168.1.2.
La macros sera remplacée et la ligne de commande finale suivante sera exécutée :
| Code Block | ||
|---|---|---|
| ||
/var/lib/Shinken Enterprise/libexec/check_ping -H 192.168.1.2 -w 100.0,90% -c 200.0,60% |
Exemple 2 : Argument de commande
Vous pouvez également passer des arguments dans une commande, ce qui permet de garder une définition de commande générique.
Les différents arguments sont séparés par le caractère '!'. On peut donc, dans l'hôte, définir les arguments de la commande check_ping comme étant:
| Info |
|---|
Si vous devez utiliser le caractère ( ! ) dans les arguments de votre commande, vous pouvez éviter son interprétation en le préfixant d'un anti-slash ( \ ). si vous avez besoin de l'anti-slash dans une commande, il suffit de doubler l'anti-slash ( \\ ). |
| Code Block |
|---|
200.0,80%!400.0,40% |
Ces arguments deviennent alors disponibles dans la commande par les macros $ARGn$. $ARG1$ sera remplacé en "200.0,80%" et $ARG2$ en "400.0,40%". La définition de la commande peut alors être réécrite :
| Code Block |
|---|
/var/lib/Shinken Enterprise/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ |
Exemple 3 : Utilisation des données
Qu'en est-il si plusieurs hôtes partagent les mêmes arguments de commande ?
Le plus simple est de définir un modèle (voir la Logique des modèles) contenant ces données spécifiques.
Nous allons créer un modèle contenant des données. Pour cet exemple, nous les nommerons WARNINGPING et CRITICALPING, et contiendront ces valeurs.
| Info |
|---|
Dans l'interface de configuration, elles sont disponibles dans l'onglet de données du modèle. Dans un fichier d'import, il sera nécessaire de les préfixer avec '_'. |
On spécifiera dans le modèle que la commande est appelée avec, en argument, ces données:
| Code Block |
|---|
$_HOSTWARNINGPING$!$_HOSTCRITICALPING$ |
La commande n'a pas besoin d'être modifiée, de par l'application récursive des macros.
Cela ouvre une nouvelle possibilité: si, on imagine, que sur un hôte donné, le seuil doit être différent, il suffira alors de surcharger les données WARNINGPING et CRITICALPING dans l'hôte, et la commande lancée sera spécialisée pour cet hôte uniquement.
Il est possible d'effectuer de même pour les Checks, et donc d'appeler en argument $_SERVICEWARNINGPING$!$_SERVICECRITICALPING$ ce qui ira prendre les valeurs de la données WARNINGPING et CRITICALPING du Check.













