J'ai relu plusieurs fois les documentations (mail, wiki, ...), je suis toujours pas certain d'avoir bien tout compris.
Mais j'ai quand même remarqué un truc bien dommage : garder les fichiers de configurations originaux. Tant qu'à réécrire nagios, autant attaquer le problème à la racine. Je suis totalement d'accord que de garder la rétro-compatibilité est intéressant pour rendre les migrations moins douloureuses, mais dans ce cas je penses que c'est une erreur.
Les fichiers de configurations deviennent, à mon goût, ingérable rapidement (avec peu de hosts, services, ...), revoir ce point aurait été intéressant. Ces fichiers restes des fichiers qui contiennent énormément d'information et de garder des fichiers plats rend l'accès à cette information difficile. L'utilisation d'une base de donnée pour ça aurait été un vrai plus, mysql ou mieux un annuaire. De plus on aurait pu éliminer le "single point of failure" qui reste l'"arbitrer".
Ensuite il me semble qu'il y a sur-découpage des tâches. Je penses que le découpage schedulers/pollers est superflu. Ces deux éléments auraient pu être fusionner sans, à mon avis, trop impacter les performances.
Je dirais aussi que l'ensemble à l'air énormément complexe et effrayant, il y a plein de services qui sont nécessaire et chacun fait qu'un partie du travail. Un service indique l'action à faire, cette action est récupérée par un service qui fait l'action, le résultat est récupérer et stocker par un service et un autre service intervient pour faire les notifications. Il y a encore le service qui lit et transmet la configuration.
Ce que je me dis c'est qu'avec un système aussi complexe il faudrait peut-être un nagios pour surveiller que tous les services nécessaires à shinken tourne. C'est un peu l'impression que j'ai à lecture des documents.
Sinon joli travail quand même.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Vachement gore
Posté par Etienne Bagnoud . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
Mais j'ai quand même remarqué un truc bien dommage : garder les fichiers de configurations originaux. Tant qu'à réécrire nagios, autant attaquer le problème à la racine. Je suis totalement d'accord que de garder la rétro-compatibilité est intéressant pour rendre les migrations moins douloureuses, mais dans ce cas je penses que c'est une erreur.
Les fichiers de configurations deviennent, à mon goût, ingérable rapidement (avec peu de hosts, services, ...), revoir ce point aurait été intéressant. Ces fichiers restes des fichiers qui contiennent énormément d'information et de garder des fichiers plats rend l'accès à cette information difficile. L'utilisation d'une base de donnée pour ça aurait été un vrai plus, mysql ou mieux un annuaire. De plus on aurait pu éliminer le "single point of failure" qui reste l'"arbitrer".
Ensuite il me semble qu'il y a sur-découpage des tâches. Je penses que le découpage schedulers/pollers est superflu. Ces deux éléments auraient pu être fusionner sans, à mon avis, trop impacter les performances.
Je dirais aussi que l'ensemble à l'air énormément complexe et effrayant, il y a plein de services qui sont nécessaire et chacun fait qu'un partie du travail. Un service indique l'action à faire, cette action est récupérée par un service qui fait l'action, le résultat est récupérer et stocker par un service et un autre service intervient pour faire les notifications. Il y a encore le service qui lit et transmet la configuration.
Ce que je me dis c'est qu'avec un système aussi complexe il faudrait peut-être un nagios pour surveiller que tous les services nécessaires à shinken tourne. C'est un peu l'impression que j'ai à lecture des documents.
Sinon joli travail quand même.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell