Depuis l'annonce du fork de Nagios l'an dernier, les choses avancent pour Centreon Engine et Centreon Broker (alternatives Open Source à Nagios et NDOUtils/NDO, une extension pour Nagios).
Merethis, éditeur de Centreon, et ses partenaires stratégiques, ont pu tester Centreon Engine à chaque étape de son développement ; de même Centreon Broker est désormais parfaitement stable et fonctionne déjà dans des environnements de production, sur des périmètres informatiques de moyennes ou petites tailles.
Cependant, même si Centreon Engine et Centreon Broker sont suffisamment stables pour être mis en production, qu’en est-il de leurs performances ? Merethis propose une étude basée sur un simple cas d’utilisation en production comparant un système de supervision basé sur Nagios© et un basé sur Centreon Engine. Le but principal de cette étude n’est pas d’exposer les performances maximales de Centeron Engine mais de les comparer simplement avec Nagios© dans un cas d’utilisation standard.
NdM : il s'agit d'une étude et d'une dépêche par l'une des parties prenantes du comparatif. La dépêche a été revue pour être moins commerciale. Les conclusions de l'étude sont dans la seconde partie de la dépêche.
Les conclusions clés de l’étude
- Le couple Centreon Engine et Centreon Broker apporte ce premier gain de se lancer plus rapidement que Nagios© fonctionnant avec NDO.
- Il permet aussi un contrôle plus précis et plus rapide par l’administrateur grâce aux modifications à chaud, et permet donc d’éviter le redémarrage et les pertes de données de monitoring.
- Cette étude montre que Centreon Engine exige moins de CPU, moins de mémoire et réduit les IO par rapport à Nagios©.
- Les checks sont faits plus rapidement donc avec moins de latence, et ces gains permettent d’utiliser un serveur moins gourmand pour un même nombre de vérifications.
- Par ailleurs, cette réduction des ressources nécessaire fait de Centreon un candidat idéal pour une architecture de supervision de type cloud basée uniquement sur des machines virtuelles.
Aller plus loin
- Détail de l'étude sur le blog de Centreon (2725 clics)
- L'étude et les benchmarks (1299 clics)
- Centreon Engine et Centreon Broker (1094 clics)
- Nagios (593 clics)
# comparatif plus large
Posté par Ludo . Évalué à 4.
Dommage que le comparatif ne prenne pas en compte plus d'alternatives comme shinken, ça aurait été plus intéressant.
# Génial, mais heu...
Posté par Gabbro . Évalué à 3.
Je ne connaissais pas ce logiciel, n'ayant aucune description de ce à quoi il sert, je suis aller voir sur Wikipédia, qui explique que ça sert à plein de trucs à propos desquels je ne connait rien.
Qu'à cela ne tienne, je me demande tout de même pourquoi il y a eu fork ; vous savez, réputation du libre de tout forker sans raison et de diviser les forces…
J'ai cru comprendre que le principal développeur de Nagios, logiciel GPL, souhaitais mettre des bouts proprio, d'où fork. Nait ainsi Icinga.
Et Centreon ? Il serait né avant 2007, date à laquel il aurait changé de nom.
Zut ! Je ne comprends plus rien.
Quand à Shinken, il semblerai que ce soit comme Nagios, mais en plus bien et en AGPL.
Heureusement que toute ces histoires de fragmentation du libre, ce sont des légendes et qu'on ne fork pas sans raison apparente !
[^] # Re: Génial, mais heu...
Posté par nodens . Évalué à 4.
Le fait est qu'il faut connaître un peu.
Centreon est une surcouche à Nagios, initialement. Mais ils ont forké Nagios. Après les raisons de ce fork sont les mêmes qu'Icinga et Shinken. Bouts de proprio qui s'annoncent, peu de réactivité et direction de projet floue", etc.
Il faut reconnaître que c'est un peu le bordel en ce moment au niveau monitoring libre…
[^] # Re: Génial, mais heu...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 10.
En effet, il faut plutôt suivre l'actualité pour savoir exactement de quoi parle cette dépêche. Le projet original, Oreon, est né entre 2003 et 2004. Le changement de nom est dû à un problème de droits. Centreon est d'ailleurs le nom d'un projet de stage donné par un étudiant souhaitant mettre en place une plate-forme de supervision …distribuée.
Les fork par rapport à Nagios Core et NDO sont respectivement Centreon Engine et Centreon Broker. S'il y a certainement eu de la frustration de la part de certains contributeurs de Nagios, je ne pense pas que ce soit la seule raison. Si on exclut Shinken, Icinga (Netways) et Centreon (Méréthis) sont des produits issus d'entreprises privées dont le modèle économique s'appuie essentiellement sur la prestation liée aux logiciels libres de supervision, dont Nagios, initialement. Deux entreprises qui ont tout intérêt dès lors à maîtriser complètement leur solution respective. Shinken, quant à lui, est parti d'un proof of concept, pour révolutionner complètement l'architecture originale de Nagios.
Quant au benchmark lui-même, il s'appuie sur Nagios 3.2.3, Centreon Engine 1.1.1 et Centreon Broker 2.1.0.
Nagios 3.2.3 a été publié le 10 mars 2010.
Centreon Engine 1.1.1 et Centreon Broker 2.1.0 ont été respectivement publiés les 17 janvier et mars 2012, soit près de 2 ans après. Certes, la 3.4.0 a été publié début avril et serait sans doute la seule version avec laquelle un comparatif aurait du sens compte des optimisations communes via la fonction execv(). Cependant, pourquoi ne pas avoir pris la 3.3.1, publiée le 25 juillet 2011 ?
Est-il prévu de faire un nouveau benchmark ou celui-ci a-t-il été publié juste pour SL12 ?
[^] # Re: Génial, mais heu...
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 1.
Parce que la version 3.3.1 comporte un bug critique qui fait chuter les performances.
Nous ferons toujours des benchmarks pour comparer notre avancée et celle des autres outils. Il n'est pas publié pour Solutions Linux 2012, sinon il aurait été publié bien plus tard… Mais si tu veux en discuter lors du Salon, n'hésite pas! :-)
[^] # Re: Génial, mais heu...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
D'après les références, il s'agit surtout d'un bug de régression empêchant le traitement des données de performances, mais pas d'un problème de performance pure. Maintenant, j'admets qu'un tel bug est plutôt consternant, même s'il existe un fix…
Je passerais bien volontiers, mon cher Cédric ;-)
[^] # Re: Génial, mais heu...
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 5.
Je conçois que pour quelqu'un d'extérieur, il n'est pas simple de comprendre les raisons du fork. C'est pourquoi ceux-ci sont expliqués pour Centreon-Engine dans la FAQ du projet et sur la page Wikipedia pour Shinken
# Une annonce commerciale...
Posté par H4wkmoon . Évalué à 6.
J'ai moi-même fait des tests sur Centreon-Brokker.
C'est super pénible à compiler (utiliser QT pour un produit en ligne de commande…). Après avoir réussi à compiler le tout en mode bricolage, on a fait quelques tests. Conclusions : le module broker fige après avoir insérer en base un lot de données. Suite à ce freeze, Nagios attend sans rien faire. La supervision est gelée… Le support "forum" a été réactif, mais inefficace. Le bug est resté sans réponse.
ça, c'est factuel.
Ensuite, côté perf, Centreon broker repose sur les mêmes technos que NDO et a sensiblement les mêmes fonctionalités. Je crains que les perfs ne soient pas au rendez-vous. Là, par contre, je ne peux pas être sur, n'ayant pas pu faire tourner le truc.
Côté Centreon-engine, j'ai fait quelques tests, il y a quelques mois… Impossible de compilter le truc et de le faire tourner le moteur. Cela a sans doute changer depuis le temps. Par contre, quelle est la valeure ajoutée par rapport au moteur Nagios ?
Bref, ce sont de sans doute de bons produits, mais sans prendre de jours de prestations de Merethis, je crains que cela une aventure dont une production préfèrerai se passer.
Je viens, par contre, d'installer un Centreon chez un client. Cela reste un bon produit, tant le nombre de serveurs ne monte pas trop. Installation simple, efficacité. Vraiment agréable à mettre en place.
Pour le reste, je pense qu'il est recommandé de se tourner vers Shinken (ou Zabbix).
[^] # Re: Une annonce commerciale...
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 3.
Il me semble pourtant qu'il y a eu une réponse
Je t'invite à lire l'étude alors :-)
Même réponse que ci-dessus : lit l'étude et ce sera plus clair.
Pour l'absence de simplicité durant l'installation de Centreon Broker, nous avons identifié le problème et nous sommes en train de travailler sur le sujet. Si tu es sur RedHat/CentOS 5 nous avons des paquets RPMs. Ce sont ceux inclus dans Centreon Enterprise Server (CES) Standard.
[^] # Re: Une annonce commerciale...
Posté par H4wkmoon . Évalué à 1.
Bonjour Cédric,
Ok, je ne vais pas refaire le post initiale sur le forum du support Merethis.
Il semble que le bug dont je souffrais était liée à des versions non compatibles entre elles entre Centreon et le broker. Déja que j'ai eu du mal à les trouver les versions que j'ai eu… A l'époque (avril dernier), le site de Centreon ne proposait rien de récent. Les versions proposées étaient très très obsolètes.
Bref, ça doit mieux marcher maintenant.
Quant à lire l'étude, Cédric, oui, je le ferai. Mais, c'est indiqué au dessus, cette étude, faite par Merethis, éditeur de Centreon, pour montrer combien Centreon est bon manque de crédit. Rien de personnel Cédric, mais c'est dur d'avoir l'air impartial quand on travaille pour l'éditeur.
[^] # Re: Une annonce commerciale...
Posté par paillon . Évalué à 4.
Utilisateur de Zabbix, j'avoue en effet qu'une comparaison poussée et claire avec Centreon me plairait, à étendre sur même banc avec OpenNMS?
Mais inclure Shinken dans ce lot est clairement trop tôt. Ok les concepts sont novateurs, ok il dépoussière le genre.. mais dans les faits il va falloir encore bosser. Ce qui est normal, on imagine pas un logiciel être fonctionnel et stable pour de la supervision en quelques mois..
Séduis par les annonces, j'ai testé les deux dernières versions et c'est loin d'être sec. Alors c'est bien de buzzer et d'annoncer des trucs, mais il serait préférable qu'ils poursuivent la r&d et qu'ils soient un peu humble :)
Sinon les benchs sont bien faits. Les récentes com sur Centreon donnent de la visibilité, c'est ce qui a manqué apparemment à l'époque dans ma boite pour le choisir.
On se croisera à Solutions Linux j'imagine ;)
[^] # Re: Une annonce commerciale...
Posté par Pilaf . Évalué à 3.
Hello,
Pas vraiment d'accord avec ton analyse. On est d'abord sur la publication d'un bench légitimé par des travaux lancés depuis 1 an et qui avait pour but de répondre aux problèmes de perf de Nagios. On est assez loin d'une "annonce commerciale", mais plus proche d'un "premier bilan" des actions menées. Bilan très positif au passage et qui nous rassure dans le choix d'avoir pu proposer des évolutions au cœur Nagios qui en avait besoin.
Alors c'est vrai que la communauté Centreon est à l'initiative de ce bench, donc partie prenante, mais qu'importe, l'important est de donner de la visibilité :)
La suite logique serait que tu puisses le constater par toi même, et comme tu n'es pas le seul à avoir eu des difficultés à le mettre en œuvre, on va faire en sorte de simplifier l'installation rapidement.
Mais néanmoins les alternatives Centreon Broker et Centreon Engine ne sont pas les clés pour passer à de la supervision de grands environnements. Centreon, dans sa version actuelle couplée à Nagios et NDO (patché sur notre forge) permet de monter en charge facilement.
Nos utilisateurs nous remontent des installations comportant des milliers de nœuds et Merethis supporte de très nombreuses installations ou les mesures se comptent par dizaines de milliers.
Si une installation from scratch tient facilement quelques milliers de mesures, il est nécessaire d'ajuster des paramètres quand on augmente ce nombre.. et la il faut connaitre un peu plus en détail le fonctionnement de ces solutions. C'est le propos de nombreuses formations existantes sur ce sujet, dont celles proposées par Merethis ;)
Concernant les évolutions techniques et fonctionnelles, elles sont nombreuses, quelques exemples:
Sécurité: Centreon Broker permet l'authentification par certificat.
Compression: Centreon Broker compresse les flux entre les serveurs de l'infra de supervision.
Multi in/Multi out: Centreon Broker permet plusieurs entrées de flux et surtout plusieurs sorties de flux, en simultanées.
Failover: Les logiciels intègrent nativement un système de réplication des données permettant de basculer l'accès à la console.
Réseau: Gestion de l'IPV6
DB: Support en écriture des bases MySQL, PostgreSQL et Oracle. (Lecture actuellement limitée à MySQL).
Et puis toute une série d'évolutions sur le coeur Nagios comme la correction de bugs, les optimisations de performance, le changement de configuration à chaud, le passage de commandes via Web Services, la distribution automatique des configurations, l'intégration complète de protocoles standards etc.
Finalement, pour ta petite pique sur les jours de Merethis nécessaire à l'installation du produit ;) je te dirais que chaque jour de nouveaux utilisateurs installent le problème en trois clics, notamment grâce à l'ISO Centreon Enterprise Server, et déploie dans la foulée une supervision de qualité.
Les retours terrains sur le test de nouvelles alternatives sont elles par contre souvent soldées par un échec, malgré le renfort de jours de SSII, et généralement suivi par le retour à une valeur sure, comme Centreon ;)
Nous serons en effet présents à Solutions Linux, comme au RMLL, ce serait avec plaisir que je t'en parlerai de vive voix :)
Bonne semaine.
[^] # Re: Une annonce commerciale...
Posté par DerekSagan . Évalué à 5.
Peut-être parce que c'est un bon framework. Peut-être par cohérence avec le reste du code.
Quand t'as goûté à Qt et à la façon dont il enrichie le C++, tu n'as plus du tout envie de faire du C/C++ nu.
# Le même benchmark mais sur une plateforme virtualisée
Posté par wiflye81 . Évalué à 1.
Bonjour,
Voila un benchmark très intéressant qui montre les progrès réalisés par Merethis et qui apporte des chiffres concrets.
Le point faible de Nagios étant également la virtualisation, serait-il envisageable d'avoir un le même bench mais sur une plateforme virtualisé (vmware de préférence car ce sont les leaders actuels).
Merci.
[^] # Re: Le même benchmark mais sur une plateforme virtualisée
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
En quoi est-ce que la virtualisation serait un point faible de Nagios ?
Peux-tu être plus précis quant au besoin ?
[^] # Re: Le même benchmark mais sur une plateforme virtualisée
Posté par paulez (site web personnel) . Évalué à 3.
Nagios fait beaucoup d'io disque (lecture des fichiers de résultat) mais à priori ce déficit de performance est corrigé avec des versions de VMWare récentes.
[^] # Re: Le même benchmark mais sur une plateforme virtualisée
Posté par wiflye81 . Évalué à 2.
A re tester dans ce cas mais lors de mes tests j'étais très loin des mêmes performances qu'un serveur physique.
Quand tu dis récente c'est >= 5 ?
[^] # Re: Le même benchmark mais sur une plateforme virtualisée
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
J'avais surtout entendu parler d'un problème lié à l'horloge interne et là, c'était plutôt lié à VMWare qu'à Nagios :
http://cedrictemple.net/dotclear/post/2008/04/18/61-nagios-3-sur-vmware-pas-tres-rapide-en-smp
Maintenant, cet article commence effectivement à dater et il est possible que VMWare ait corrigé ce problème depuis.
# Comparatif intéressant mais...
Posté par paulez (site web personnel) . Évalué à 3. Dernière modification le 11 juin 2012 à 15:28.
Ce comparatif est intéressant mais je trouve que les chiffres obtenus sont très loin de la réalité.
Je fais tourner une solution classique Nagios + Ndo + Centreon avec ~25k checks toutes les cinq minutes sur une architecture répartie (avec un collecteur vérifiant 16k services / 5 min) avec moins de 1seconde de latence sur tous les pollers (contre plus de 300 dans l'étude présentée par l'article) et des temps de démarrage inférieurs à 20s (contre plus de 300s dans l'étude).
Les chiffres que j'obtiens sont donc deux ordres de grandeur inférieur à ceux obtenus dans l'étude. Cet écart est trop important pour être anodin.
Je ne doute pas que Centreon-engine et centreon-broker apportent par rapport à NDO et Nagios, par contre je déplore fortement le cloisonnement entre ces différentes solutions qui pourraient évoluer de concert.
En effet entre temps Ndoutils 1.5 est sorti, corrigeant un de ses principaux problèmes (transmission synchrone) et jouissant de nombreuses optimisations, pourtant Centreon n'est pas compatible.
Entre temps Nagios 3.4 est sorti avec une légère optimisation mais encore boguée, Nagios 4 qui devrait apporter d'importants gains en performance est dans les tuyaux.
Si tous les efforts se concentraient sur Nagios, peut-être que celui-ci avancerait plus vite, plutôt que d'avoir plusieurs produits quasiment identiques avec chacun leurs problèmes et leurs avantages. Pourquoi ne pas résoudre les problèmes d'une seule solution et de ressembler tous ses avantages plutôt que de faire une course de clones ?
PS : ndoutils 1.5.2 a été publié vendredi dernier, qu'on ne me réponde pas que ce projet est mort ;-)
[^] # Re: Comparatif intéressant mais...
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 7.
Comme tu l'indiques toi-même, tu fais cela sur une architecture répartie. Les benchmarks sont réalisés sur un seul serveur (30 000 checks toutes les 5 minutes sur un seul poller). Il est certain qu'avec Nagios sur plusieurs serveurs physiques, il est possible de produire le même résultat que Centreon-Engine sur un seul serveur physique.
C'est ce qui a été fait : nous avons tenté de communiquer avec le développeur de Nagios. Nous avons envoyé plusieurs patchs. N'ayant aucune réponse, nous les avons re-solicité de nouveau. Sans réponse encore, nous avons insisté. Poliment. Plusieurs fois… Presque tous nos patchs ont été refusés, sans forcément obtenir une réponse malgré plusieurs relances. Nous avons été contraint de forker et nous aurions préféré pouvoir travailler de concert avec eux. Nous ne sommes pas les seuls à avoir rencontrer des problèmes de communication. Nous avons vraiment essayé de jouer le jeu. N'étant pas seul à rencontrer ce problème et n'ayant pas eu de réponse, nous ne pouvons pas mettre en cause notre travail sur quelque plan que ce soit (communication, qualité des patchs).
Bah, est ce grâce à Centreon-Broker que ce projet est sortie de sa léthargie? ;-)
Nous avons considéré qu'il était mort car aucune modification n'était apportée pendant de très longs mois. Là encore, nous avons proposé des patchs, proposer de nouvelles orientations et du temps de développement. Nous attendons toujours une réponse sur ce sujet ;-)
[^] # Re: Comparatif intéressant mais...
Posté par H4wkmoon . Évalué à 6.
Ethan ne joue plus le jeux de la communauté depuis des années. La communauté, et Mérethis ont faits de nombreux efforts et a toujours trouvé porte close.
Lors du fork de Icinga, Merethis a même soutenu Ethan, mais du se rendre à l'évidence et créer son fork à son tour.
Tout comme Jean avec Shinken.
Tous ont cherché à faire avancer Nagios, sans réponse de Ethan, sans explications.
Au bout d'un moment, si tu veux faire avancer le sujet, et qu'on te claque la porte au nez, …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.