Bonnes pratiques: pour en finir avec les arguments de type $ARG…$

This post is also available in: Anglais

De nombreux utilisateurs répugnent ou se décomposent à l’idée de devoir modifier les arguments des commandes de Centreon. Et on ne peut pas vraiment leur donner tort ; qui a envie de devoir retenir ce que signifient des arguments aussi abscons que $ARG1$ , $ARG2$…
Voici une méthode simple qui vous permettra, en utilisant des macros personnalisés d’écrire facilement nos commandes et surtout de retenir/comprendre les arguments utilisés.

Rappel sur l’écriture des commandes

Lorsque l’utilisateur définit une commande dans Centreon, il doit définir des arguments à cette commande. Ces arguments sont appelés « macro standards » et sont nommés « $ARG1$ » pour le premier argument, « $ARG2$ » pour le second et ainsi de suite. Ces macros sont ensuite définies dans les modèles de service ou dans un service.
Exemple : l’utilisateur crée une commande supervisant l’espace disque disponible sur une partition Linux :

01_saisie_commande_traditionnelle

L’important dans cette capture d’écran est à « Ligne de commande » : $ARG1$, $ARG2$, $ARG3$, $ARG4$, $ARG5$.
Ces arguments sont définis par l’utilisateur, dans l’ordre qu’il souhaite. La limite est que ces éléments sont très peu lisibles : à quoi correspond $ARG1$ ? Et $ARG2$ ? Et les autres ? Sans connaître la sonde de supervision « check_centreon_snmp_remote_storage », il est impossible de le savoir. C’est la principale limite de ce mode de fonctionnement : le manque de lisibilité.

Les exemples d’arguments

Centreon, au fil des versions successives, a remédié à ce problème.
Tout d’abord, Centreon permet de définir un exemple d’arguments. Dans la capture d’écran précédente, l’exemple est : !/!80!90!$USER2$!1

Cet exemple peut ensuite être réutilisé dans les modèles de service et les services. L’utilisateur choisi une commande et défini les arguments de la commande par cette syntaxe.

Cette syntaxe très rigide est très complexe à utiliser: il faut d’abord placer un premier point d’exclamation puis le premier argument puis encore un point d’exclamation puis le second argument et ainsi de suite. Lors des formations que nous donnions, il nous arrivait d’expliquer au stagiaire : « un argument == un point d’exclamation. Deux arguments == deux points d’exclamation. N arguments == N points d’exclamation. ». Même si cela parait très simple, c’est très complexe. Tant à comprendre qu’à expliquer, mais surtout à vérifier : lorsqu’une erreur est remontée à la génération de la configuration, il faut vérifier chaque argument consciencieusement en s’assurant que tous les points d’exclamation sont présents, que les arguments sont saisis dans le bon ordre, que l’on a pas mis deux points d’exclamation au lieu d’un seul, …

Les descriptifs d’arguments

Une autre solution a été mise en place par Centreon : la possibilité de définir un descriptif des arguments dès la saisie de la commande. Dans la première capture d’écran, les arguments sont détaillés dans la partie « Argument descriptions » :

  1. ARG1 : warning
  2. ARG2 : critical
  3. ARG3 : path, partition
  4. ARG4 : community
  5. ARG5 : SNMP version

Cette description est reprise ensuite lors de la définition du service ou du modèle de service lorsque l’utilisateur choisit la commande :

02_saisie_service_avec_arguments_preremplis

Centreon construit alors automatiquement la ligne composée des arguments saisis par l’utilisateur. Lors de la création de la commande, il est possible que l’utilisateur n’ait pas saisi la description des arguments. De plus, si l’utilisateur ne saisit qu’un seul argument, cela ne fonctionne plus. Il est en effet obligatoire de saisir tous les arguments ou aucun.
Enfin, il est très complexe de saisir et de maintenir une macro commune à tous les services d’un hôte. Par exemple, le port d’une base de données peut-être saisi une seule fois et sa valeur identique pour tous les services de supervision de cette base de données. Une troisième solution permet d’aller plus loin et d’être encore plus explicite : les macros personnalisées ou les custom macros.

Les macros personnalisées

Les macros personnalisées sont définies dans les commandes puis leur valeur est saisie dans l’hôte ou le service ou le modèle d’hôte ou le modèle de service.
Exemple de définition d’une commande avec les macros personnalisées :

03_saisie_commande_macro_personnalisees

L’important dans cette capture d’écran est surligné en rouge :

image art cedric

L’utilisateur définit lui même ses propres macros. Ceci est rendu possible en :

  1. préfixant la macro par $_ (caractère dollar immédiatement suivi du caractère souligné/underscore)
  2. préfixant la macro par
      -HOST pour définir une macro qui doit être défini sur un hôte ou un modèle d’hôte
      -SERVICE pour définir une macro quoi doit être défini sur un service ou sur un modèle de service
  3. définissant explicitement le nom de la macro : WARNING par exemple
  4. terminant la macro par $ (le caractère dollar).

Dans l’exemple ci-dessus, nous avons défini 2 macros personnalisées d’hôtes (SNMPCOMMUNITY et SNMPVERSION) et 3 macros personnalisées de service (DISK, WARNING et CRITICAL). Les macro d’hôtes SNMPCOMMUNITY et SNMPVERSION sont automatiquement remplies par Centreon lorsque l’utilisateur définit une communauté SNMP et une version SNMP pour un hôte :

04_saisie_communautesnmp_hote

Les macros de service doivent être définies sur un service ou un modèle de service :

05_saisie_macro_service

En résumé, les avantages des macro personnalisées par rapport aux macros standards :
1. elles sont clairement définies, avec un nom significatif choisi par l’utilisateur (WARNING, MYSQLPASSWORD, NRPETCPPORT,…)
2. l’héritage entre modèle de service et service est beaucoup plus souple : par exemple, un modèle de service peut définir une seule macro personnalisée et laisser le service définir les autres
3. la surcharge d’une seule macro est possible
4. une macro personnalisée définie sur un hôte peut être partagée par plusieurs services. Ceci est très utilisé pour définir par exemple des arguments identiques sur un hôte, quel que soit le service. Le cas d’utilisation le plus courant étant le nom d’utilisateur et le mot de passe pour se connecter à une application lorsque celle-ci est supervisée par plusieurs services. Un exemple : il y a 10 services qui supervisent MySQL. Le nom d’utilisateur MySQL, le mot de passe et le port d’écoute de MySQL sont placés tous les trois dans des macros personnalisées d’hôte. Par contre, le nom d’une base de données sera placé dans une macro personnalisée de service.

Mais espérons que cet éclairage nous permette « enfin » de vous y retrouver dans nos macros !

Incoming search terms:

  • centreon define macro
  • définition des macros sur centreon

Leave a Reply