Concept général

Shinken Entreprise permet d'effectuer des remplacements dynamiques de contenu ( autrefois appelé "MACRO" ).

  • Cela permet de paramétrer avec une grande flexibilité les commandes lancées par Shinken, les liens externes des éléments… 
  • La notation entre dollars "$" est utilisée pour permettre ce remplacement.
  • Les variables donnent la capacité d'utiliser dans la configuration de la supervision,
    • des informations dites globales,
    • ainsi que les propriétés et les données présentes sur les éléments ( Hôtes, Cluster, Check, Utilisateurs ).
      • par exemple, les propriétés d'un hôte dans la vérification d'un check.

Exemple :

On dispose d'une commande qui se charge de contacter un hôte pour déterminer s'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 Variable $HOSTADDRESS$ qui va contenir l'adresse de l'hôte courant.

Ainsi, en utilisant cette Variable 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 Variable par l'adresse de l'hôte.

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

donne au final

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

Utilisation du remplacement dynamique de contenu

Endroits où le remplacement dynamique de contenu est effectué

Le remplacement dynamique de contenu n'est pas effectué partout.

Voici la liste par type d'élément où est effectué le remplacement dynamique de contenu :

Les Hôtes et leurs modèles

  • Vivant ( Commande de vérification ),
  • URL externe,
  • Liste des URL externes,
  • Données locales & héritées d'un modèle,
  • Commande lancée par le gestionnaire d'événements.

Les Clusters et leurs modèles

  • Définition,
  • URL externe,
  • Liste des URL externes,
  • Données locales & héritées d'un modèle,
  • Commande lancée par le gestionnaire d'événements.

Les Checks et leur modèles

  • Commande de vérification,
  • URL externe,
  • Liste des URL externes,
  • Données locales & héritées d'un modèle,
  • Commande lancée par le gestionnaire d'événements.

Les Utilisateurs avec leurs modèles

  • Données locales & héritées d'un modèle

Les Méthodes de notification

  • Commande de notifications pour l'hôte/cluster,
  • Commande de notifications pour les checks.

Les Commandes

  • Ligne de Commande

Les Modulations de données

  • Données locales & héritées d'un modèle

Remplacement récursif

Le remplacement dynamique de contenu est récursif.

  • Ce qui veut dire que les Variables dans les Variables seront remplacées.
  • Il est possible d'effectuer une boucle de remplacement sans le vouloir ( exemple : VARIABLE_1  nécessite VARIABLE_2  qui nécessite VARIABLE_3 qui nécessite VARIABLE_1 ).
    Dans ce cas, une erreur est remontée, dans l'interface de Configuration et de Visualisation.



Limites lors du remplacement des Variables

Il peut arriver que le résultat de certaines Variables nécessite l'évaluation d'autres Variables 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 :

  • 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 ne peut pas excéder 65000 caractères.


Si un dépassement se produit,

  • la résolution des Variables est interrompue,
  • et la Variable est tronquée pour être intégrée dans un message remontant cette information.


Comment est effectué le remplacement des Variables

Le remplacement est fait dans deux démons :

  • Le Synchronizer pour l'Interface de Configuration.
  • Le Scheduler pour l'Interface de Visualisation, les notifications et la préparation des commandes de supervision ( pour leur exécution par le Poller ).

Le Synchronizer ne gérant que la configuration des éléments,

Il y a une autre différence sur les remplacements effectués par les deux démons : 

  • le Scheduler, gère le nombre de Variables 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.

Les différents types de Variables

Il existe trois types de Variables :

  • Les Variables globales
  • Les Variables d'élément
  • Les Variables génératives

Les Variables globales 

Il est possible dans Shinken Entreprise de définir des Variables globales accessibles partout dans Shinken et qui ne dépendent pas d'un élément particulier.

  • Ces Variables globales se définissent dans des fichiers de configuration.
  • Une globale nommée MAGLOBALE sera accessible avec la notation $MAGLOBALE$.

Définir des Variables globales

Les Variables globales peuvent être définies UNIQUEMENT par fichiers de configuration.

  • Par défaut, un certain de nombre de Variables globales sont prédéfinies dans le dossier /etc/shinken/resource.d,
  • Ce dossier contient tous les fichiers qui déclarent les Variables globales.
  • Au démarrage du Synchroniser, ces fichiers sont chargés et les Variables globales qui y sont définies sont disponibles dans l'UI de Configuration.
  • Au démarrage de l'Arbiter, ces fichiers sont chargés et les Variables globales qui y sont définies sont disponibles pour tous les autres démons.

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

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

$NOMDELAGLOBALE$=valeur

