Le script en question permet les actions suivantes :

• Installer shinken (et le supprimer, mais personne ne l’utilise )
• Sauvegarder et restaurer la configuration, les logs et les plugins installés (utile en phase de mise a jour)
• Effectuer une rotation des logs (avec compression)
• Paramétrer les démons devant être activés (dans une architecture distribuée c’est utile)

L’installation prend en charge les distributions basées sur Debian, Redhat 5.5 et 6.x et bientôt Suse Linux Enterprise Server (en version 10 et 11). Bon soyons honnête, le script à été intensivement testé sous Debian 6 et Ubuntu > 10.04. Il semble correctement fonctionner sour RedHat/Centos 6 et doit être testé de manière approfondie sur Debian 5 et Ubuntu < 10.04. Et pour cela rien de mieux que d’impliquer la communauté !

Le script se charge de tout ! Installation des dépendance et paramétrage. Après installation il suffit de le lancer.

Bien sur un ordonnanceur de supervision sans « plugins » de supervision ne serait pas très utile. Le script prend en charge l’installation d’un ensemble de plugins :

• check_esx3
• nagios-plugins
• check_oracle_health
• check_mysql_health
• check_wmi_plus
• check_mongodb
• check_emc_clariion
• check_nwc_health
• check_hpasm
• capture_plugin

En dehors des plugins, le script permet d’ajouter quelques « addons » bien utiles.

• pnp4nagios pour la métrologie
• l’interface multisite du projet check_mk pour la console (elle complète bien l’interface native de shinken)
• Nagvis devrait apparaître d’ici la version 1.0
• Sans oublier l’interface native de shinken qui apporte pas mal d’innovations

Un exemple d’utilisation est présent dans le wiki : http://wiki.monitoring-fr.org/shinken/shinken-install

L’école centrale utilise GLPI + FusionInventory et a besoin de gérer le monitoring de ses serveurs facilement, et si possible dans une console centrale, soit GLPI. Guillaume Capiod est à l’origine de cette collaboration.

siprossii utilise et contribue à GLPI (partenaire officiel GOLD) ainsi que sur le projet FusionInventory via son développeur David Durieux (contributeur GLPI, co-leader FusionInventory). Grâce aux relations avec Jean Gabès, le système de monitoring utilisé avec le plugin Monitoring est Shinken.

Les buts de ce plugin :

