En ce début d’année 2012, nous avons décidé de vous tenir au courant des principales activités de la communauté Monitoring-fr. Que cela soit au niveau des forums ou du wiki, nous ferons une fois par mois, un bilan des nouveautés sur le wiki et des sujets les plus actifs sur notre forum.

Ces articles ont donc un double objectif:

• informer la communauté des activités du mois passé
• mettre en lumière les contributeurs

Bon arrêtons là la parlotte, et commençons plutôt le bilan des principales activités du mois de janvier 2012 sur Monitoring-fr .

Quoi de neuf sur le wiki ?

Voici les nouveautés de janvier:

- Boîte à outils Nagios pour les débutants
- Superviser un hôte Windows avec NSClient++
- Installation de Shinken par script
- Installation de Graylog2

N’oubliez pas de vous inscrire sur le wiki afin de pouvoir participer à l’élaboration de ces tutoriels, guides de bonne pratique et d’informations concernant des solutions Open Source. Et tout le monde peut y prendre part !

Tendances du forum

Parmi les topics (résolus) ayant eu le plus d’activité sur ce dernier mois:

- FAN Trap SNMP / MATCH & status
- Centreon: Connection failed, please contact your admin (pb mysql)
- Nagios Installation et paramétrage des notifications par mail
- Nagios Notifications Escalations
- Shinken event_handler
- Redémarrage Shinken
- Shinken et les droits entre plugins (check_mk)
- Shinken Problème kill après timeout
- Utilisation du livestatus de shinken
- Ouvrir un terminal SSH sur hôte depuis l’interface Zabbix
- Zabbix Configuration email – reception intempestive d’email
- Différencier perte de la machine et perte de l’agent Zabbix

Et la liste est encore longue sur le forum…

Remerciements à nos contributeurs les plus actifs

A ceux qui ont pu prendre le temps de rédiger des pages wiki et participer au forum:

Olivier JAN, David GUENAULT, Ludovic VALENTIN, Funkyman, surcouf, pitpoule, naparuba, …

Merci les gars !

Rejoignez-vous aussi le mouvement …

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

  

L’année 2011 a vu le monde de la Supervision s’orienter vers une nouvelle destination… La problématique de performance dans les grands environnements et la supervision métier.

Fais-moi une verveine …

Comme on aurait pu s’y attendre, le projet Nagios flotte sur sa notoriété et ne propose rien d’excitant dans sa roadmap. Nagios n’a pas brillé par ses nouveautés. L’année 2011 nous a offert la sortie d’une version mineure avec quelques correctifs et un petit relooking via CSS pour être dans la même charte graphique que le site et Nagios XI. Plutôt décevant quand on connaît les faiblesses de Nagios sur les grands environnements.

Ton Voon (Responsable du projet Nagios Plugins) a aussi annoncé son départ de la place de leader du projet Nagios Plugins.

Vers la quête de la performance et de l’innovation …

Icinga, l’élève dépasse le maître ?

Le projet Icinga a été l’un des projet les plus dynamiques dans cette année 2011. Entre les sorties de releases et la sortie de la partie Reporting, Icinga a frappé fort cette année, mais l’équipe ne s’arrête pas là. Afin de combler les faiblesses du cœur de Nagios qui pour le moment ne sont pas dans les priorités d’Ethan Galstad, la communauté allemande veut prendre le taureau par les cornes afin de trouver des innovations technologiques pour palier à la limitation & la complexité de conception d’architecture de Nagios dans les grands environnements.

Icinga suit la piste de l’AMQP en lançant le projet IcingaMQ basé sur la librarie ZeroMQ. Icinga n’est pas le seul projet à s’intéresser à l’AMQP, un autre projet d’hypervision Open Source va s’appuyer sur cette technologie, il s’agit de Canopsis.

Canopsis, l’hypervision à le droit à l’Open Source

