J'ai d'abord essayé d'installer de manière standard la version 0.3 téléchargée depuis le site. L'installation en elle même s'est bien passée mais le lancement provoque une erreur du module ARBITER car il n'arrive pas à ouvrir le "egg" et dit : ce n'est pas un répertoire.
N'étant pas un spécialiste de Python ni versé dans les oeufs je n'ai pas pu déboguer ce problème. Il s'est avéré par la suite que la version était une version en cours d'évolution vers la version 0.4.
J'ai ensuite téléchargé l'image (VMWARE) d'une machine pré-installée. La conversion en image XEN a fort bien fonctionné.
La manipulation (http://wiki.xensource.com/xenwiki/VMDKImage) fonctionne parfaitement, après un :
qemu-img convert -f vmdk temporary_image.vmdk -O raw xen_compatible.img
on dispose d'une image Xénifiée (Xénisée ?) qui ne demande plus qu'un petit paramétrage pour démarrer.
Le premier lancement est réussi et les deux interfaces fournis (Thruk et Ninja) ont progressé en numéro de version et semblent OK.
Il faut maintenant essayer de réaliser une installation personnelle, un peu plus "standard" que tous les fichiers dans le HOME de SHINKEN, et surtout qui utilise un paramétrage un peu plus complet et qui répond à mes besoins (et possibilités, malgré la virtualisation je n'ai pas 100 serveurs !).
Après une petite remise en ordre des scripts (à mon goût) tout démarre et les tests vers mes petits "services" débutent. Les différents modules communiquent fort bien et font leur boulot très convenablement.
Un petit tour dans les interfaces graphiques, Thruk a une esthétique qui se rapproche de cette de Nagios, on est donc en pays de connaissance. Dans le cas de Ninja l'esthétique est radicalement différente mais semble offrir des fonctionnalités équivalentes.
Toutefois les "hosts" ne présentent pas de status valable, ils reflètent plus ou moins le status des services attachés. Il semble que les fonctions indépendantes de "check" liées aux hosts soient inopérantes ou désactivées, mais je n'ai encore trouvé aucun moyen de les réactiver.
Pourtant du coté du paramétrage des host il est bien indiqué une "check_command" qui, lancé à la main fonctionne normalement.
Une inspection rapide du fichier "status.dat" géré par Shinken montre que le statut des hosts ("plugin_output") n'est pas mis à jour, comment réactiver cette fonctionnalité pourtant essentielle ?
Après quelque recherches je me suis aperçu que la commande utilisée pour le "check" du host était mal paramétrée (niveau "warning" inférieur au niveau "critical" ! ). Un fois ceci réparé tout rentre dans l'ordre et tous les tests passent au vert. Par contre aucun message n'indiquait ce qui se passait réellement et cela marchait avec Nagios.
Je vais maintenant essayer une autre fonctionnalité qui est un des phares de ce logiciel : la facilité de déporter une partie des travaux sur une autre machine. Ici je vais tenter de contrôler un petit réseau complètement disjoint et constitué de 4 machines :
- Un "frontal" (Haproxy)
- Deux serveurs WEB Apache
- Un serveur de base de données Mysql alimentant les deux serveurs WEB
Le serveur frontal est le seul accessible "de l'extérieur", c'est donc lui qui va porter les éléments nécessaires et tester ainsi les possibilités des "royaumes" et de la distribution des modules.
Cette version m'a donné bien du fil à retordre car le "central" n'arrivait pas à contacter le "scheduler" distant. L'équipe de développement a été très efficace et après quelques ajustements de code tout est rentré dans l'ordre et communique avec discipline. Depuis la version 0.4 a été "libérée" et j'ai continué les tests avec celle-ci qui intègre toutes les modifications faites précédemment.
Ce n'est que le début, il faut maintenant ajuster les différents "hosts" et "services" sur ce nouveau réseau.
A suivre ...
... probablement dans un autre article car il va y avoir des tas de choses à dire.