Shinken 0.8 (Guilty Guecko) pointe le bout de son nez
Depuis la dernière version fin juin, les auteurs de Shinken n’avaient pas trop fait parlé d’eux. Ils étaient loin d’être endormis pour autant , car voici poindra la version 0.8, avec son lot de nouveautés!
Des améliorations dans le cœur de la supervision
La toute première est une amélioration du système central de Shinken, à savoir la gestion des priorité et la recherche des causes. Il est désormais possible de moduler l’importance d’un élément suivant une période de temps. Ainsi, un serveur de paie pourra n’être « important » que trois jours par mois.
Vient ensuite une amélioration des règles métiers, avec la possibilité de définir des seuils de modes « dégradés » pour les indicateurs, et une amélioration des options de corrections d’erreurs avec par défaut une désactivation de ces commandes quand l’élément est en période de maintenance.
Un module GLPI fonctionnel
L’une des deux grandes nouveautés réside dans un module GLPI totalement réécrit par un membre du projet FUsionInventry et désormais pleinement fonctionnel. Shinken peut utiliser GLPI en backend tant pour charger sa configuration que pour exporter les données de disponibilité via le plugin Monitoring compatible GLPI 0.80.x. Ce GLPI plugin est encore en pré-Alpha, mais devrait vite évoluer dans les prochains jours / semaines.
Pour rappel, GLPI est intéressant comme source de configuration a déjà l’inventaire du matériel (serveurs, switchs) via la remontée d’inventaire de FUsionInventory. De ce fait, le plugin se sert des informations telles que les partitions, les logiciels installer, les ports de switchs… et le plugin monitoring peut suggérer des services à superviser comme sur la capture d’écran suivante :
Ce lien entre les deux outils repose sur deux modules :
- GLPI (module de l’Arbiter) qui va se connecter en webservice à GLPI et récupérer toute sa configuration (services, hosts, contacts, timeperiods et commandes). cette opération se fait au démarrage de l’Arbiter,
- glpidb (module Broker) qui va envoyer les checks à GLPI directement dans la base de donnéé.
Voici à quoi ressemblent les alertes dans GLPI :
Et avec un exemple de règle métier :
Et son détail :
Le gros morceau de cette version : la WebUI Shinken!
Les objectifs du projet Shinken
Le projet Shinken a été lancé pour pallier les manques de Nagios pour les problématiques d’aujourd’hui. Il a donc été géré comme un simple outil devant replacer le core de Nagios. Cet objectif a été atteint avec la finalisation de l’architecture distribué dans la version précédente et de la mise en place de nombreuses améliorations dans le cœur de la supervision (notion d’importance, recherche de la source des problèmes, périodes de maintenances simple à mettre en place, etc).
Comme annoncé dans l’interview de Jean Gabès par Nicolargo, le projet suit les demandes de ses utilisateurs, et va donc dépasser le stade du simple outil, vers celui de la solution de supervision, tout en gardant le plus possible son aspect modulaire. Après un premier module de découverte dans la précédente version, nous avons le droit ce coup-ci à rien de moins qu’une interface Web dédiée à Shinken!
Pourquoi une nouvelle interface?
Pourquoi une nouvelle interface alors qu’il y en a déjà tellement d’autres? Celle-ci tente de mettre en avant ce que Shinken a apporté dans le cœur de la supervision, à savoir les notions d’importances et la différentiation très nette entre problème source et impacts, chose que ne font pas les autres interfaces et qui est pourtant la base de ce que les administrateurs et responsables d’infrastructures veulent voir.
Fidèle à ce qui fait la force de ce projet, l’architecture de cette interface est assez originale, car elle n’utilise pas de base de données. Multiplateforme (Linux/Windows) et ne nécessitant pas de serveur web de type Apache, elle se place au sein d’un daemon Shinken, et permet donc d’avoir sans difficulté une interface Web hautement disponible! Sans base de données et travaillant totalement en mémoire, sa vitesse d’exécution est également très importante, et peux être utilisé pour des parcs très importants sans craintes.
Une ergonomie innovante
Un travail très important a été fait sur l’ergonomie. Elle est ainsi truffée de technologie dites HTML5, avec des effets d’opacités ou de transitions très agréables visuellement, mais également très pratique pour que l’utilisateur se focalise sur les informations importantes ne priorités. Les notions de hiérarchies de type réseaux ou logique (comme une interface web qui dépends d’un serveur de base de données par exemple, ou une machine virtuelle qui dépends de son hôte physique) sont omniprésents, que ce soit sous forme d’arbre ou de graphique.
Gérant les connexions par mot de passes Apache ou dans Active Directory, elle permet également de définir ses propres packs d’icônes comme le fait NagVis. Plusieurs sont d’ailleurs proposés de base comme des serveurs ou des icônes réseaux ou de base de données. Elle se permet également quelques fantaisies comme le fait d’importer la photo des administrateurs d’Active Directory, ou de proposer à l’utilisateur de lancer une commande par un simple geste de souris
Fini les mots, place au show
Voici la vue pour les managers, qui sauront en un clin d’œil quelles sont les applications critiques tombées, et la présentation de l’arbre de dépendance afin de voir le ou les problèmes sources.
Pour les managers ayant un navigateur supportant WebGL, cette vue est également disponible en 3d :
Pour les administrateurs, la vue proposée liste tous les problèmes sources, le tout trié par ordre d’importance de leurs impacts. Ainsi, cette veue peux se résumer en « voici ce qu’il faut régler, dans cet ordre », ce qui tranche avec les autres interfaces du monde Nagios qui mélangent les notions de problèmes sources et leurs impacts. Ceci permet d’avoir des vues bien plus concises et lisibles pour les administrateurs. Ils peuvent évidement lister les impacts simplement ou lancer des commandes sur plusieurs problèmes sources en même temps.
Avec l’affichage d’impacts (également triés sur leurs importances) pour un élément par exemple :
La vue de détail d’un élément fait également la différenciation entre problème source et impacts. Par exemple, pour un problème source, elle listera ses impacts, toujours triés par ordre d’importance :
Et inversement pour un impact :
Il est à noter que la vue en arbre des dépendances présentée ici est également valable pour les relations de type réseaux (switch<->serveur) ou applicative (Web->bdd) mais également pour les règles métiers (comme ici notre ERP).
Cerise sur le gâteau, ces liaisons peuvent être suivies de manière plus graphique sur une carte comme sur l’exemple suivant :
Il est a noté qu’ici ne sont pas uniquement présentés les hôtes et les liaisons réseaux, mais toutes les dépendances et services. Un effort particulier a été fait afin de permettre une bonne visibilité de la carte, même dans un environnement très dense, afin que l’utilisateur ne voit que ce qui l’intéresse lorsqu’il est sur un élément particulier.
Pour ceux qui veulent se faire une idée, une plate forme de démonstration est disponible sur http://demo-shinken.web4all.fr:7767/ (comtpe admin/admin), celle-ci étant gracieusement hébergée par l’hébergeur associatif Web4all que toute l’équipe de Shinken remercie chaleureusement!
Et pour la prochaine version?
Cette version 0.8 inaugure le virage de Shinken vers une solution complète du type Zabbix ou Centreon. L’interface va encore fortement évoluer, avec plus de liens vers d’autres interfaces comme PNP, NagVis, Thruk ou même Centreon. L’équipe des développeurs s’est encore agrandie avec cette version, ce qui promet une version 1.0 très prometteuse pour la fin de l’année, et des outils pour aider aux installations et premiers pas dans la supervision