Tests de la version 0.1. 
Le test a été réalisé en téléchargeant depuis le site une image de machine virtuelle VMWARE que j'ai du convertir en image "XEN" afin de pouvoir l'installer dans le système adéquat. 
Le paramétrage mis au point pour NAGIOS et "bêtement" repris ne fonctionne pas et déclenche un bon paquet d'erreurs ... et certaines options de configuration ne sont pas implémentées (ou ne fonctionnent pas ??), par exemple l'option "cfg_dir" qui permet d'indiquer un répertoire complet à prendre en compte dans le paramétrage. 
Mon modèle était construit sur cette possibilité :

•         Un répertoire pour chaque type d'objet.
•         Un fichier par objet (host, service, administrateur .....

J'aime bien ce style de paramétrage car on peut ainsi éviter de toucher à des paramètres "qui  marchent" et si après une mise à jour quelque chose va de travers l'erreur ne peut être que dans le fichier modifié et celà facilite la gestion du paramétrage dans un système de gestion de configuration (CVS, SVN, GIT .... selon vos préférencesi) 
Les tests avancent, bien que les interfaces WEB fournies ( THRUK et NINJA) ne semblent pas toujours fonctionner correctement. Notamment le statut du dernier test n'est pas toujours visible et des service stoppés restent au vert ... est-ce du aux interfaces ou à Shinken lui même ? 
Mystère, il va falloir investiguer sérieusement. 
Premières pistes d'investigation : 
Il semble que les tests soient bien réalisés par Shinken, son fichier de status est bien mis à jour et a bien l'air de refléter le résultat des tests. Un service stoppé apparaît bien comme stoppé et s'il redémarre son statut est modifié de manière correcte. 
Les deux interfaces fournis (THRUK et NINJA) ne semblent pas bien recevoir (ou interpréter) les changements.

 THRUK a l'air d'avoir bien du mal à retrouver l'état des HOSTS, sauf s'ils sont KO, ils apparaissent alors en rouge. Les hosts actifs restent en état "pending" (un gris terne, pas de beau vert), l'affichage des services, lui, est impeccable. J'ai récupéré une version plus récente (0.66) mais je dois encore voir comment l'installer. Le premier essai n'a pas fonctionné et les logs me signalaient un problème avec "Catalyst". N'étant pas un grand fervent de PERL j'ai du mal à trouver le problème et je suis revenu à la version 0.62. Il lance désespérement un message "Argument "" isn't numeric in numeric gt (>) at /usr/local/shinken/Thruk-0.62/templates/status_detail.tt line 189"

NINJA lui, a du mal à récupérer les status des services ou des hosts, la colonne "Status Information" reste désespérement vide. Il faudrait là aussi que je tente de trouver une nouvelle version.

SHINKEN, j'utilise ici la version 0.1 de fin 2009 qui est la seule disponible à la date de début des tests en téléchargement sur le site.

Cette version ne semble pas bien alimenter le "plugin_status" pour les hosts actifs ce qui explique peut-être le mutisme de THRUK à leur sujet. J'ai par la suite trouvé (essais version 0.3) qu'il s'agissait en fait d'un problème de paramétrage du plugin alors que ces mêmes paramètres fonctionnent sur une machine "Nagios" d'un version assez ancienne, peut-être une mise à jour du plugin Nagios (négative dans mon cas !).

J'ai installé MYSQL-PROXY pour suivre la mise à jour de la base MYSQL utilisée par NINJA, je ne suis pas un fana du "DELETE/INSERT" qui ne simplifie pas les recherches et SHINKEN a l'air de transmettre des données correctes. 
Un des avantages de SHINKEN est de pouvoir alimenter en données diverses applications externes par un système de plugins (conforme Nagios, Mysql, Oracle, ?). 
Je n'ai actuellement pas beaucoup de temps (boulot !) et une machine en panne (carte mère ?) Cela ne favorise pas la recherche de la petite bête car la machine virtuelle est installée sur le zinzin en panne ... et il faut en plus que je classe mes photos de vacances ...

Tout ceci était valable pour la version 0.1, donc une version de développement, ici en fait plus une preuve de concept ou un prototype dont les bases fonctionnent montrant que les choix d'architecture sont corrects et que le choix du langage PYTHON n'est pas forcément une erreur pour ce type de produit où le "fonctionnel" est très important. Sur mon petit réseau de test (quelques machines et services), même en mettant au minimum les délais (vérification toutes les minutes environ) aucune charge perceptible sur la machine. 
L'avantage du choix de PYTHON est une grande portabilité car il n'existe que peu de matériels où Python n'est pas présent.

Dès que la machine sera réparée je reprends les tests ... 
Après quelques jours ... 
Finalement la version 0.1 fonctionne correctement et permet de remplacer mon vieux Nagios sans aucun problème. 
Mais ... la version 0.3 est disponible, je ne m'appesantirais pas plus sur cette version qui pourtant fonctionne. 
Vive la version 0.3.

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.

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 :

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.

Après avoir essuyé quelques plâtres, mais c'est normal pour une version "0.x", j'ai mis en place la version 0.4 (stable) dont les fonctions semblent stables et efficaces. 
Le paramétrage réponds maintenant à mes goûts avec la possibilité de donner des répertoires de paramètres et non plus les fichiers détaillés. Il est ainsi possible d'avoir un fichier par host, un par service et on perd beaucoup moins de temps lors des ajouts car on sait où sont les erreurs : dans le dernier fichier ajouté ! 
Thruk est l'interface que j'ai testé car il est simple à installer depuis son Tarball, simple à paramétrer bien que le XML me donne des boutons ... et il peut très facilement "récupérer" les données depuis plusieurs fournisseurs ce qui est le cas ici avec le réseau principal (royaume par défaut) et le royaume "testweb" fraichement créé. 
L'interface pousse même la bonté (beauté ?) jusqu'à fournir de petits boutons pour afficher ou non chaque royaume. On peut ainsi afficher un royaume quelconque, ou les deux, aussi bien parmi les "hosts" que parmi les services. 
Il existe plusieurs "skins" pour cet interface mais je préfère pour le moment le skin par défaut défaut qui ressemble beaucoup à Nagios. 
Cet interface est muni de certains perfectionnements très agréables, par exemple : 
- cliquer sur quelques ligne sélectionne les hosts/services et une boîte de dialogue permet de leur appliquer un traitement commun ... check immédiat, suspension des contrôles etc. 
Je vais préparer quelques belles images et une petite explication sur le paramétrage adopté ici. 
D'abord des images : 
 
Admirez les deux "boutons" verts (en haut à gauche) qui vous permettent de sélectionner un "royaume" ou les deux. 
Pour le reste l'aspect reste très "Nagios". 
 
Ici j'ai sélectionné quelques "hosts" et la fenêtre d'action s'est ouverte, il est possible de réaliser les actions "standard" de Nagios "reschedule check", "enable notifications" ..... 
C'est beau ! 
Pour le paramétrage de THRUK il suffit d'ajouter un "peer" dans le fichier de configuration : 
  <peer> 
        name   = Local 
        type   = livestatus 
        <options> 
            peer    = 127.0.0.1:50000 
       </options> 
  </peer> 
  <peer> 
        name   = Testweb 
        type   = livestatus 
        <options> 
            peer    = 192.168.1.120:50000 
       </options> 
  </peer> 
Les noms indiqués apparaîtrons dans les boutons de sélection de royaume. 
Il faut bien entendu que le module "Livestatus" soit activé dans la configuration de Shinken : 
define broker{ 
       broker_name      broker-1 
       address          localhost 
       port             7772 
       spare            0 
       modules           Status-Dat, Simple-log, Livestatus 
       manage_sub_realms 1    
       manage_arbiters   1     
       realm    Local 
       } 
Et le module lui même : 
define module{ 
       module_name      Livestatus 
       module_type      livestatus 
       host             *        
       port             50000   ; port to listen 
       database_file    /var/lib/shinken/livestatus.db 
} 
Le port peut être changé mais il ne faut pas oublier la communication avec Thruk ! 

Je vais maintenant essayer Ninja, mais l'installation de Merlin + Ninja + la base Mysql me semble complexe. 

En bref la version 0.4 de SHINKEN semble stable et agréable à utiliser.

J'ai un peu délaissé SHINKEN (Nagios "like") depuis un certain temps. Or la version 1 est sortie et j'ai vite téléchargé la version 1.0.1 depuis leur site.

Le tarball a un peu grossi et je décidé de l'installer dans une machine virtuelle "vierge". J'ai installé une Debian stable depuis une image cd CD et effectué immédiatement une mise à jour complète avec le couple magique : 
apt-get update 
apt-get upgrade

Il y a déjà un certain temps j'avais testé Shinken dans différentes version de la 0.4 à la 1.0.1. C'est un bon candidat au remplacement pour la supervision de l'inévitable Nagios. La version 1.2 étant sortie j'ai eu envie de voir ce que ce logiciel était devenu car son développement semblait rapide et j'étais curieux de voir les progrès accomplis.

Afin de tester complètement j'ai démarré une nouvelle machine virtuelle (Debian 6 en 64 bits) pour un environnement performant. Les pré-requis sont assez simples, l'installeur s'occupe presque de tout ! 
Cet installeur permet d'installer le logiciel principal (avec tous les pré-requis) sans aucune difficulté et il semble fonctionner non seulement pour Debian mais aussi pour Redhat, Fedora et probablement CentOs. 
Il permet ensuite d'installer d'autres modules tels que des plugins différents de ceux de Nagios et qui "valent le coup" : 
Accès en supervision par SNMP pour les machines Unix/Linux, Accès en WMI pour Windows ... 
On peut aussi installer quelques compléments tels que PNP4NAGIOS, mais chaque chose en son temps. 
La philosophie du produit, fonctionnement en plusieurs tâches indépendantes, est très intéressante par la variété des configurations qui peuvent être gérées sans complication majeure.