Les noms de Variables globales ne peuvent contenir que des caractères alphanumériques ( A-Z 0-9 ), des tirets ( - ) et des soulignés (  _ ).

Variables globales prédéfinies

Shinken possède aussi des Variables globales directement utilisable et dont les valeurs proviennent des démons.

SyntaxeDescriptionRemplacé dans le SynchronizerRemplacé dans le Scheduler

$LONGDATETIME$

Heure/date courante au format long ( par exemple : Fri Oct 13 00:30:28 CDT 2000 )

(error)

(tick)

$SHORTDATETIME$

Heure/date courante au format court ( par exemple : 10-13-2000 00:30:28 )

(error)

(tick)

$DATE$

Date courante ( par exemple : 10-13-2000 )

(error)

(tick)

$TIME$

Heure courante ( par exemple : 00:30:28 )

(error)

(tick)

$TIMET$

Heure courante au format timestamp ( par exemple : 1706871278 )

(error)

(tick)

$SHINKENVERSION$

Contient la version de Shinken. ( par exemple : V02.08.02 )

(error)

(tick)

Ces Variables ne sont pas encore disponibles dans le Synchronizer.

  • C'est un point qui sera amélioré dans une prochaine version de Shinken.

Utiliser des Variables globales

Les Variables globales sont accessibles en entourant le nom de la Variable globale par des dollars "$".

  • La Variable globale "MAGLOBALE" est donc accessible avec la notation $MAGLOBALE$.


Parce que les Variables globales sont définies dans les fichiers de configuration, l'ajout ou la modification d'une Variable globale dans ces fichiers nécessite un redémarrage du Synchronizer et de l'Arbiter pour que les changements soient pris en compte.

  • C'est un point qui sera amélioré dans une prochaine version de Shinken.

Les Variables d'élément ( Hôte, Cluster, Check, Utilisateur )

Les Variables d'élément correspondent à des propriétés ( de définition ou d'exécution ) ou des données d'un élément.


Les Variables issues des Propriétés ( $HOST...$, $SERVICE...$, $CONTACT...$ )