Ce projet lancé par la société Capensis avec l’aide de la CFSL sera un projet Open Source sous licence aGPLv3. Ce projet émane d’une année de réflexion autour du constat que: « la Supervision d’aujourd’hui ne correspond plus exactement à ce qu’attend le public destiné à la supervision (plus particulièrement les dirigeants) ». Le but de ce projet n’est pas de rester qu’un développement interne à Capensis. Canopsis invite tout type de public (développeur python / Web 2.0, ergonomiste, concepteur, dirigeant, …) à participer à ce projet afin de partager leurs idées sur ce que doit être un hyperviseur et ce qu’ils en attendent. Le but est de créer une solution répondant aux besoins des entreprises aujourd’hui concernant la surveillance de leur parc informatique et capable de rivaliser avec le monde de l’édition dans ce domaine mais en moins usine à gaz .

Mod Gearman a de la répartie

La communauté allemande a aussi lancé un autre projet: Mod_Gearman. Ce projet sort tout droit du laboratoire de Consol.de. Cette solution permet de gérer sa configuration en 1 seul point et de gérer le système d’interrogation du parc supervisé en mode Load Balancing. Fini le découpage de la configuration par poller .

Dans le cadre d’une architecture distribuée Nagios, Vous avez un Nagios dit « Central » qui sert de console de visualisation et de gestion de la configuration et vous avez ensuite une instance Nagios par poller / collecteur.

Avec Mod_Gearman, l’aspect du Nagios « Central » et la gestion de la configuration reste mais la répartition du parc supervisé n’est plus à la charge de l’administrateur de Supervision. Fini l’installation d’un Nagios sur chaque poller. Vous n’avez plus qu’à installer les plugins de supervision sur vos Worker Gearman (alias poller Nagios) et le tour est joué. C’est le Broker d’événement Mod_Gearman sur la Nagios Central qui va gérer la répartition de la charge. Il existe d’autres modes au Mod_Gearman. Je vous laisse les découvrir sur le site de Consol Labs.

Les performances proposées par cette alternative aux distribuées traditionnelles est tout bonnement bluffante. Si vous êtes en architecture distribuée Nagios ou Nagios / Centreon et que vous ne voulez pas franchir le pas vers Icinga ou Shinken pour le moment, je vous invite grandement à goûter à cette recette, vous m’en direz des nouvelles. Ce projet nous a séduit car il permet de faire évoluer son architecture et en décupler les performances à moindre coup.

Shinken, le nouveau né prend son envol

Le projet Shinken est le 2eme projet à nous avoir séduit par la vivacité de son avancée et de l’aspect nouveau qu’il donne à la supervision. Le projet Shinken a sorti son interface web qui représentait l’un des plus gros frein à l’heure actuel pour migrer son Nagios vers un Shinken. Cette interface propose un aspect différent des autres interfaces dites « Nagios-Like ». L’interface arbore des vues permettant de mettre en évidence la Supervision Métier, les Business Rules et le RCA (Root Cause Analysis). Une version de l’interface de Shinken est visible sur le site Démo Shinken (login: admin / mdp: admin).

Quelques nouvelles des coulisses … Le projet Shinken travaille toujours sur la quête de la simplicité et veut offrir un maximum de plugins par défaut à son utilisateur. Il n’est pas toujours facile de prendre en main la supervision mais aussi certains plugins qui touche des technologies bien particulière (Oracle, MSSQL, MySQL, ESX, …). Les développeurs travaillent pour simplifier l’installation de ces briques que l’on retrouve dans 90% des S.I.

Centreon, la recette qui marche

Comme on peut le voir, le projet Centreon plait beaucoup aux entreprises par son aspect bien fini. Le projet Centreon s’est concentré cette année à répondre aux demandes de ses utilisateurs sur les problèmes de performances que pouvaient avoir l’interface avec le broker d’évènement NDOUtils (notre croix …). Merethis a sorti son propre broker d’évènement pour alléger le coeur de Nagios et d’améliorer les performances entre l’interface et les bases de données MySQL.

Le projet a aussi beaucoup travaillé sur l’amélioration de l’interface et de son ergonomie. Ce chantier est toujours en cours et a engendré beaucoup de bugs dans la version 2.2.x. Merethis doit continuer son effort dans l’amélioration de l’ergonomie de Centreon… surtout quand on voit tous les frameworks et technologies aujourd’hui qui facilite la création d’interface logiciel Web 2.0.

