- gestion de "MetaServices" (services aggrégeant les données d'autres services)
Peux-tu être plus précis ?
Ce qui me gêne davantage dans Oreon, pour l'avoir déployé chez de nombreux clients, ce n'est certainement pas le support de Nagios 2.
Encore qu'on peut se demander s'il le supporte car il pose la question de la version de Nagios dès l'installation.
Bien que de récentes réponses à des bogues que j'ai ouvert sur leur flyspray semblent avoir trouvé une issue, je n'ai pas encore vu leur application dans le cvs actuel. Et c'est ce manque de support presque complet de Nagios 1.x que je trouve gênant. Bien sûr, Oreon remplit très bien son rôle d'interface de configuration, évitant à des profanes d'éditer les fichiers de configuration de Nagios. Je regrette surtout que le développement soit trop proche de ces fichiers de configuration.
Sans doute aurait-il été plus pertinent d'en faire abstraction et de penser à faciliter la saisie des divers objets de la configuration, comme par exemple, ne pas dissocier les hôtes et les extensions d'hôtes (de même pour les services).
Et sur ce plan-là, Oreon ne facilite guère cette saisie. Il y a bien la duplication des hôtes, fonctionnalité qu'on avait demandé et merci beaucoup d'ailleurs. Mais je regrette certaines fonctionnalités qu'offre Nagios 1.x et que ne permette plus Oreon ! Surtout quand il s'agit de fonctionnalités qui ne sont pas insignifiantes, comme associer un service à un groupe d'hôtes ou créer un modèle à partir d'un autre modèle (quand on peut créer un modèle pour un objet, car tous les objets ne peuvent pas avoir de modèles alors que Nagios offre ces fonctionnalités...). Il s'agit là pourtant de fonctionnalités qui permettent justement de réduire, de simplifier la saisie... En fait, pour être honnête, je me suis souvent demandé si les développeurs d'Oreon connaissaient bien Nagios.
Et j'ai bien d'autres idées à développer à ce sujet, comme l'intégration de SNMPtt pour gérer les traps ou un meilleur support des options des plugins pour éviter que les profanes ne soient rebutés par cette phase de configuration.
Maintenant, je dois avouer que leur produit s'améliore et que l'équipe est ouverte aux suggestions et j'admet que ce n'est pas facile de développer une telle application. Les critiques sont faciles, l'art est difficile, comme on dit.
Donc, le support de Nagios 2.0 n'est pas la priorité pour moi, d'autant que pas mal de fonctionnalités changent, de nouvelles apparaissent et qu'il faudrait déjà valider cette version avant de pouvoir la déployer. Non, ce qui compte, c'est qu'Oreon supporte davantage et correctement Nagios 1.x, déjà, car ça profitera tout naturellement à Nagios 2.x.
[^] # Re: Pour une supervision professionnelle : Nagios + Oreon
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Sortie de Nagios 2.0. Évalué à 3.
Peux-tu être plus précis ?
Ce qui me gêne davantage dans Oreon, pour l'avoir déployé chez de nombreux clients, ce n'est certainement pas le support de Nagios 2.
Encore qu'on peut se demander s'il le supporte car il pose la question de la version de Nagios dès l'installation.
Bien que de récentes réponses à des bogues que j'ai ouvert sur leur flyspray semblent avoir trouvé une issue, je n'ai pas encore vu leur application dans le cvs actuel. Et c'est ce manque de support presque complet de Nagios 1.x que je trouve gênant. Bien sûr, Oreon remplit très bien son rôle d'interface de configuration, évitant à des profanes d'éditer les fichiers de configuration de Nagios. Je regrette surtout que le développement soit trop proche de ces fichiers de configuration.
Sans doute aurait-il été plus pertinent d'en faire abstraction et de penser à faciliter la saisie des divers objets de la configuration, comme par exemple, ne pas dissocier les hôtes et les extensions d'hôtes (de même pour les services).
Et sur ce plan-là, Oreon ne facilite guère cette saisie. Il y a bien la duplication des hôtes, fonctionnalité qu'on avait demandé et merci beaucoup d'ailleurs. Mais je regrette certaines fonctionnalités qu'offre Nagios 1.x et que ne permette plus Oreon ! Surtout quand il s'agit de fonctionnalités qui ne sont pas insignifiantes, comme associer un service à un groupe d'hôtes ou créer un modèle à partir d'un autre modèle (quand on peut créer un modèle pour un objet, car tous les objets ne peuvent pas avoir de modèles alors que Nagios offre ces fonctionnalités...). Il s'agit là pourtant de fonctionnalités qui permettent justement de réduire, de simplifier la saisie... En fait, pour être honnête, je me suis souvent demandé si les développeurs d'Oreon connaissaient bien Nagios.
Et j'ai bien d'autres idées à développer à ce sujet, comme l'intégration de SNMPtt pour gérer les traps ou un meilleur support des options des plugins pour éviter que les profanes ne soient rebutés par cette phase de configuration.
Maintenant, je dois avouer que leur produit s'améliore et que l'équipe est ouverte aux suggestions et j'admet que ce n'est pas facile de développer une telle application. Les critiques sont faciles, l'art est difficile, comme on dit.
Donc, le support de Nagios 2.0 n'est pas la priorité pour moi, d'autant que pas mal de fonctionnalités changent, de nouvelles apparaissent et qu'il faudrait déjà valider cette version avant de pouvoir la déployer. Non, ce qui compte, c'est qu'Oreon supporte davantage et correctement Nagios 1.x, déjà, car ça profitera tout naturellement à Nagios 2.x.