Shinken est un ensemble de démons travaillant de manière autonome pour collecter les statuts des équipements supervisés. Mais dans certains cas, Shinken ne peut pas accéder aux équipements à superviser.
Le Receiver permet alors de recevoir des messages de l’extérieur et de les transmettre aux démons concernés.
Mais comme la source de message peut-être différente, il est nécessaire d'ajouter des modules au Receiver qui traduiront les messages reçus dans un format que Shinken comprendra.
Le module receiver-module-generic-endpoint est un module qui est utile pour servir de base au développement de vos modules de Receiver.
Il y a plusieurs manières de récolter des informations du monde extérieur:
Nous avons donc fait évoluer l'architecture du Receiver et des modules accrochés au Receiver pour qu'ils puissent recevoir des informations des hôtes/clusters ainsi que leurs checks associés à gérer.
Nous avons aussi permis que les traitements faits par les modules de Receiver puissent se répartir sur un ou plusieurs processus ( des workers ).
Ce lien vous permet de récupérer l'archive contenant le module d'exemple:
Il faut un nom pour votre module. Ce nom doit respecter les règles suivantes :
Dans cette documentation, on le nommera NOMduMODULE
Nous suivons maintenant pour tout nouveau module la convention suivante: NOMduDEMON_module_NOMduMODULE |
Le module est installé avec deux actions:
Il faut donc copier dans le package d'exemple :
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èmes 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.
Pour que le module s'active il faut:
Important: Si vous avez besoin de l'inventaire des hôtes/clusters, il faut que le module soit configuré pour recevoir les données d'inventaires que vous souhaitez gérer via ce Receiver. Pour cela, il faut utiliser les paramètres suivants:
Le module d'exemple a un fonctionnement très simple:
Exemple de communication avec le module via curl:
curl --data 'key=my_value' http://127.0.0.1:9000/my_api |
Modifier le module pour qu'il corresponde à vos attentes
Il est important de bien lire les commentaires dans le code d'exemple avant toute modification.
Le code est divisé en deux parties:
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:
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 de s'assurer une stabilité dans le temps:
Les méthodes que vous pouvez surcharger sont multiples.
Méthodes surchargeables concernant le fonctionnement global du worker:
ATTENTION: toutes les autres méthodes (exceptées init_worker_before_main qui est appelée avant le worker_main) sont faites dans des threads différentes. Vous devez donc faire attention à l'accès concurrent de vos données. |
Les méthodes concernant l'inventaire des hôtes:
Lorsque l'inventaire est mis à jour, les objets d'inventaires vous sont fournis:
Les méthodes appelables sur ces objets sont:
Pour les hôtes et les clusters:
Concernant les checks, les méthodes appelables sont:
| IMPORTANT: aucune modification ne doit être faite sur ces objets. Seules ces méthodes sont à appeler, les autres pouvant modifier l'élément et créer de graves incohérences ou bien être supprimer/renommer dans les futures versions. |
Dans le worker il est possible actuellement d'effectuer les commandes suivantes:
Toutes les commandes doivent avoir une forme telles que:
[EPOCH] NOM_COMMANDE;ARG1;ARG2;ARG3
Dans le module d'exemple, la méthode export_http montre comment définir l'envoi d'un OK pour tous les hôtes de l'inventaire.
Mais ce n'est qu'un exemple. L'important est le bloc pour l'envoi des commandes.
cmd = '[%s] PROCESS_HOST_CHECK_RESULT;%s;0;Is alive' % (int(time.time()), host_name)
logger.info('[%s] Generating a command UP for %s' % (self.get_name(), host_name))
ext = ExternalCommand(cmd)
# give back the check result to the daemon
self.send_object_to_main_daemon(ext) |
Pour pousser un résultat d'hôte/cluster vers les Schedulers
Pour pousser un résultat de check vers les Schedulers
Pour créer une prise en compte sur un hôte/cluster
Pour créer une prise en compte d'élément check.
Pour créer une période de maintenance sur un hôte/cluster.
Pour créer une période de maintenance sur un check d'hôte/cluster.