Multisite, la boîte à idées ?

Mattias Kettner avait frappé très fort lorsqu’il a sorti le broker d’évènement MK_Livestatus et le fameux check_MK. Mattias ne s’est pas arrêté là. Il continue à faire évoluer l’interface Multisite. Cet interface style « nagios-like » est une très bonne source d’inspiration. Mattias a su se différencier à proposant des vues métier, des filtres, un bac à évènement, des indicateurs, … Multisite est pour nous l’une des meilleures interface sans gestion de configuration à ce jour pour Nagios.

Que se passe-t-il chez les voisins ?

Zabbix a attiré notre attention cette année par son dynamisme et aussi par le commencement de l’amélioration de son interface Web qui ne fait pas l’unanimité. Son interface est souvent perçue comme très chargé pour un débutant. La prise en main demande un petit temps d’adaptation. Ce projet pourrait vraiment faire un bon en avant si son interface était revu en termes de simplicité et d’ergonomie car point de vue technique Zabbix n’a rien à envier à Nagios.

OpenNMS continue son bonhomme de chemin, les sorties de releases sont régulière. Nous avons remarqué que ce projet a du mal à trouver son public en France alors que cette solution présente de réels intérêts. Peut être que ce projet manque de réels acteurs pour le pousser dans l’hexagone.

Pour conclure cette année …

2012 sera l’année où les solutions devront miser sur les bonnes technologies pour améliorer non seulement leurs performances mais offrir un aspect nouveau de la supervision plus axé vers les dirigeants et le service rendu. Les dirigeants attendent de leurs outils de supervision:

• Des indicateurs de performances et de tendances
• Une meilleure représentation des services rendues aux utilisateurs
• Une interface simple à utiliser et à comprendre

Pour ma part, c’est toujours un plaisir d’assister à cet événement qui permet, outre d’assister à des conférences toujours très intéressantes, de partager retours d’expérience et réflexions autour de notre sujet de prédilection : la supervision. Et ceci avec les protagonistes de la plus importante communauté du monitoring qui soit; la communauté allemande.

Nous avons encore eu cette année de belles conférences comme par exemple l’équipe d’Icinga qui nous présentait les nouveautés de la version 1.6 qui vient juste de sortir. À noter aussi une conférence comparative des performances de Nagios, Icinga et Shinken. Si les performance de Nagios et Icinga sont très proches; ce qui ne surprend pas puisque ces deux solutions partagent toujours la même base de code pour le core, le grand vainqueur du match est sans contestation possible Shinken.

J’ai eu aussi le privilège d’avoir une présentation « privée » en anglais de la pile logicielle retenue par la société derrière le premier réseau social allemand. Cette solution, en remplacement du tandem Nagios/Cacti est basée sur un bus AMQP de type RabbitMQ, complété de Rocksteady et de Graphite. Une approche vraiment intéressante du traitement des données de performance pour les grands environnements et qui répondait en écho à ma propre présentation sur la supervision pour les dix années à venir (rien que ça .

Et si je retiens deux choses cette année, c’est l’intérêt croissant pour ces solutions de supervision architecturées autour d’un bus message de type AMQP ou autres (IcingaMQ) et l’engouement à venir pour la supervision de type End User Experience.

Je retiens également sur un « plan moins technique » la bonne soirée que nous avons passé le mardi soir, Jean et moi, en compagnie d’amis francophones wallons à discuter supervision et autres À noter dès aujourd’hui dans vos agendas, les dates retenues pour la prochaine OSMC qui se tiendra les 17 et 18 octobre 2012.

 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 :

Sugestions de configuration par GLPI pour Shinken

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 :

Alertes Shinken dans GLPI

Et avec un exemple de règle métier :

Business rules Shinken dans GLPI

Et son détail :

Détail de business rule Shinken dans GLPI

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.

Shinken 0.8 : Vue des impacts importants pour le business

Pour les managers ayant un navigateur supportant WebGL, cette vue est également disponible en 3d :

Shinken 0.8 : impacts en WebGL 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.

Shinken 0.8 : vue des problèmes sources

Avec l’affichage d’impacts (également triés sur leurs importances) pour un élément par exemple :

Shinken 0.8 : vue problèmes avec des impacts

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 :

Shinken 0.8 : détail d'un problème source

Et inversement pour un impact :

Shinken 0.8 : détail d'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 :

Shinken 0.8 : vue graphiques des liaisons

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

]]> http://www.monitoring-fr.org/2011/10/shinken-0-8-guilty-guecko-pointe-le-bout-de-son-nez/feed/ 1 http://www.monitoring-fr.org/2011/09/nicolargo-interview-le-papa-de-shinken/ http://www.monitoring-fr.org/2011/09/nicolargo-interview-le-papa-de-shinken/#comments Fri, 02 Sep 2011 08:30:00 +0000 Romuald Fronteau http://www.monitoring-fr.org/?p=2973 Nicolargo s’est lancé dans l’interview d’un projet qu’il suit depuis un petit moment : Shinken.

