L’interface de visualisation

Outre un léger relooking de l’interface et de meilleures capacités pour filtrer les informations, la principale nouveauté de cette version est l’arrivée d’un tableau de bord. L’utilisateur pouvant sélectionner des « widgets » et les placer à sa guise sur sa page personnalisée.

L’installation pour les feignants


curl -L http://install.shinken-monitoring.org | /bin/bash


 Et c’est fini

Scalabilité de la supervision passive

La partie configuration

On note ainsi l’arrivée de découverte des équipements en plusieurs phases au lieu d’une seule. Par exemple, une première phase basée sur Nmap pouvant découvrir les principales caractéristiques des équipements (OS, ports ouverts, fabricant du matériel, …), et de nouvelles sondes de découvertes pouvant être lancés sur les équipements respectant certains critères (comme ne scanner les partages réseaux que sur les Windows par exemple).

Autre point intéressant de cette version, l’apparition de moyens d’échanger des bonnes pratiques de supervision. Si dans le microcosme Nagios le partage de sondes de supervision est courant, celui du partage des bonnes pratiques de la configuration de ces sondes l’est beaucoup moins. Or une bonne partie de la bonne gestion de gros environnements passe par ces bonnes pratiques. Shinken propose un outil (shinken-pack) permettant d’extraire de la configuration ce qui a trait à un sujet particulier (Linux, Windows, etc) comme la configuration des sondes ou les règles de découvertes, et d’en faire une archive. Un site communautaire http://community.shinken-monitoring.org a été mis en place pour faciliter leur partage.

Dernier point de la partie configuration est l’arrivée en beta de l’outil de configuration de Shinken, nommé sKonf. Il permet d’utiliser la bibliothèque de découverte de l’outil, mais également la configuration plus classique des éléments. Il est également capable d’aller rechercher de nouveaux packs de supervision directement sur le site communautaire du projet.

Corrélation avancée et calcul de KPI : les triggers

Un autre outil important en matière de supervision est Zabbix. ce dernier repose sur l’obtention de données de performances qui sont analysée par des expressions dites « triggers », là où Nagios, et donc Shinken, laisse cette tâche aux sondes.

Shinken inaugure dans cette version ses propres triggers. Ces derniers n’ont pas pour but d’être utilisés pour toute la supervision, mais dans les cas où l’utilisation des sondes n’est plus adaptée. Ces triggers sont tout simplement du code Python qui sera lancé après les sondes au sein même de l’outil, et ayant accès à toutes ses données.

Ils pourront être utilisés pour définir des règles métiers complexes, où de simples opérateurs & | Xof: ne sont plus assez complets, ou encore dans le calcul de nouveaux indicateurs, comme calculer la moyenne du temps de réponse de serveurs web déjà supervisés, et alerter si elle devient trop importante. Le principal atout de ce système étant que les données étant réinjectées directement au sein de l’outil, elles seront disponibles avec les interfaces actuelles de supervision.

Un autre module fait appel à ce système : le module Collectd. L’outil du même nom est un agent exportant sur le réseau les données de performances des serveurs. Shinken est désormais capable d’écouter ces informations et les transformer en données de performances pour ses propres services. Des triggers peuvent alors être utilisés pour comparer les valeurs à des seuils, et lever des alertes si besoin est.

On notera enfin des améliorations importantes du côté du temps de démarrage sur les gros environnements, ce qui est toujours bon à prendre

Prochaine version

Les développements actuels sont orientés vers la complétion de l’interface de configuration sKonf, ainsi que le rajout de nouvelles fonctions aux triggers et la possibilité à des modules externes d’en fournir des nouvelles.