• Se baser sur l’inventaire du matériel pour définir automatiquement les services à monitorer.
• Visualiser l’état des ressources dans la fiche d’un matériel.
• Une vue synthétique sous forme de tableau de bord
• Délégation du monitoring possible par l’utilisation des entités de GLPI.
• Le monitoring peut-être visualisé en « temps réel » via la remontée des derniers contrôles ou sur une période via les graphiques RRDs.
• Avoir des modèles génériques pour RRDTOOL au format JSON (https://github.com/rrdtooltemplates)
  

Voici les parties développées sous license AGPLv3 :

• Module Arbiter et Broker pour le plugin Monitoring de Shinken développé et intégré dans la dernière release de Shinken (0.8.1)
• Plugin Monitoring pour GLPI 0.80.x
• Application Android

Fichiers à télécharger :

• Plugin Monitoring 0.80+1.1
• Application Android
• Documentation :
  • en anglais
  • en français

Démo :

http://pluginmonitoringdemo.siprossii.com/
login : monitoring
mot de passe : monitoring

Si vous souhaitez tester l’application Android, voici les informations :
url : http://pluginmonitoringdemo.siprossii.com/
login : android
mot de passe : android

Remerciements :

Merci à ceux qui ont aidé pour ce plugin : Guillaume Capiod, David Durieux, Jean Gabes, David Hannequin, Matieu Simon, Fabrice Flore-Thébault

Captures d’écran :

• Schéma de fonctionnement

  

• Vue des évènements de catalogues de composants

  

• Vue des évènements de toutes les ressources

  

• Vue des évènements à partir de la fiche d’un équipement (ordinateur dans ce cas)

  

• Vue de l’application Android

  

Un rattrapage des derniers manques par rapport à Nagios

Comme à leur habitude, les développeurs de l’outil, compatible avec Nagios et sa myriade de plugins, ne se sont pas tournés les pouces. Cette version était destinée à régler tous les derniers points qui manquaient par rapport à son grand frère :

• Chargement des données de rétention au format Nagios
• Gestion des caractères ! et * dans les associations services sur hôtes
• Les commandes de données de performances sont gérées (comme celles de Centreon par exemple)
• Gestion des variables d’environnements _NAGIOS* pour les sondes

L’utilisateur n’a ainsi plus à craindre de perdre des fonctionnalités en passant de Nagios à Shinken. C’est aussi simple que de lancer ce dernier avec les fichiers de configurations de l’honorable star de la supervision (et d’avoir avec quelques lignes de plus une architecture performantes, distribuée et hautement disponible…).

Des nouvelles fonctionnalités

Ils n’ont pu cependant s’empêcher de rajouter quelques nouvelles fonctionnalités au passage :

• L’apparition des « service generators » dont nous reparlerons par la suite
• Serveur NSCA intégré au cœur de la solution sous la forme de module
• Apparition de la sauvegarde des données entre les redémarrages dans un serveur memcache ou redis afin d’offrir une méthode distribuée et redondante entre les nœuds de ces données si importantes
• Les macros utilisateurs peuvent avoir des vrais noms, SONDESDIR est plus explicite que la célèbre valeur USER1 par exemple pour fournir le répertoire des sondes…

Outre ces nouvelles fonctionnalités, cette version a été l’occasion de mettre en place un modèle de développement dirigé par les tests, ce qui a permis de détecter/régler bon nombre de bugs. Cette version est utilisée en production chez son auteur et se révèle très stable.

Focus sur les générateurs de services

Revenons un peu sur les générateurs de services. L’idée principale de ces dernier est de recentrer un peu les données des hôtes dans la définition de ces derniers et de générer des services à la volée.

Par exemple, si un utilisateur veut superviser les espaces disques d’un serveur, il pourra les déclarer sur son hôtes comme suit :

define host {

host_name  serveur-fichier

_disks     C,D,E

Et pour avoir un service pour chaque disque, l’utilisateur n’a plus qu’à déclarer un unique service dans leur configuration :

define service {

service_description  Espace disque $KEY$

duplicate_foreach   _disk

C’est encore plus utilise pour nos chers administrateurs réseaux qui doivent définir un service par port d’un équipement. Maintenant ils peuvent définir pour une « pile de 6 switchs » avec 48 ports chacun :

define host {

host_name switch-prinicpal

_ports  Switch [1-6] Port [1-48]

Et le service

define service {

service_description  Etat port $KEY$

duplicate_foreach  _ports

Ainsi l’utilisateur a automatiquement 6*48 = 288 services en quelques lignes !

Pour le tester facilement

Comme à son habitude, l’équipe de Shinken fourni son outil sous forme de source installable facilement sur GNU/Linux ou Windows, mais également sous la forme d’une machine virtuelle pré-installée avec les interfaces de visualisation Thruk, Ninja et NagVis

Le tout est disponible sur le site officiel de l’outil : http://www.shinken-monitoring.org/download/

Aperçu de la roadmap

Cette version était importante pour le projet car c’est la première a être installable sereinement en production. Maintenant que les dernières fonctionnalités manquantes de Nagios sont rattrapées, il est temps pour l’équipe de repartir de plus belle vers des améliorations toujours plus intéressantes pour ses utilisateurs. Les principales nouvelles fonctionnalités de la version 0.5 seront :

• Escalades de notifications basées sur le temps au lieu du nombre de notifications afin de plus facilement coller à la notion de SLA
• « Cluster/business correlation » est une fonctionnalités pour agréger facilement des données de plusieurs services en un seul afin de représenter efficacement une application métier avec des règles puissantes comme des « et » ou des « ou ». C’est un peu un « addon business correlator » mais intégré dans le cœur afin de faciliter la configuration et d’avoir une sortie unifiée vers les interfaces de visualisation et la notion de problème/impacts déjà présente dans Shinken
• L’arrivée de la notion de « criticité » des environnements afin de permettre aux utilisateurs de savoir facilement et rapidement ce sur quoi ils doivent travailler en priorité, et de faciliter la configuration dans le cadre des envois de SMS par exemple
• la possibilité d’avoir des « downtimes » de contacts afin de pouvoir gérer facilement les vacances des utilisateurs

Les bases de l’outil étant bien posées, et les méthodes de développement efficaces étant bien intégrées, cette version ne devrait pas tarder à arriver

Pour participer

L’équipe de développement est très ouverte, et toutes les aides sont les bienvenues. Vous pouvez obtenir les informations sur la mailing list sur la page http://www.shinken-monitoring.org/project-and-contact/ ou tout simplement voter pour vos choix d’orientations du projet sur le site des idées de Shinken disponible sur http://shinken.ideascale.com/ (inscription optionnelle). Si vous avez une idée pour améliorer l’outil, c’est le meilleur moyen de le dire