Il y a quelques semaines, Nicolargo demandait aux internautes de lui envoyer leur questions autour du projet Shinken. Je vous laisse donc lire le résultat de cet interview où Jean Gabès (créateur de Shinken) s’y livre sans retenu.

Blog Nicolargo : Interview de Jean Gabès

En parlant de Zabbix le salon Solution Linux à été l’occasion d’apprendre le déploiement de Zabbix sur de gros périmètres de supervision. Il manque tout de même de visibilité et de professionnels permettant de le supporter en France. Mais Ludovic, notre référent Zabbix, veille au grain. Cet intérêt pour Zabbix est à mettre en parallèle avec l’explosion du nombre de posts dans le forum dédié à Zabbix.

Shinken commence à vraiment faire parler de lui, en témoigne le succès de la conférence de Jean GABES au salon Solution Linux (plus de 100 personnes au comptage sur une salle qui n’était clairement pas taillée pour accueillir autant de monde). Les premiers retours de mise en production de Shinken arrivent également.

L’année des forks ?

Sur le stand Monitoring-fr peu de demandes concernant Nagios et cela confirme notre opinion de la stagnation de cette solution qui glisse progressivement vers le propriétaire (Nagios XI) et tourne le dos à sa communauté (le core, NDO, NRPE et NSCA n’ont pas eu de mise à jour depuis plus d’un an). Gageons que Ethan va enfin finir par redresser le tir. Des rumeurs concernant la reprise du développement du core sont à confirmer.

Merethis à fait grand bruit autour de sa solution Centreon avec d’une part l’annonce de la sortie de la version 2.2 de Centreon (qui marque l’ouverture aux autres ordonnanceurs de supervision comme Icinga ou Shinken) et d’autre part l’annonce d’un fork de Nagios (Centreon Engine). Ce n’est pas un simple fork avec reprise du code et nettoyage des marques, mais réellement une volonté d’avancer et d’innover sur un coeur sclérosé par son auteur original. Merethis entend bien avoir une offre globale et devenir un véritable acteur maîtrisant toute la chaine depuis l’ordonnanceur jusqu’à la console de supervision en passant par l’interface de configuration. La roadmap est ambitieuse et promet de belles avancées (webservice permettant de remplacer le fichier pipe de commande et de contrôler les collecteurs en mode distribué), mais également de nombreuses innovations a venir. Attendons une première version utilisable avec Centreon.

