...
A quoi cela sert?
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
Before Shinken Enterprise executes a command, it will replace any datas it finds in the command definition with their corresponding values. This data substitution occurs for all types of commands that Shinken Enterprise executes - host and service checks, notifications, event handlers, etc.
Certain datas may themselves contain other datas. These include the "$HOSTNOTES$", "$HOSTNOTESURL$", "$HOSTACTIONURL$", "$SERVICENOTES$", "$SERVICENOTESURL$", and "$SERVICEACTIONURL$" datas.
Tip: If, you need to have the '$' character in one of your command (and not referring to a data), please put "$$" instead. Shinken Enterprise will replace it well
...
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 Variable de Donnée contient à son tour une autre variable, cette seconde variable sera résolue. Ce processus continue jusqu'à ce que la commande ne contienne plus de variable.
| 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 Variables. |
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 |
- Host:
| Property | Value |
|---|---|
| Name | linuxbox |
| address | 192.168.1.2 |
| check_command | check_ping |
- Command
...
Enterprise/libexec/check_ping -H $HOSTADDRESS$ -w 100.0,90% -c 200.0,60% |
...
You can pass arguments to commands as well, which is quite handy if you'd like to keep your command definitions rather generic. Arguments are specified in the object (i.e. host or service) definition, by separating them from the command name with exclamation points (!) like so:
The check:
...
Linuxbox a pour adresse 192.168.1.2.
La Variable 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% |
...
Ce remplacement a lieu pour chaque exécution différente de la commande. Cette même commande peut donc servir à vérifier des hôtes différents, mais elle peut être rendue encore plus générique.
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:
| Code Block |
|---|
200.0,80%!400.0,40% |
...
Ces arguments deviennent alors disponibles dans la commande par les Variables $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 |
|---|
...
| Property | Value |
|---|---|
| Name | check_ping |
| command line | /var/lib/Shinken Enterprise/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ |
The expanded/final command line to be executed for the service's check command would look like this:
...
/var/lib/Shinken Enterprise/libexec/check_ping -H |
...
$HOSTADDRESS$ -w |
...
$ARG1$ -c |
...
On-Demand datas
...
$ARG2$ |
| 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 ( \\ ). |
| Info |
|---|
Il est possible d'utiliser des Données comme argument. Exemple : 200.0,80%!%_HOSTWARNING_LEVEL% Il est même possible de définir plusieurs argument dans une donnée avec le séparateur : |-| Exemple :
|
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 template (voir la Logique des templates) contenant ces données spécifiques.
Nous allons créer un template 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 template. Dans un fichier d'import, il sera nécessaire de les préfixer avec '_'. |
On spécifiera dans le template 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 Variables.
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.
If you would like to reference values for another host or service in a command (for which the command is not being run), you can use what are called "on-demand" datas. On-demand datas look like normal datas, except for the fact that they contain an identifier for the host or service from which they should get their value. Here's the basic format for on-demand datas:
- * "$HOSTdataNAME:host_name$"
- * "$SERVICEdataNAME:host_name:service_description$"
Replace "HOSTdataNAME" and "SERVICEdataNAME" with the name of one of the standard host of service datas found :ref:here <thebasics/datalist>.
Note that the data name is separated from the host or service identifier by a colon (:). For on-demand service datas, the service identifier consists of both a host name and a service description - these are separated by a colon (:) as well.
On-demand service datas can contain an empty host name field. In this case the name of the host associated with the service will automatically be used.
Examples of on-demand host and service datas follow:
- $HOSTDOWNTIME:myhost$ // On-demand host data
- $SERVICESTATEID:server:database$ // On-demand service data
- $SERVICESTATEID::CPU Load$ // On-demand service data with blank host name field
...
- $CONTACTEMAIL:john$ // On-demand contact data
- $CONTACTGROUPMEMBERS:linux-admins$ // On-demand contactgroup data
- $HOSTGROUPALIAS:linux-servers$ // On-demand hostgroup data
- $SERVICEGROUPALIAS:DNS-Cluster$ // On-demand servicegroup data
Custom Variable datas
...
- "$_HOSTvarname$"
- "$_SERVICEvarname$"
- "$_CONTACTvarname$"
Take the following host definition with a custom variable called ""_MACADDRESS""...
Host definiton
| Property | Value |
|---|---|
| Name | linuxbox |
| address | 192.168.1.1 |
| _MACADDRESS | 00:01:02:03:04:05 |
The "_MACADDRESS" custom variable would be available in a data called "$_HOSTMACADDRESS$".
Data Cleansing
Some datas are stripped of potentially dangerous shell metacharacters before being substituted into commands to be executed. Which characters are stripped from the datas depends on the setting of the illegal_data_output_chars directive. The following datas are stripped of potentially dangerous characters:
- $HOSTOUTPUT$
- $LONGHOSTOUTPUT$
- $HOSTPERFDATA$
- $HOSTACKAUTHOR$
- $HOSTACKCOMMENT$
- $SERVICEOUTPUT$
- $LONGSERVICEOUTPUT$
- $SERVICEPERFDATA$
- $SERVICEACKAUTHOR$
...