Shinken : version 0.4

Shinken : version 0.4 jpp sam 18/12/2010 - 23:25

Après installation dans "/usr/local" la version 0.4 semble très stable. Au passage j'ai installé la version 0.72 de Thruk qui s'avère très agréable à l'usage, la nouveauté : les "realms" ou royaumes.
Comme déjà dit dans un article précédent l'esthétique de cet interface est très proche de celle de l'interface de Nagios, mais il s'avère que c'est plein de petits "plus" qui facilitent la vie.
La communication avec Shinken est impeccable, vous pouvez en quelques clics demander le rafraîchissement d'un service, d'un hôte, de tous les hôtes ...
Revenons-en à ma création de "royaume". Un royaume doit comporter 4 des 5 modules principaux : poller,broker,actionner et scheduler. La seule chose qui lui manque est un arbiter capable de gérer la description des hosts/services à surveiller.
Le paramétrage s'effectue donc principalement au niveau de l'arbiter sur la machine "centrale". Il faut indiquer à l'arbiter la création d'un "realm" et décrire les quatre modules liés à ce royaume. Il en sera de même dans les fichiers décrivant les hosts et les services.
Les fichiers de paramétrage sont présentés ci-dessous :

define realm { realm_name testweb default 0 }	D'abord le "realm" c'est la partie la plus simple, donner un nom et dire que ce n'est pas le royaume par défaut.
define scheduler{ scheduler_name scheduler-web address 192.168.1.120 port 7768 spare 0 weight 1 realm testweb }	A tout seigneur, tout honneur, on commence par le maître des lieux, c'est lui qui contrôlera ce royaume pour y distribuer le boulot ... il doit être défini par un nom, une IP, un port, un poids (ici 1) le fait qu'il n'est pas un "spare" et l'appartenance au royaume "testweb".
define reactionner{ reactionner_name reactionner-web address 192.168.1.120 port 7769 spare 0 manage_sub_realms 0 min_workers 1 max_workers 5 polling_interval 3 realm testweb }	Le même genre de définition nécessaire à la communication, nom; IP, port, royaume plus quelques paramètres propres : max et min workers (pensez au MaxServer et MinServer de Apache) Polling interval
define broker{ broker_name broker-web address 192.168.1.120 port 7772 spare 0 modules Status-Dat, Simple-log, Livestatus # , ToMerlindb_Mysql manage_sub_realms 1 manage_arbiters 0 realm testweb }	Toujours le même style de paramérage avec les paramètres spécifiques des "modules" à activer, ici je n'ai pas activé la liaison "Mysql" car la liaison est à faire avec un nouveau schéma de la base de données. Je vais essayer de voir avec les versions les plus récentes de Ninja. Pour le moment la liaison Mysql est inactivée. C'est pourtant la seule manière de centraliser les données issues du royaume.
define poller{ poller_name poller-web address 192.168.1.120 port 7771 manage_sub_realms 0 min_workers 2 max_workers 2 processes_by_worker 127 polling_interval 5 realm testweb }	Encore le même paramétrage avec les spécifiques : min et max workers processes_by_worker polling interval

Du coté du serveur hébergeant notre "royaume" le paramétrage est beaucoup plus simple et peut être réalisé une fois pour toutes car cela se limite à un "bloc" de définitions pour chaque module. Les quatre fichiers ont d'ailleurs strictement la même syntaxe, je les ait nommes my_broker.ini, my_pollerd.ini, my_reactionnerd.ini et my_reactionnerd.ini. Le contenu est standard et corresponds à ceci :
[daemon]
#relative from this cfg file
workdir=/var/lib/shinken
pidfile=%(workdir)s/brokerd.pid
interval_poll=5
maxfd=1024
port=7772
host=0.0.0.0
user=shinken
group=shinken
idontcareaboutsecurity=no
Il faut bien sûr faire varier le fichier de "pid" et le port pour chacun des modules. Les ports sont un peu "standardisés" et il est plus simple d'utiliser toujours les mêmes :

7768 : scheduler
7769 : reactionner
7771 : poller
7772 : broker

Cela permet d'éviter de faire des "noeuds" difficiles à démonter.
Pour la description des "hôtes" il suffit d'y ajouter une ligen "realm testweb" et le tour est joué :
define host{
        use                     generic-host
        host_name               xxxxxx
        alias                   testweb_frontal
        address                 xxxxxx
        check_command           check_ping!4.0,80%!10.0,80%!
        realm                   testweb
        max_check_attempts      3
        notification_interval   1800
        notification_period     24x7
        notification_options    d,u,r
        register                1
        }
Pour les services le standard est suffisant, ils suivent le sort de leur hôte :
define service {
        use                     generic-HTTP
        host_name               xxxxxxxx
        name                    HTTP-XXX
        contact_groups          virtuel
        notification_interval   480
        check_command           check_http_auth!/index.php!user:password!
        normal_check_interval   200
        check_interval          10
}

Et le résultat me direz-vous ... et bien cela marche, et même fort bien dès que vous avez commencé à décrire quelques hôtes et services dans votre nouveau royaume.
Lorsque tout fonctionne vous voulez pouvoir suivre vos hosts/services en direct d'une seule et même console ... et cela marche, au moins avec THRUK, pour NINJA la version dont je dispose (fournie avec SHINKEN 0.3) ne fonctionne pas avec SHINKEN 0.4 car il faut une version plus récente et l'installation de Ninja suppose d'installer d'autres packages ... bref dans un premier temps je reste avec THRUK. Voir l'article suivant pour des précisions sur le paramétrage hosts + services et celui de Thruk.