Si tu en as la possibilité, je t'invite à te faire ta propre opinion sur ce sujet. Le trac te permettra de consulter, et de suivre les évolutions du logiciel.
Je suis passablement agace par le fait que chaque fois que l'on parle de Vigilo, il faut le comparer a Centreon.
Cela est généralement accompagne de critiques lies au code de l'outil.
Quel est l'intérêt d'une telle manœuvre ? Cette déstabilisation doit servir des intérêts économiques je suppose, CS ne donnant pas dans le libre par pur altruisme.
Donc d'un cote ça me rassure, car cela prouve bien que Centreon tend a devenir une référence, et c'est un juste retour des choses compte tenu de l'investissement de la communauté depuis des années.
Mais malheureusement, par l'initiative de certains qui veulent entretenir cette fausse concurrence, on se retrouve avec deux projets intéressants tous les deux discrédités, et cela sans finalement aborder le fond de la réflexion.
Est ce que les services rendus sont efficaces ?
Est ce que le support de Nagios est assure ?
L'outil trouve t il son public ?
Qu'en est il de la pérennité des solutions ?
Ensuite tout a chacun de valider quel est l'outil qui lui convient.
J'évite, pour ma part, de parler de ce que je ne connais pas, et je peux a ce titre vous garantir que Centreon couvre énormément de besoins pour le réseau, le système, l'applicatif.
Les process de supervision, alerting, reporting et présentation y sont présents et tout a fait fonctionnels.
Maintenant, certains préfèrent Zabbix, Vigilo, Cacti, HPOV ;-), chacun a sa sensibilité et ils ont surement raison. Mais merci de ne pas/plus réduire Centreon a un code sans commentaires, et pauvre fonctionnellement.
Dites moi plutôt qu'on ne fait pas d'auto découverte, qu'on devrait plus s'interfacer avec GLPI/OCS, que l'arborescence et l'héritage des templates devraient être mieux présentes, les filtres du monitoring devraient apportes plus de valeur ajoutée etc...
Car matt23, je ne vais pas troller avec toi, je t'invite juste a nous prendre contact avec nous pour essayer de freiner/calmer ta hargne.
Et je vous invite d'ailleurs tous, lecteurs et fans de la supervision, a vous inscrire sur nos plateformes d'échange (http://en.doc.centreon.com,http://trac.centreon.com/) et donner vos idees, avis et autres commentaires constructifs.
Je serais également présent vendredi prochain au RMLL, conférence de 11h00 après FAN et Vigilo. Cette présentation ne sera pas du tout d'un niveau "confirme", comme il l'est écrit sur le programme :-)
J'aurais beaucoup de plaisir a vous rencontrer si vous m'en donnez l'occasion (Aurelien ;-) )
PS: Courage Vigilo, plus on avance, moins on fait l'unanimite.. ;-)
Centreon a subit de nombreuses améliorations faisant suite aux retours des utilisateurs, et est a ce jour facile a prendre en main pour n'importe quel développeur qui souhaiterait y rajouter des fonctionnalités.
Je peux citer a ce titre le moteur de template Smarty, quelques libraires PEAR assez pratiques (Quickform, DB...) ou encore RRDTool.
Il existe il est vrai quelques failles de sécu, mais des contributeurs bienveillants les remontent et nous donnent les pistes pour les corriger.
Le script d'installation est un reliquat de la version 0.01 de Centreon et a été repris de 0 pour la prochaine version 2.
Donc mis à part le dernier point, je te trouve vraiment dur avec le produit, et tes critiques largement injustifiées, surtout que l'équipe travaille dur sur la prochaine version 2.
Quand à Vigilo, deux choses, soit c'est un coming out qui explique ton post, soit tu ne l'as pas encore eu entre les mains ;-)
Oui effectivement au niveau du monitoring dans les versions precedentes on manquait de filtres de vues. C'est quelque chose qui a ete retravaille, notamment les vues ou on separent les problemes acknowledges de ceux qui ne le sont pas.
La tactical overview est bien sur plus pertinente que les camemberts de depart, et c'est par manque de temps (et oui bcp de gens attendaient quand meme cette version ;-) ), que nous avons decide pour la 1.4 de ne pas aller plus en profondeur sur la page de login. Mais comme tu t'en doutes, ca sera implemente dans les prochaines.
Effectivement il a fallu faire des concessions par rapport a l'interface de Nagios et peut etre perdre un petit peu par rapport a la navigation originelle.
Le fait est que maintenant, tu n'es pas perdant au change, on reprend la majeure partie des fonctionnalites de Nagios tout en ajoutant un lot tout aussi interessante.
Oreon n'est pas simplement une reprise des pages existentes, mais avec le temps un outil qui le complete bien et le rend disponible a un large public.
Si on avait voulu faire un framework qui liste les etats courants de ressources, je pense qu'on aurait pu faire mieux c'est vrai, mais en fait ce n'est pas ca Oreon...
Je serais heureux de te faire une demo du produit pour que tu voies l'interet qu'il existe de passer sur du Oreon (pour ta boite et donc toi :p). Apres ca et un peu de pratique j'imagine qu'un Nagios addict comme toi aurait de bonnes remarques a nous faire suivre sur l'evolution du produit.
RRDTool a toujours ete dans Oreon, depuis la 0.1 meme.
En fait nous avons ete tout le temps convaincu du potentiel de ce moteur de graph, les changements ont résidé dans la maniere de creer/visionner les données de performance.
Le premier choix, et toujours fonctionnels, quoique nous ne le conseillons plus, est d'utiliser les plugins graphiques "check_graph". Ils renvoient des informations a Nagios (code d'erreur + output) et peuplent simultanement une base rrd physique.
La limitation est qu'il faut retaper tous les plugins existants et que dans le cas de supervision distribuée c'est assez limité car les bases rrd sont crees à l'endroit d'exécution du plugin.
Le second choix a été de créer des graphs rrd "a la volee" sur la base des metrics remontees dans perfparse (1.3.x). L'idée était bonne car nombre de plugins ont adopté ce format de retour d'informations et cela nous permet de centraliser les donnees.
La limitation vient du fait que perfparse est assez lourd a entretenir et son schema SQL offre peu de liberte.
Resultat, plusieurs secondes pour des graphs sur des periodes pas forcement enormes (et du coup qu'on veuille grapher plusieurs metrics dans le meme graph...) et dans le temps, la retention d'informations prend une place énorme.
La troisieme solution, actuelle et très performante :
Donner a l'utilisateur le choix dans sa remontee, bases rrd physiques et/ou base SQL, a partir des donnees de performances qui sont remontées.
L'interet est qu'on a des bases rrd physiques, donc tres rapides a grapher et facilement manipulables (cacti, pnp styles) et que ceux qui le desirent peuvent stocker les donnees de performance dans un nouveau modele de base de donnees (Oreon Data Storage), plus light et optimisé que perfparse afin de conserver dans le temps ses donnees, ou alors pour une exploitation exterieure (reporting...).
[^] # Re: La qualité du produit
Posté par Romain Le Merlus . En réponse à la dépêche Centreon 2.0 est sortie en version finale. Évalué à 2.
http://trac.centreon.com/
[^] # Re: Mouais
Posté par Romain Le Merlus . En réponse à la dépêche Vigilo : la solution de supervision libre pour les grands réseaux. Évalué à 6.
Je travaille sur le logiciel Centreon.
Je suis passablement agace par le fait que chaque fois que l'on parle de Vigilo, il faut le comparer a Centreon.
Cela est généralement accompagne de critiques lies au code de l'outil.
Quel est l'intérêt d'une telle manœuvre ? Cette déstabilisation doit servir des intérêts économiques je suppose, CS ne donnant pas dans le libre par pur altruisme.
Donc d'un cote ça me rassure, car cela prouve bien que Centreon tend a devenir une référence, et c'est un juste retour des choses compte tenu de l'investissement de la communauté depuis des années.
Mais malheureusement, par l'initiative de certains qui veulent entretenir cette fausse concurrence, on se retrouve avec deux projets intéressants tous les deux discrédités, et cela sans finalement aborder le fond de la réflexion.
Est ce que les services rendus sont efficaces ?
Est ce que le support de Nagios est assure ?
L'outil trouve t il son public ?
Qu'en est il de la pérennité des solutions ?
Ensuite tout a chacun de valider quel est l'outil qui lui convient.
J'évite, pour ma part, de parler de ce que je ne connais pas, et je peux a ce titre vous garantir que Centreon couvre énormément de besoins pour le réseau, le système, l'applicatif.
Les process de supervision, alerting, reporting et présentation y sont présents et tout a fait fonctionnels.
Maintenant, certains préfèrent Zabbix, Vigilo, Cacti, HPOV ;-), chacun a sa sensibilité et ils ont surement raison. Mais merci de ne pas/plus réduire Centreon a un code sans commentaires, et pauvre fonctionnellement.
Dites moi plutôt qu'on ne fait pas d'auto découverte, qu'on devrait plus s'interfacer avec GLPI/OCS, que l'arborescence et l'héritage des templates devraient être mieux présentes, les filtres du monitoring devraient apportes plus de valeur ajoutée etc...
Car matt23, je ne vais pas troller avec toi, je t'invite juste a nous prendre contact avec nous pour essayer de freiner/calmer ta hargne.
Et je vous invite d'ailleurs tous, lecteurs et fans de la supervision, a vous inscrire sur nos plateformes d'échange (http://en.doc.centreon.com, http://trac.centreon.com/) et donner vos idees, avis et autres commentaires constructifs.
Je serais également présent vendredi prochain au RMLL, conférence de 11h00 après FAN et Vigilo. Cette présentation ne sera pas du tout d'un niveau "confirme", comme il l'est écrit sur le programme :-)
J'aurais beaucoup de plaisir a vous rencontrer si vous m'en donnez l'occasion (Aurelien ;-) )
PS: Courage Vigilo, plus on avance, moins on fait l'unanimite.. ;-)
[^] # Re: IHM
Posté par Romain Le Merlus . En réponse à la dépêche Nagios 3.0. Évalué à 4.
Je peux citer a ce titre le moteur de template Smarty, quelques libraires PEAR assez pratiques (Quickform, DB...) ou encore RRDTool.
Il existe il est vrai quelques failles de sécu, mais des contributeurs bienveillants les remontent et nous donnent les pistes pour les corriger.
Le script d'installation est un reliquat de la version 0.01 de Centreon et a été repris de 0 pour la prochaine version 2.
Donc mis à part le dernier point, je te trouve vraiment dur avec le produit, et tes critiques largement injustifiées, surtout que l'équipe travaille dur sur la prochaine version 2.
Quand à Vigilo, deux choses, soit c'est un coming out qui explique ton post, soit tu ne l'as pas encore eu entre les mains ;-)
[^] # Re: Interface
Posté par Romain Le Merlus . En réponse à la dépêche Monitoring Oreon : sortie de la version 1.4. Évalué à 2.
La tactical overview est bien sur plus pertinente que les camemberts de depart, et c'est par manque de temps (et oui bcp de gens attendaient quand meme cette version ;-) ), que nous avons decide pour la 1.4 de ne pas aller plus en profondeur sur la page de login. Mais comme tu t'en doutes, ca sera implemente dans les prochaines.
[^] # Re: Interface
Posté par Romain Le Merlus . En réponse à la dépêche Monitoring Oreon : sortie de la version 1.4. Évalué à 2.
Le fait est que maintenant, tu n'es pas perdant au change, on reprend la majeure partie des fonctionnalites de Nagios tout en ajoutant un lot tout aussi interessante.
Oreon n'est pas simplement une reprise des pages existentes, mais avec le temps un outil qui le complete bien et le rend disponible a un large public.
Si on avait voulu faire un framework qui liste les etats courants de ressources, je pense qu'on aurait pu faire mieux c'est vrai, mais en fait ce n'est pas ca Oreon...
Je serais heureux de te faire une demo du produit pour que tu voies l'interet qu'il existe de passer sur du Oreon (pour ta boite et donc toi :p). Apres ca et un peu de pratique j'imagine qu'un Nagios addict comme toi aurait de bonnes remarques a nous faire suivre sur l'evolution du produit.
++
[^] # Re: Graphique : RRDTools ou Perfparse ?
Posté par Romain Le Merlus . En réponse à la dépêche Monitoring Oreon : sortie de la version 1.4. Évalué à 4.
En fait nous avons ete tout le temps convaincu du potentiel de ce moteur de graph, les changements ont résidé dans la maniere de creer/visionner les données de performance.
Le premier choix, et toujours fonctionnels, quoique nous ne le conseillons plus, est d'utiliser les plugins graphiques "check_graph". Ils renvoient des informations a Nagios (code d'erreur + output) et peuplent simultanement une base rrd physique.
La limitation est qu'il faut retaper tous les plugins existants et que dans le cas de supervision distribuée c'est assez limité car les bases rrd sont crees à l'endroit d'exécution du plugin.
Le second choix a été de créer des graphs rrd "a la volee" sur la base des metrics remontees dans perfparse (1.3.x). L'idée était bonne car nombre de plugins ont adopté ce format de retour d'informations et cela nous permet de centraliser les donnees.
La limitation vient du fait que perfparse est assez lourd a entretenir et son schema SQL offre peu de liberte.
Resultat, plusieurs secondes pour des graphs sur des periodes pas forcement enormes (et du coup qu'on veuille grapher plusieurs metrics dans le meme graph...) et dans le temps, la retention d'informations prend une place énorme.
La troisieme solution, actuelle et très performante :
Donner a l'utilisateur le choix dans sa remontee, bases rrd physiques et/ou base SQL, a partir des donnees de performances qui sont remontées.
L'interet est qu'on a des bases rrd physiques, donc tres rapides a grapher et facilement manipulables (cacti, pnp styles) et que ceux qui le desirent peuvent stocker les donnees de performance dans un nouveau modele de base de donnees (Oreon Data Storage), plus light et optimisé que perfparse afin de conserver dans le temps ses donnees, ou alors pour une exploitation exterieure (reporting...).
C'est mieux ? :p