Supervision : Un avenir sans Nagios ?

Posted by on 3 Mar 2014 in Communauté, Planet, Supervision | 0 comments

Ce titre vous paraît peut-être inquiétant. Si nous faisons le point de ce qui s’est passé ces 2 dernières années et ce qui est entrain de se produire … ceci pourrait devenir une réalité.

Les mailing-list de développement ont été fermé à la communauté et il a été dit que Nagios 4 est la dernière version du coeur qui sera développée. Même si cette dernière au vue de ces performance à de l’avenir … Ceci ne fait pas tout. Ce qui fait la force d’un projet est aussi la communauté qui le porte et ça fait bien des années qu’ Ethan ne la regarde plus.

Si nous faisons un petit bon dans le passé, nous avions déjà averti le créateur de Nagios, que le phénomène pourrait retomber comme « un cheveu sur la soupe » en n’écoutant pas les problèmes que remontaient la communauté et en faisant évoluer très peu l’outil. Le constat est unanime, les dérivés se sont multipliés : Icinga, MK MultiSite, Naemon, Shinken …

Même le projet Centreon a marqué son éloignement à Nagios à sortant son propre Broker et le projet Centreon Engine. La multiplication des dérivés montrent que le projet Nagios n’est plus en phase avec la réalité de ses utilisateurs.

Autre phénomène, la naissance des mouvances MonitoringSucks et MonitoringLove sur les réseaux sociaux où des experts en supervision se regroupent et recherchent des technologies Open Source afin d’améliorer et rendre plus intelligente la supervision de demain.

Et oui, pour utiliser une solution de supervision tous les jours, on est encore loin de la perfection. Elle ne s’adapte pas au calendrier de l’activité du métier, manque de seuil dynamique au niveau des sondes, manque d’adaptation de la sévérité, manque d’intelligence des agents … Ces petits détails font que nous pouvons générer des « fausses alertes ».

Prenons quelques exemples :

  • Faut-il générer une alerte lorsque le load average d’une machine est chargé durant la période des paies ?
  • Faut-il générer le même niveau de sévérité durant les heures ouvrées et non ouvrées ? Lorsque l’activité de l’application est calme ou énormément sollicitée par ces utilisateurs ?
  • Faut-il se baser sur un pourcentage de volumétrie disque ou plus sur la rapidité à laquelle un disque se remplit ?
  • Je pense qu’en prenant du recul, chacun d’entre nous trouve au moins un comportement « stupide » à la supervision Open Source d’aujourd’hui. J’appuie sur Open Source, car les éditeurs ont depuis longtemps une longueur d’avance sur nous … On ne bénéficie pas des même moyens aussi et surtout, c’est pas le même prix 😉

On voit très bien depuis l’année dernière que le centre d’intérêt des internautes changent et que des experts s’intéresse de plus en plus à des alternatives aux Nagios-Like … en complément ou en total remplacement de leur solution de supervision. Nous voyons des projets comme Sensu, LogStash, Elastic Search, Kibana, Graphite, d3 et bien d’autres encore affolés les compteurs d’intérêts en terme de lecture et surtout twitter.

En tous les cas, nous suivons de très près ces nouvelles technologies pour voir comment nous pourrons dessiner la supervision de demain. Nagios sera-t-il encore de la partie ? l’avenir nous le dira …

No Comments

Trackbacks/Pingbacks

  1. La supervision Open Source : pourquoi j'ai laissé de côté Nagios ? | Lolokai - Supervision, systèmes, réseaux, base de données... - […] Ca fait un long moment que je n’ai pas bloggué et j’avoue que l’idée de ce billet est honteusement…

Leave a Comment