Bilan technique du salon Solutions Linux 2011
2011 confirme la crédibilité des solutions alternatives à Nagios comme Zabbix ou Shinken.
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
7 Comments
Leave a Comment
Vous devez être connecté pour publier un commentaire.
Licence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.
Bonjour, je suis un des développeurs de Vigilo. J’étais sur le salon sur le stand de l’AFPy, mais vous savez ce que c’est : entre tenir le stand, répondre aux visiteurs, faire des démos, et essayer d’aller récupérer des goodies et des petits-fours, j’ai à peine eu le temps de passer dire bonjour.
Mais ce n’est que partie remise.
En ce qui concerne Vigilo, on s’était fixé le début du salon comme date de publication de la version communautaire, ce qu’on a réussi à tenir au prix de quelques oublis dans le contenu : deux interfaces sur trois sont encore en cours de nettoyage, et la doc est assez minimaliste pour l’instant. Là aussi, on essaye de dégager du temps entre les clients (qui passent devant, c’est normal).
Bref, n’hésitez pas à tester, mais ne soyez pas trop surpris du manque de finition pour l’instant. On y travaille, ça prend du temps.
En tout cas, merci d’avoir parlé de nous ! On prépare aussi de notre côté un plan de communication un peu plus détaillé, ce n’est pas une sortie ponctuelle de Vigilo pour replonger aussitôt. Tout ça c’est du boulot, mais on est motivés ! 🙂
Bonjour, merci pour ce retour très complet qui donne une vision intéressante sur l’avancée des projets open source de supervision. Je ne suis toutefois pas d’accord avec la conclusion concernant l’hypervision.
N’est-ce pas justement le point fort d’OpenNMS par rapport aux autres solutions open source ? David Hustace qui a rejoint le projet venait de chez Micromuse, premier éditeur de Netcool avant d’être vendu à IBM. Il a contribué au projet OpenNMS par l’ajout des fonctionnalités de Netcool Omnibus, référence absolu pour l’hypervision dans le monde télécoms au début des années 2000. La BEM de BMC n’a fait que reprendre lui aussi ses concepts à ses débuts !
Désolé de te contredire mais un hyperviseur n’est ni plus ni moins qu’une solution qui consomme des évènements, les normalises et les corrèles pour présenter une vision consolidée aux différents acteurs du SI. Quand je parle d’évènements, cela peut venir des différentes solutions de supervision, des centralisation de log, mais également l’activité des outils de support (comme la gestion de tickets). En somme l’hyperviseur se place au dessus de toutes ces solutions générant de l’évènement. OpenNMS est un ordonnanceur de supervision avant tout (chose qu’il fait très bien), je ne suis pas expert mais je ne le sent pas capable de consommer des évènements de tous types,les normaliser et les corréler .
Désolé de te contredire à mon tour mais OpenNMS n’est justement pas initialement un ordonnanceur de supervision comme le sont Nagios, Zabbix, …
OpenNMS est avant tout une solution qui consomme des évènements, les normalises et les corrèles pour présenter cette vision consolidées dont tu parles.
Il intègre certes un ordonnanceur qui permet de tester activement des services (le polling) mais le résultat est exploité dans les vues events (historique des alarmes présentées au fil de l’eau) et alarms (corrélation et déduplication) avec les autres alarmes reçues cette fois-ci à l’initiative des équipements supervisés, ou transmis par d’autres consoles de supervision.
Il n’existent d’ailleurs pas de vue qui présente l’ensemble des services pollés comme dans Nagios, etc …
La vue Outage d’OpenNMS qui présente l’état des services PAR CATEGORIES n’est jamais utilisés : il manque les autres alarmes !
Concernant les tickets d’incidents, un hyperviseur doit pouvoir s’interfacer avec un tel outil pour faciliter la création d’un ticket à partir d’une alarme reçue (pré remplissage des champs connus par l’hyperviseur, l’opérateur complète ensuite manuellement le ticket avec ses commentaires) et pour suivre la résolution du ticket d’incident (gestion automatique de l’état du ticket lorsque l’incident est résolu).
Par contre, les tickets d’incident peuvent être créés aussi à partir d’un centre d’appel téléphonique. Les problèmes remontés par les utilisateurs ne sont alors pas forcément gérables dans un hyperviseur (perte de mot de passe, …).
Pour moi, il s’agit bien de deux besoins différents : les dashboards fait à partir de l’hyperviseur et ceux fait à partir du gestionnaire des tickets d’incidents.
Super intéressant ce débat, ça permet de mieux connaître les possibilités d’OpenNMS qui restent encore peu connu 😉
Thx Dominique pour ce retour d’expérience
Un grand merci a toi pour ces réponses, je pense d’ailleurs à tester plus avant ces concept. Peut être de la doc dans le wiki a rédiger a ce sujet ?
Tout à fait, j’ai prévu de le faire prochainement.
Les concepts de déduplication et de corrélation début/fin sont déjà expliqués dans le wiki : http://wiki.monitoring-fr.org/opennms/events-alarms
Il manque les explications qui permettent d’affecter à l’équipement supervisé les alarmes provenant d’un autre superviseur. En effet, elles s’affichent par défaut sur l’équipement qui envoi l’alarme, donc sur le superviseur !
Le mécanisme utilisé est l’Event Translator …