Parmi tous les éléments de Shinken Entreprise, il est possible d'accéder à certaines propriétés des Hôtes, des Clusters, des Checks et des Utilisateurs.

  • Pour accéder à une propriété d'un élément, il faut bien sûr le $, puis le type de l'élément et le nom de la propriété
    • Pour les Types :
      • HOST => pour les Hôtes et Clusters ( c'est le même mot clé de type )
      • SERVICE => pour les Checks
      • CONTACT => pour les Utilisateurs
    • On accède a la propriété en rajoutant son nom aprés le type

      VariableFonction
      $HOSTPROPRIETE$Accède une propriété de l'hôte
      $SERVICEPROPRIETE$Accède à une propriété du check
      $CONTACTPROPRIETE$Accède à une propriété de l'utilisateur
    • Les propriétés disponibles par éléments diffèrent en fonction de l'élément.
      • Les noms des propriétés accessibles par le mécanisme de Variable sont listés dans les chapitres ci-dessous décrivant les éléments ( Hôtes, Clusters, Checks, Utilisateurs ). 

  • Point important : Il existe 2 types de Propriétés
    • Des propriétés de définition ( Elles sont définies dans l'UI de Configuration et ne changent que lorsque l'on change la configuration ).
    • Des propriétés d'exécution ( Elles sont calculées par le Scheduler et susceptible de changer à chaque exécution d'une vérification de l'élément ).
      • Cela concerne les Hôtes, Les Clusters et les Checks.
  • Par exemple, pour qu'une commande de vérification d'un check accède à l'adresse d'un hôte, il faut utiliser $HOSTADDRESS$.

Propriétés des hôtes
SyntaxePropriété de TYPEDescriptionDisponible  dans le SynchronizerDisponible  dans le Scheduler

$HOSTNAME$

DEFINITION

Nom de l'hôte ( propriété host_name )

(tick)

(tick)

$HOSTDISPLAYNAME$

DEFINITION

Nom d'affichage de l'hôte ( propriété display_name )

(tick)

(tick)

$HOSTADDRESS$

DEFINITION

Adresse de l'hôte ( propriété address )

(tick)

(tick)

$HOSTUUID$

DEFINITION

Identifient unique d'un hôte ( Voir la page TIPS - Récupérer l'UUID d'un élément ( Cluster / Hôte / Check ) )

(tick)

(tick)

$HOSTREALM$

DEFINITION

Royaume de l'hôte ( propriété realm )

(tick)

(tick)

$HOSTSTATE$

EXECUTION

Statut courant de l'hôte ( UP, DOWN, ou UNREACHABLE )

(error)

(tick)

 $HOSTSTATETYPE$

EXECUTION

Confirmation du statut d'un hôte ( SOFT ou HARD )

(error)

(tick)

$HOSTSTATEID$

EXECUTION

Numéro correspondant au statut courant de l'hôte ( 0=UP, 1=DOWN, ou 2=UNREACHABLE )

(error)

(tick)

$LASTHOSTSTATE$

EXECUTION

Statut précédent de l'hôte ( UP, DOWN, ou UNREACHABLE )

(error)

(tick)

$LASTHOSTSTATEID$

EXECUTION

Numéro correspondant au statut précédent de l'hôte ( 0=UP, 1=DOWN, ou 2=UNREACHABLE )

(error)

(tick)

$HOSTGROUPNAME$

EXECUTION

Nom du groupe d'hôte auquel appartient l'hôte. S'il appartient à plusieurs groupes d'hôtes, un seul sera retourné

(error)

(tick)

$HOSTGROUPNAMES$

DEFINITION

Liste des groupes d'hôtes auxquels appartient l'hôte, séparés par des virgules

(tick)

(tick)

$LASTHOSTCHECK$

EXECUTION

Date au format timestamp de la dernière vérification de l'hôte

(error)

(tick)

$LASTHOSTSTATECHANGE$

EXECUTION

Date au format timestamp du dernier changement de statut de l'hôte

(error)

(tick)

$LASTHOSTUP$

EXECUTION

Date au format timestamp du dernier statut UP de l'hôte

(error)

(tick)

$LASTHOSTDOWN$

EXECUTION

Date au format timestamp du dernier statut DOWN de l'hôte

(error)

(tick)

$LASTHOSTUNREACHABLE$

EXECUTION

Date au format timestamp du dernier statut UNREACHABLE de l'hôte

(error)

(tick)

$HOSTOUTPUT$

EXECUTION

Résultat de la dernière vérification de l'hôte

(error)

(tick)

$LONGHOSTOUTPUT$

EXECUTION

Résultat long de la dernière vérification de l'hôte

(error)

(tick)

$HOSTPERFDATA$

EXECUTION

Données de performances renvoyées par la dernière vérification de l'hôte

(error)

(tick)

$HOSTCHECKCOMMAND$

DEFINITION

Nom de la commande utilisée pour la vérification de l'hôte ( avec les paramètres )

(tick)

(tick)

$HOSTNOTESURL$

DEFINITION

URL externe de l'hôte ( propriété notes_url )

(tick)

(tick)

$HOSTBUSINESSIMPACT$

DEFINITION

Nombre entre 0 et 5 indiquant l'impact métier de l'hôte

(tick)

(tick)

$HOSTFIRSTNOTIFICATIONDELAY$ 

DEFINITION

Nombre de minutes à attendre avant d'envoyer la première notification pour un hôte

(tick)

(tick)

$HOSTNOTIFICATIONNUMBER$

EXECUTION

Nombre de notifications consécutives envoyées pour un statut différent de UP

(error)

(tick)

$HOSTDOWNTIMECOMMENT$

EXECUTION

Le commentaire du contexte "Période de maintenance"

(error)

(tick)

$HOSTDOWNTIMEAUTHOR$

EXECUTION

L'auteur du contexte "Période de maintenance"

(error)

(tick)

$ACKDATA$

EXECUTION

Le message d'un contexte "Prise en compte".

(error)

(tick)

$ACKAUTHOR$

EXECUTION

L'auteur d'un contexte "Prise en compte".

(error)

(tick)

On accède en général aux propriétés de l'hôte avec la notation entre dollars commençant par HOST ( exemple : $HOSTADDRESS$ ). Dans le tableau, certaines entrées ne commençant pas par HOST sont présentes, mais elles font quand même référence à une propriété de l'hôte.

Propriétés des checks
SyntaxePropriété de TYPEDescriptionDisponible dans le SynchronizerDisponible dans le Scheduler

$SERVICEDESC$

DEFINITION

Nom/description du check

(tick)

(tick)

$SERVICEDISPLAYNAME$

DEFINITION

Nom d'affichage du check ( propriété display_name )

(tick)

(tick)

$SERVICEUUID$

DEFINITION

Identifient unique d'un check ( Voir la page TIPS - Récupérer l'UUID d'un élément ( Cluster / Hôte / Check ) )

(tick)

(tick)

$SERVICESTATE$

EXECUTION

Statut courant du check ( OK, WARNING, UNKNOWN, CRITICAL )

(error)

(tick)

$SERVICESTATETYPE$

EXECUTION

Confirmation du statut d'un check ( SOFT ou HARD )

(error)

(tick)

$SERVICESTATEID$

EXECUTION

Numéro correspondant au statut courant du check ( 0=UP, 1=DOWN, ou 2=UNREACHABLE )

(error)

(tick)

$LASTSERVICESTATE$

EXECUTION

Statut précédent du check ( OK, WARNING, UNKNOWN, CRITICAL )

(error)

(tick)

$LASTSERVICESTATEID$

EXECUTION

Numéro correspondant au statut précédent du check ( 0=UP, 1=DOWN, ou 2=UNREACHABLE )

(error)

(tick)

$SERVICEISVOLATILE$

DEFINITION

Booléen indiquant si le check est volatile ( False=Non volatile, True=Volatile )

(tick)

(tick)

$LASTSERVICECHECK$

EXECUTION

Date au format timestamp de la dernière exécution du check

(error)

(tick)

$LASTSERVICESTATECHANGE$

EXECUTION

Date au format timestamp du dernier changement de statut du check

(error)

(tick)

$LASTSERVICEOK$

EXECUTION

Date au format timestamp du dernier statut OK du check

(error)

(tick)

$LASTSERVICEWARNING$

EXECUTION

Date au format timestamp du dernier statut WARNING du check

(error)

(tick)

$LASTSERVICEUNKNOWN$

EXECUTION

Date au format timestamp du dernier statut UNKNOWN du check

(error)

(tick)

$LASTSERVICECRITICAL$

EXECUTION

Date au format timestamp du dernier statut CRITICAL du check

(error)

(tick)

$SERVICEOUTPUT$

EXECUTION

Résultat de la dernière vérification du check

(error)

(tick)

$LONGSERVICEOUTPUT$

EXECUTION

Résultat long de la dernière vérification du check

(error)

(tick)

$SERVICEPERFDATA$

EXECUTION

Données de performances renvoyées par la dernière exécution du check

(error)

(tick)

$SERVICECHECKCOMMAND$

DEFINITION

Nom de la commande utilisée pour l'exécution du check ( avec les paramètres )

(tick)

(tick)

$SERVICENOTESURL$

DEFINITION

URL externe du check ( propriété notes_url )

(tick)

(tick)

$SERVICEBUSINESSIMPACT$

DEFINITION

Nombre entre 0 et 5 indiquant l'impact métier du check

(tick)

(tick)

$SERVICEFIRSTNOTIFICATIONDELAY$

DEFINITION

Nombre de minutes à attendre avant d'envoyer la première notification pour un service

(tick)

(tick)

$SERVICENOTIFICATIONNUMBER$ 

EXECUTION

Nombre de notifications consécutives envoyées pour un statut différent de OK

(error)

(tick)

$SERVICEDOWNTIMECOMMENT$

EXECUTION

Le commentaire du contexte "Période de maintenance"

(error)

(tick)

$SERVICEDOWNTIMEAUTHOR$

EXECUTION

L'auteur du contexte "Période de maintenance"

(error)

(tick)

$ACKDATA$

EXECUTION

Le message d'un contexte "Prise en compte".

(error)(tick)

$ACKAUTHOR$

EXECUTION

L'auteur d'un contexte "Prise en compte".

(error)(tick)

On accède en général aux propriétés du check avec la notation entre dollars commençant par SERVICE ( exemple : $SERVICEDESC$ ). Dans le tableau, certaines entrées ne commençant pas par SERVICE sont présentes, mais elles font quand même référence à une propriété du check.

Propriétés des utilisateurs
SyntaxePropriété de TYPEDescriptionDisponible dans le SynchronizerDisponible dans le Scheduler
$CONTACTNAME$DEFINITIONNom de l'utilisateur ( propriété contact_name )(tick)(tick)
$CONTACTEMAIL$ DEFINITIONAdresse mail de l'utilisateur ( propriété email )(tick)(tick)
$CONTACTPAGER$DEFINITIONNuméro de téléphone de l'utilisateur ( propriété pager )(tick)(tick)
Propriétés des notification
SyntaxePropriété de TYPEDescriptionDisponible dans le SynchronizerDisponible dans le Scheduler
$NOTIFICATIONTYPE$EXECUTION

Le type de notification à envoyer. Cela correspond au type d'événement qui a été constaté sur l'élément.


Type

Événement source

PROBLEM  Le statut de l'élément est non OK.
RECOVERYL'élément avait un problème, mais est de nouveau dans un statut OK.
ACKNOWLEDGEMENT  Un utilisateur a envoyé par l'interface web un accusé de réception par rapport à un problème survenu à un hôte ou à un check.
FLAPPINGSTART, FLAPPINGSTOPL'élément est entré ou sorti d'un contexte de FLAPPING .
FLAPPINGDISABLED  La détection a été désactivée pendant la durée du FLAPPING .
DOWNTIMESTART, DOWNTIMESTOP   L'élément est entré ou sorti d'une période programmée d'indisponibilité.
DOWNTIMECANCELLEDLa période programmée d'indisponibilité de l'élément a été annulée en cours.



(error)(tick)



Les Variables pour les Données ($_HOST...$, $_SERVICE...$, $_CONTACT...$ )

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 de compléter la définition d'un élément 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.


Pour accéder à une donnée d'un élément, il faut bien sûr le $, puis un UNDERSCORE, puis le type de l'élément et le nom de la propriété :

    • Le UNDERSCORE => "_"
    • Les types sont les mêmes que pour les propriétés :
      • HOST => pour les Hôtes et Clusters ( c'est le même mot clé de type )
      • SERVICE => pour les Checks
      • CONTACT => pour les Utilisateurs
    • On accède à la donnée en rajoutant son nom aprés le type.

      VariableFonction
      $_HOSTDONNEE$Accède à la donnée personnalisée "DONNEE" de l'hôte
      $_SERVICEDONNEE$Accède à la donnée personnalisée "DONNEE" du check
      $_CONTACTDONNEE$Accède à la donnée personnalisée "DONNEE" de l'utilisateur

C'est la présence d'un underscore ( _ ) avant HOST, SERVICE ou CONTACT, ce qui permet de différencier l'accès à une propriété de l'élément et l'accès à une donnée personnalisée.

  • Par exemple, imaginons qu'on ajoute une donnée sur un hôte qui s'appelle ADDRESS_2
    • Sur la commande de vérification d'un check, il accède à l'adresse d'un hôte, il faut utiliser $_HOSTADDRESS_2$.

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.

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.

Dans un fichier de configuration, une donnée personnalisée est définie en précédant son nom 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 précisant le nom de la donnée et sa valeur.

Les Variables génératives ( $ARGn$, $VALUEn$ )

Lorsque l'on remplace dynamiquement du contenu,

  • il est possible de faire référence aux propriétés, aux données locales ainsi qu'aux Variables globales.
  • il existe également des Variables spéciales qui ne récupèrent ni des Variables globales, ni des données locales ou des propriétés d'un élément.
    • Elles permettent de transférer des données, notamment des arguments de commande.

Ces Variables spéciales sont accessibles avec les notations $ARGn$ et $VALUEn$.

Les Variables générées par l'utilisation d'une commande ( $ARGn$, $VALUEn$ )

Shinken Entreprise permet aux hôtes et aux checks de préciser les commandes qui seront utilisées pour la vérification de l'élément.

  • Dans l'optique de rendre ces commandes le plus générique 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 définition de la commande, on veut pouvoir récupérer la valeur de ces arguments pour pouvoir les utiliser sur la ligne de commande.

  • Pour cela, on utilise la notation $ARGn$.
  • La Variable $ARGn$ permet simplement d'accéder à la valeur du n-ième argument.


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

Il est possible d'utiliser des Variables comme argument.

  • Exemple : 200!$_HOSTWARNING_LEVEL$
  • Elles seront remplacées lors de l'évaluation de la commande.


Pour une utilisation avancée, et avec un certain niveau de maîtrise nécessaire, il est même possible d'utiliser une Variable pour définir plusieurs arguments.

  • Il faut utiliser pour cela le séparateur : |-|
  • Exemple :
    • Dans les arguments : VERBOSE!$_HOSTLEVELS$
    • Dans l’hôte, la donnée LEVELS vaut 200|-|400
    • La commande script.py $ARG1$ $ARG2$ $ARG3$ deviendra script.py VERBOSE 200 400

Il est possible d'utiliser jusqu'à 32 arguments.

  • Ainsi, les Variables $ARG1$ à $ARG32$ sont utilisables.

Les Variables générées par l'utilisation de la Duplication de check ( Duplicate Foreach ) - ( $KEY$, $VALUE1$ )

La fonctionnalité avancée Dupliquer des checks en fonction d'une liste de valeurs présentes dans la Donnée d'un hôte (duplicate_foreach) 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, une clé est affectée, et optionnellement des paramètres.

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

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

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

VariableValeur
$KEY$check1
$VALUE1$valeur1
$VALUE2$valeur2
$VALUE3$valeur3

Il est possible d'utiliser 16 valeurs différentes. Ainsi, les Variables $VALUE1$ jusqu’à $VALUE16$ sont disponibles.