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 :
|
| 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 :
|
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.