En parlant des forks de Nagios, d’un coté ce mouvement tend à dynamiser les avancées, d’un autre n’y a t’il pas un risque de diviser les communautés ? La question est posée et si chaque fork (Icinga pour l’Allemagne, Centreon Engine pour la France … mais également Opsview en plus « amical » en viennent à ne pas communiquer, il y a risque de réinventer la roue (redondance des patchs par exemple). Attendons de voir comment cela va évoluer.

Les « nouveaux » et les « retours »

La société tunisienne Alpha Engineering a surpris en parlant de leur solution de supervision Alphatron basée sur …. Hyperic. On peut se demander si le choix est judicieux vu que la solution Hyperic est maintenant passée aux mains de VMWARE qui n’est pas vraiment reconnu comme acteur de l’Open Source mais cela pourrais être contrebalancé par le désir de forker Hyperic (mais l’éditeur se pose des questions sur les compatibilité des licences libres et souhaite se faire accompagner par des spécialistes de ces questions). Alphatron apporte un certain nombre d’améliorations, notamment dans le domaine du reporting. Les pays d’Afrique du Nord sont donc très actifs dans le domaine et il constituent maintenant notre deuxième lectorat après la métropole française.

L’éditeur Combodo avec leur solution ITOP permet de facilement intégrer les processus ITIL au coeur du SI. Et bien sur (comme tout est mesure dans ITIL) la supervision tient une bonne place dans cette Solution. Combodo se pose en agrégateur des différentes solutions existantes (comme OCS pour l’inventaire, GLPI pour la gestion de ticket / Gestion de parc ou Nagios pour la supervision) et relie toutes ces solutions au travers d’une CMDB. Il est relativement aisé de substituer une solution par une autre en créant les connecteurs adaptés. Nous en reparlerons plus avant dans quelques temps.

Toujours au rayon nouveautés, une nouvelle interface « Made in France » pour Nagios et compatibles fait son apparition dans le paysage. Celle-ci est dénommée Openpom et fait partie d’une solution complète qui elle n’est pas libre; si j’ai bien tout compris.

Enfin, signalons un retour à la vie d’un projet que nous croyions mort et enterré avec Vigilo v2. Le wiki a été mis à jour et pour avoir rencontré quelqu’un du projet, il semble que l’équipe soit décidée à mieux communiquer sur ce logiciel qui a des atouts pour les gros périmètres de supervision. Nous verrons dans le temps si tout ça se vérifie.

Quelles perspectives pour l’année 2011 ?

L’émergence de solutions comme ITOP (dont la conférence à été un réel succès au salon Solution Linux), tend à démontrer le besoin des solutions de supervision à se rapprocher d’autres solutions pour présenter une offre globale et plus proche des besoins d’industrialisation des entreprises.

Ce rapprochement commence à mettre en évidence certains manques comme la supervision de la performance des applications (dont nous commençons à parler depuis quelques temps pour les applications web), mais il ne faut pas oublier également la mesure de la performance des applications client riche et lourd et là en dehors de certaines solutions (non dédiées) comme Sikuli (projet du MIT) il y a un grand vide. La supervision de la performance des application doit être un bon complément à notre classique supervision technique et doit permettre de mieux cerner certains problèmes indécelables par celle ci. Par exemple une application peut parfaitement être disponible du point de vue technique (services présent, serveurs joignables) mais complètement inutilisable du point de vue utilisateur final à cause de temps de réponse trop longs (Je parle par expérience). À contrario on ne peut se contenter de la mesure de la performance des applications pour des raisons évidentes de diagnostique en cas de problème. Au sujet de la gestion de la performance des applications, certaines initiatives éditeur démontrent et tendent à confirmer ce besoin, avec par exemple Groundworks et Webinject, ou encore Opsview avec Selenium. L’implémentation reste encore basique mais va dans le bon sens.

Une autre tendance émergente concerne le besoin d’agréger les solutions de supervision éparses de l’entreprise et de corréler tout les événements générés par ces solutions de manière à les présenter sous formes synthétiques à l’ensemble des acteurs de l’entreprise (DSI, Etude et Production). Les vues et les besoins ne sont pas les mêmes selon les cibles et l’on se doit de présenter des tableaux de bord ciblé. En plus des événements générés par les solutions de supervision, il faut également avoir la possibilité de corréler l’ensemble des événements du SI (Ticket d’incidents, centralisation des logs ….). On touche à un domaine ou le monde propriétaire est bien implanté (BMC, IBM ….) mais ou l’Open Source brille par son absence : l’Hypervision. Des solutions sont en gestation et devraient commencer à faire parler d’elle courant 2011.

Vous pouvez retrouver le bilan communautaire du salon sur le site de l’association

Un module de découverte!

Le grand rajout de cette version est incontestablement le module de découverte. Ce dernier est totalement modulaire et extensible. De base, il permet de détecter les machines et les services réseaux classiques (HTTP, DNS, MySQL, Mssql, Oracle, …) et de les rajouter automatiquement à la configuration. Un module de découverte des machines virtuelles sous VmWare vSphere est également disponible.

Ce module est très facilement extensible, que ce soit pour la découverte à proprement parler (ceci se base sur de simples scripts qui retournent les informations comme le font les sondes Nagios), ou bien son système de règles qui permet suivant les informations récoltées de créer les hôtes et les services dans la configuration.

L’architecture globale est finie

Cette version voit arriver la fin des travaux initiés depuis les toutes premières versions sur l’architecture qui fait de Shinken un projet si particulier. On a donc à disposition désormais un nouveau daemon optionnel pour les données passives que l’on peux disposer sur les sites distants qui sont régulièrement coupés. Il n’y a ainsi plus de pertes d’informations possibles.

La partie distribution de charge n’est pas oubliée non plus, et le dernier point possible de contention est levé avec la possibilité de multiplier à merci les « broker », ces daemons qui gèrent les données pour les sauvegarder/présenter.

Enfin, un soin tout particulier a été donné aux daemons qui lancent les sondes afin qu’ils puissent être placés en zone DMZ et que leur connexions soient uniquement du sens LAN->DMZ afin de respecter les exigences de sécurités actuelles. Le rajout de ces daemons est également désormais possible à chaud sans redémarrer tous les daemons!

Des modules immortels, et pour de nouveaux daemons

Les modules sont l’autre clé de voute de Shinken. Désormais, en cas de soucis, comme la perte de la connexion à une base de donnée, ces modules sont redémarré de temps en temps au lieu de disparaitre et demander un redémarrage complet du daemon.

Ces modules font également leur arrivées sur de nouveaux daemons, comme par exemple les poller qui ont comme charge de lancer les sondes. Un des modules disponible est par exemple un module NRPE qui permet de lancer les interrogations sur les serveurs distants sans avoir à lancer de processus. Ceci apporte un gain de performance important pour ceux qui utilisent cette sonde.

Un lien fort avec VMware

Tout comme pour le module de découverte, Shinken est de plus en plus adapté à la supervision des environnements virtuels, VMware en tête. Il permet ainsi de détecter et mettre à jour si besoin les liens de dépendances entre les machines virtuelles et leurs hôtes. Ainsi, après une migration d’un hôte vers un autre (VMotion), le lien de dépendance entre les hôte dans Shinken va être automatiquement mis à jour sans que l’administrateur n’ait besoin de lui dire!

Un nouveau wiki plus simple

Un gros travail de fond a été fait sur le wiki du projet pour le rendre plus accessible aux débutants. Ce travail est toujours en cours, mais il est déjà bien plus simple de débuter sur Shinken avec des tutoriels simple, comme celui qui propose de démarrer en 10minutes avec découverte automatique et interface graphique! (Thruk)

Et maintenant ?

Avec la finalisation de l’architecture, c’est toute une phase de ce projet qui se termine. Une phase de stabilisation se profile, avec la rédaction d’aides de plus en plus nombreuses pour aider à installer et tirer parti de tout le potentiel de l’outil. Vous pouvez toujours voter pour vos prochaines fonctionnalités favorites sur le site dédié, car gageons que les auteurs nous ravirons encore dans le futur proche, avec de nouvelles fonctionnalités qui facilitent la vie des utilisateurs

Shinken sort déjà une nouvelle version, un peu plus d’un mois et demi après la dernière! Cette version 0.5 (nom de code ver de terre éruptif) continue sur la même lignée que son prédécesseur, et sur un rythme toujours effréné. Comme à son accoutumée, elle est disponible sous forme classique et sous forme d’une machine virtuelle de démonstration.

Outre les quelques corrections de bugs, nous avons le droit à cinq fonctionnalités principales :

• rajout du chiffrement SSL entre les processus, basés sur des certificats
• des périodes d’absences pour les contacts
• les escalades de notifications basées sur le temps, afin de mieux coller aux notions de SLA
• l’arrivée de la notion de criticité des hôtes et services
• et la dernière mais pas la moindre : l’arrivée dans le cœur de l’application des règles métiers!

Regardons un peu les dernières fonctionnalités plus en profondeur.

Périodes d’absences pour les contacts

Les administrateurs sont comme tout le monde, ils partent de temps en temps en vacances. Lors de leur retour, chacun faisait à peu près la même chose : prendre toutes les alertes s’étant produites pendant ses congés et les supprimaient. Dorénavant, avant de partir il peut prévenir l’outil qu’il ne sera pas là sur une période de temps, et ce dernier ne va tout simplement pas lui lever de notifications pendant celle-ci.

Escalades de notifications basées sur le temps

Dans Nagios, les escalades de temps sont basées sur un nombre de notifications. Ceci rend cette configuration très complexe lorsqu’il est question de SLA basés sur le temps. Or la plupart le sont (comme par exemple escalader le problème au support niveau 2 au delà de 3h).

Shinken ajoute ceci dorénavant. Ce rajout n’est pas un simple « temps=nombre de notifications/temps entre les notifications » car il gère le cas où l’administrateur a décidé qu’entre deux notifications il faille 1 journée, mais qu’il faille escalader au bout de 3heures. L’outil va savoir qu’au bout de 3 heures il doit escalader le problème sans attendre une prochaine notification pour cela.

La notion de criticité

Les outils à licence libre ont un souci : les administrateurs n’ont aucun remord à mettre en supervision tout leur parc, car ils n’ont pas à payer de licence pour chaque objet supervisé. Ceci signifie qu’ils supervisent aussi bien de la production que des serveurs moins critiques comme ceux de qualifications.

Or dans les consoles de supervisions actuelles du monde Nagios/Shinken, il n’y avait que 3 états : ok, avertissement et critique. Mais un avertissement sur un serveur de production peux être plus important qu’un critique sur un serveur de qualification.

C’est pour gérer cela que Shinken permet désormais aux administrateurs de définir la criticité de ses objets. Ils seront triés comme il faut dans les consoles temps réels. Un point important sur le fonctionnement de ce mécanisme vient du fait que lorsqu’un « problème source » est détecté (comme sur un switch qui impacte des applications de production) sa criticité est calculée avec la valeur maximale de celle de ses impacts.

Ainsi, il est possible de lever une alerte la nuit pour un administrateur réseaux pour un switch défaillant que si celui-ci à réellement impacté un service important et non pas un de qualification.

Voici un exemple de vue dans Thruk qui présente les « problèmes sources » et uniquement eux, le tout trié par criticité :

Vue des problèmes sources par Thruk, avec tri sur la criticité

Une telle vue peux être résumée simplement pour les administrateurs « faites ceci, et dans cet ordre ».

Les règles métiers, ou business rules

Il existait déjà dans le monde Nagios un addon permettant d’avoir une « agrégation d’états » sur un indicateur unique avec Nagios Business process addon. Mais il était intéressant d’incorporer un tel fonctionnement dans le cœur de la supervision, afin d’avoir les autres rajouts comme les relations problème source/impacts ou la criticité liés à ces objets « business ».

C’est ce que propose Shinken. Désormais, une simple commande de supervision permet d’obtenir une telle règle « complexe ». L’exemple donné dans la documentation est la suivante, pour décrire une application complète :

• deux bases de données redondées
• trois services webs, dont au moins deux sont nécessaires pour cause de charge
• deux répartiteurs de charges redondés

Une telle règle va s’écrire simplement comme commande de supervision :

bp_rule!(base1|base2) & (2 of: http1 & http2 & http3) & (lvs1 | lvs2)

Un tel hôte ou service est ainsi affichable avec n’importe quelle interface, car après tout c’est un objet comme les autres d’un point de vue externe.

Certains outils comme Thruk sont cependant capables d’interpréter les données du module LiveStatus de Shinken et de représenter ces objets sous forme d’arbres.

Voici un exemple de ce que ceci peux donner :

Thruk et vue business trié par criticité

Et après?

La prochaine version de Shinken devrait introduire des fonctions avancées sur les connexions réseaux afin de pouvoir les « inverser » à loisir et ainsi être plus facile à intégrer dans des environnements hautement sécurisés.

Pour rappel, vous pouvez rajouter votre idée ou voter pour votre future fonctionnalité favorite sur le site http://shinken.ideascale.com.