Mais il est aussi probable que l'absence d'évolutions réelles en 2009 sur le Nagios Core profite également à quelques concurrents qui ne sont pas restés sans rien faire de leurs côtés. Le plus "dangereux" pour Nagios étant Zabbix, qui a vraiment progressé en 2009 et offre aujourd'hui une alternative crédible à Nagios. Zabbix embarque désormais au moins autant de fonctionnalités que Nagios si ce n'est plus. Sans oublier Zenoss. C'est aujourd'hui certainement l'un des projets les mieux structurés au niveau communauté, business…. Le logiciel progresse et le fait qu'il soit en python et basé sur Zope pourrait tenter du monde. Python toujours avec Shinken qui pourrait être l'outsider de cette année. Ce jeune projet a sur le papier tout pour séduire, notamment sur le plan des performances et une architecture qui permet de l'adapter à de très grands environnements.

La balle est aujourd'hui clairement dans le camp de Ethan, qui se doit de réagir et d'envoyer quelques signes positifs à la communauté qu'il a un peu déserté ces derniers temps pour cause de démarrage de Nagios XI. Il doit réussir la triple équation évolution du code, développement du business et bien-être de la communauté pour garder le leadership sur la supervision Open Source. Quoiqu'il en soit, ce sera une belle année pour la supervision Open Source.

RSur le même sujet:

1. La supervision au salon Linux Solutions 2009 Le salon Linux Solutions s’est tenu comme chaque année à Paris et comme à l’accoutumée, quelques solutions de supervision étaient présentes. Pas de révolution à venir dans le domaine de la supervision mais plutôt une confirmation que les acteurs actuels, Centreon et Vigilo; continuent de...
2. Quand la supervision rencontre la Sécurité Quand la supervision rencontre la sécurité ça nous fait une solution Open Source digne de ce nom à base de : Nagios Prelude Snort Ossec Ce projet a été élaboré en labo par Ludovic VALENTIN dans le cadre d’un stage. La documentation qui en est...
3. Monitoring-fr aux RMLL 2010 Comme vous avez pu le remarquer avec les bannières des RMLL 2010 sur le site, la Communauté Francophone de la Supervision sera présente du 6 au 11 juillet aux RMLL 2010 à Bordeaux. Nous serons présent au Village Associatif pour vous rencontrer et échanger sur...
4. Les outils de supervision libres aux RMLL 2009 Comme pas mal de personnes me l’ont demandé, voici le support de la présentation (au format Open Office) de 40 minutes que j’ai faite le jeudi 09 juillet aux RMLL 2009 à Nantes sur les outils de supervision libres....
5. 3ème conférence Nagios Pour la troisième année consécutive, NetWays organise une conférence Nagios à Nüremberg qui se tiendra le 11 et 12 septembre. C’est l’occasion comme chaque année de faire le point sur Nagios, son écosystème et les projets à venir le concernant. J’y serai encore cette année...

Le directeur du système d’information se fout un peu de savoir si le switch était disponible à 99,99% du temps. Comme il se fout de savoir si la base de données est optimisée et fonctionne efficacement. Ce qu’il lui importe est de savoir comment ces composant affectent le business.

Les bons systèmes de rapports incluent tous les incidents qui perturbe de n’importe quelle façon l’utilisateur des systèmes. Ils n’incluent pas les interruptions de service comme par exemple, un lien secondaire qui est mort. Bien sûr, le service informatique doit travailler pour résoudre ce genre d’incidents, mais vu qu’il n’affecte pas l’utilisateur final, c’est inutile de le consigner.

C’est une épée à double tranchant. Vous devez ne pas rapporter sur les choses qui n’affectent que les services IT; mais vous devez au contraire rapporter tout ce affecte l’utilisateur final. Beaucoup de services IT ne le font pas ainsi, et ils masquent soit ce qui pourrait être une nouvelle opportunité d’améliorer les services IT pour les utilisateurs; soit ce qui pourrait devenir une rébellion utilisateur.

Disons que votre console Nagios ou WhatsUp vous dit que votre serveur Exchange est up, up, up. Il est joignable par ICMP, et les transactions courtes sur chacun des services importants sont fonctionnelles. Pourtant, il y un problème qui est que les personnes connectées ne peuvent plus rien faire après 60 secondes de connexion. Interruption de service, non ? Interruption de service, OUI. Les dirigeants n’ont que faire que ce soit un problème lié au poste client, à l’application ou à l’infrastructure.

Il y a 15 ans, j’ai écrit de façon enthousiaste sur les systèmes de supervision. Et je continue à croire que les services IT en ont besoin. La gestion des infrastructures est une partie importante de la gestion des services. Mais dans un contexte orienté service, la supervision de la disponibilité n’est pas suffisante.

Votre centre de services doit être le point central de rapport des interruptions de services. Rapporter un uptime de “99,99%” ne raconte pas toute l’histoire. Et franchement, vu que le centre de services est souvent conduit par une entité tierce à votre organisation, c’est une tierce partie qui peut aider pour savoir toute l’histoire vu du point de vue utilisateur final.

Comment commencer ? La plupart des centres de services vous permettent de classer les tickets comme incidents ou demandes. Pour augmenter la plus value du classement des incidents, vous pourriez les classer par niveau d’impact, (par exemple pas de service, interruption importante ou faible, intermittente) et le périmètre d’impact (par exemple entreprise, département, groupe de travail). Collecter des données multi-dimensionnelles vous permettra d’avoir une vue complète. De plus, la plupart des centres de services vous permettent de préciser le temps écoulé jusqu’à la clôture du ticket.

Ces dimensions vous permettront de présenter un rapport d’interruption de service qui veut dire quelque chose plutôt qu’un mumbo-jumbo d’uptime d’infrastructure qui ne dit pas toute la vérité.

Article repris et traduit depuis :
Infrastructure Uptime: A Useless Report par Jonathan Feldman