Principe de fonctionnement des module receiver d'écoute avec des workers

Le module receiver-module-generic-endpoint est un module qui est utile pour servir de base au développement d'un module:

  • pour le receiver
  • qui fonctionne avec un worker à l'heure actuelle
    • en effet si on en rajoute plusieurs chaque worker n'aura qu'une partie des éléments sélectionnés pour être géré par ce receiver


Il est important de noter que seul les éléments spécifiquement sélectionné par un template d'hôte dans la configuration du receiver seront gérés par ce receiver et ses modules


Mise en place du module d'exemple

Choisir le nom de votre module

Il faut un nom pour votre module. Le nom doit respecter:

  • uniquement des caractères ascii
  • en terme de caractères spéciaux, seuls - ou _ sont supportés
  • pas d'espaces
  • tout en lower case

Dans cette documentation on le nommera mon_module

Copier le module dans son répertoire

Le module est installé via deux actions:

  • on met son code en place dans /var/lib/shinken/modules
  • on met sa configuration en place dans /etc/shinken/modules

Il faut donc:

  • copier le répertoire module en tant que /var/lib/shinken/modules/mon_module
  • copier le fichier receiver-module-generic-endpoint.cfg en tant que /etc/shinken/modules/mon_module.cfg 

Renommer le contenu du module et sa configuration avec notre nouveau nom


Il est important de renommer TOUTES les parties du module, si votre module a encore des classes ayant le même nom que le module generic, alors il y aura des problème d'import du code par le daemon et le résultat sera incorrect.

Dans le code livré par défaut le nom du module est MODULE_CODE_NAME.

  • Éditez /var/lib/shinken/modules/mon_module/module.py en changeant toutes les occurrences de ReceiverGenericEndpoint en mon_module.
  • Éditez /etc/shinken/modules/mon_module.cfg en changeant toutes les occurrences de receiver_module_generic_endpoint en mon_module

Déclarez le module sur votre receiver

Pour que le module s'active il faut:

  • redémarrer le broker afin qu'il charge le nouveau code (module.py)
  • rajouter votre module dans votre broker (typiquement /etc/shinken/brokers/broker-master.cfg)

Notes pour le développement de votre module

Il est important de bien lire les commentaires dans le code d'exemple avant toute modification.

Comme vu sur le diagramme d'explication des modules basés sur des workers, le code est divisés en deux parties:

  • La classe du module en lui même, qui va être chargée par le processus broker
  • La classe du worker qui va fonctionner dans le processus du worker

Le code du module

Le code dans le module va être très limité, car la seule méthode que vous pouvez modifier/surcharger est get_raw_stats qui est utilisée pour les checks de supervision et le healthcheck.

Il est important de:

  • ne pas surcharger la méthode __init__ du module
  • ne pas surcharger d'autres méthodes de la classe module autre que get_raw_stats et want_brok
  • toujours laisser l'appel au super au sein de get_raw_stats et seulement rajouter vos propres données au résultat sans modifier celle existantes.
  • want_brok: vous pouvez le surcharger pour filtrer les broks qu'on ne souhaite pas envoyer au worker.
  • tous les imports doivent être fait depuis shinkensolutions.api et pas shinken directement car seul shinkensolutions.api est considéré comme une API stable entre les versions
    • NOTE: en version v02.07.04 cet espace n'étant pas disponible, les imports dans shinken sont fournis à la place mais devront être migré dès le passage en v02.08.01.


Le code dans le worker

Le code dans le worker est celui où sera votre code métier ainsi que votre boucle principale d'actions.

Ici encore certaines règles s'appliquent afin s'assurer une stabilité dans le temps:

  • ne pas surcharger la méthode __init__ de la classe worker
  • toujours laisser l'appel au super au sein de get_raw_stats et seulement rajouter vos propres données au résultat sans modifier celle existantes.
  • tous les imports doivent être fait depuis shinkensolutions.api et pas shinken directement car seul shinkensolutions.api est considéré comme une API stable entre les versions
    • NOTE: en version v02.07.04 cet espace n'étant pas disponible, les imports dans shinken sont fournis à la place mais devront être migrès dès le passage en v02.08.01.

Les méthodes que vous pouvez surcharger sont multiples.

Méthodes surchageables concernant le fonctionnement global du worker:

  • init_worker_before_main: (init_worker en version v02.07.04) cette fonction vous permet de récupérer les paramètres de votre module dans le fichier .cfg sous forme de string comme propriétés de l'objet module_configuration. 
  • worker_main: (obligatoire) c'est la boucle principale de votre worker. Si elle s'arrêt, le worker s'arrête également et le module est mis en erreur.


    • ATTENTION: toutes les autres méthodes (exceptées init_worker_before_main qui est appelées avant le worker_main) sont faites dans des threads différents. Vous devez donc faire attention à l'accès concurrents de vos données.


  • get_raw_stats: vous pouvez la surcharger pour retourner les stats de votre module, qui seront récupérées par le get_raw_stats que vous avez surchargés dans la classe module.

Les méthodes concernant les broks reçus du broker:

  • manage_initial_host_status_brok : appelé avec le brok concernant un hôte et tous les champs exportés dans les broks par les hôtes
  • manage_initial_service_status_brok: appelé avec le brok concernant un check et tous les champs exportés dans les broks par les checks
  • manage_service_check_result_brok : appelé avec le brok présentant les champs du check après un retour de vérification
  • manage_host_check_result_brok: appelé avec le brok présentant les champs de l'hôte après un retour de vérification

Les méthodes concernant l'inventaires des hôtes:

  • callback__a_new_host_added: appelé avec l'uuid d'un hôte qui vient d'être rajouté
  • callback__a_host_updated: appelé avec l'uuid d'un hôte qui vent d'être modifié
  • callback__a_new_realm_added: appelé lorsqu'un royaume vient d'être fini d'être chargé 
    • et donc tous les appels des callback__a_new_host_added/callback__a_host_updated sont déjà effectués
  • callback__a_realm_updated: appelé lorsqu'un royaume vient d'être fini d'être mis à jour
    • et donc tous les appels des callback__a_new_host_added/callback__a_host_updated sont déjà effectués