Shinken : tagguez vos pollers

Posted in Shinken by Nap on May 5, 2010

Découpage organisationnel/technique

Dans l’Architecture de Shinken, un point important concerne les Realms (royaumes) qui servent à découper dans pans entiers d’infrastructure, comme un site distant par exemple, ou bien un client pour une entreprise qui propose une prestation de supervision.

Ce découpage est donc soit organisationnel, soit technique. Mais pour ce dernier, le choix du découpage se fait sur des critères géographiques, en terme de réseau principalement (pour ne pas avoir de fréquentes communications inter-continents par exemple).

Shinken fonctionne sur Windows (avec des services et tout et tout), et il est donc tentant de placer un poller sur un tel OS afin de lancer directement ses checks depuis une machine (et un compte de domaine) qui a les droits sur les autres machines, pour faire du WMI par exemple.

Mais comment faire en sorte que les commandes pour Windows partent sur ces pollers “Windows” et pas les classiques pollers “Linux”? On peut se dire que l’on utilise les realms, mais ce n’est pas une bonne idée en fait. Les realms sont des cloisonnements, il n’y a pas d’échange entre les schedulers (même au sein d’un realm d’ailleurs). Donc si un administrateur défini un Realm Linux et un Realm Windows, il va pouvoir obtenir l’effet souhaité (des commandes qui vont sur les bons pollers), mais à un prix énorme : plus de liens (dépendances) entre les hôtes Linux et Windows…

Cloisonnement technique

C’est pour cela que dans un même realm, il doit être possible de cloisonner “techniquement” les commandes sur des pollers. Ce cloisonnement, qui va être optionnel bien sûr, se fera dans la configuration avec une nouvelle option : poller_tag. Comme son nom l’indique, un poller va avoir un ou plusieurs tags, et les checks vont pouvoir également être taggués.

Si le tag au niveau des pollers est simple, se pose la question du tag des commandes : à quel niveau doit-on tagguer? commands, services, hosts? Et pourquoi pas les 3 finalement? L’héritage serait host->service->commands.

Le tag des commands est simple : une commande définie comme un exe au sens windows (PE et non pas ELF) sera naturellement tagguée “windows-poller”. Les tags au niveau service/hosts seraient un peu comme un “mini-realm” : au lieu de définir un realm complet (avec un couple scheduler/poller) pour une DMZ par exemple, il peut être pratique de juste dédier un poller (ou deux) dans cet environnement, et de tagguer les hôtes/services.

Un mini-realm?

Ceci n’est pas complètement orthogonal aux realms je l’admets, mais c’est plus une réponse aux “proxy nrpe windows” qu’à un réel besoin organisationnel que proposent les Realms.

Au passage, cette implémentation va être un bon exemple de “Hack” possible de Shinken. Je vais essayer de noter/expliquer l’implémentation dans un document afin de montrer que développer pour Shinken n’est pas complexe, loin de là :)

Related Posts: