Merci beaucoup,
c'est un joli projet et j'espère que les autres devs seront receptifs.
J'ai quelques questions.
- Est-ce que les composants sont réutilisables sortis de l'ensemble?
par ex. peut-on réutiliser le parsing de conf pour faire autre chose? est-ce qu'ils ont une api "publique" ou seulement interne? (par ex. pour attaquer directement les scheduler et leur demander où ils en sont, changer leurs priorités, etc).
- En parlant de montée en charge ("scalability")...
comme le fait remarquer quelqu'un en réponse sur la m-l, l'essentiel de la durée d'execution d'un plugin type semble être passé à attendre (attente pour pouvoir écrire sur une socket, attente d'une réponse...) (plus le temps du exec() et envois du retour à nagios, bien sûr).
J'ai l'impression que l'execution des plugins en tant que commandes externes impose une limite au nombres de tests/seconde possibles : outre la surcharge de l'execution externe, en lancer un trop grand nombre simultanément (et même s'ils ne font pour ainsi dire rien d'autre qu'attendre, et quand bien même l'architecture à mutiple poller + NDX permettrai d'en lancer 10000 à la fois) signifirait saturer le/les système de processus sleeping.
Est-ce que des plugins très couramment utilisés comme check_tcp, check_http, et check_smtp pourraient être re-implementés en interne, et executés simultanément par multiplexage asynchrone et evenementiel de sockets ? par ex. en les regroupants quand c'est possible sur un seul (ou, disons, une poignée de) processus gerant x "checks classiques sur tcp ou udp ou raw (icmp)" et multiplexant via epoll()/kqueue() etc à la façon nginx/haproxy. Il existe plusieurs libs python pour faire ce genre de choses (twisted, mais il ne supporte pas IPv6, PyEvents, libevent-python...).
Le modèle des multiples pollers de shinken semble permettre ceci, au sens où avoir un couple de poller spécialisés/dédié aux checks de bases reposants sur tcp ne devrait pas empecher l'execution d'autres plugins en parralele (?).
- Quel est le niveau de compatibilité visé avec un nagios3 ?
seulement compatible au sens de pouvoir réutilise l'ancienne conf et certains plugins à condition d'y adjoindre des confs spécifiques à shinken ? générer un status.dat ? etc
# questions (réutilisations, multiplexage, compatibilité)
Posté par herodiade . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 5.
c'est un joli projet et j'espère que les autres devs seront receptifs.
J'ai quelques questions.
- Est-ce que les composants sont réutilisables sortis de l'ensemble?
par ex. peut-on réutiliser le parsing de conf pour faire autre chose? est-ce qu'ils ont une api "publique" ou seulement interne? (par ex. pour attaquer directement les scheduler et leur demander où ils en sont, changer leurs priorités, etc).
- En parlant de montée en charge ("scalability")...
comme le fait remarquer quelqu'un en réponse sur la m-l, l'essentiel de la durée d'execution d'un plugin type semble être passé à attendre (attente pour pouvoir écrire sur une socket, attente d'une réponse...) (plus le temps du exec() et envois du retour à nagios, bien sûr).
J'ai l'impression que l'execution des plugins en tant que commandes externes impose une limite au nombres de tests/seconde possibles : outre la surcharge de l'execution externe, en lancer un trop grand nombre simultanément (et même s'ils ne font pour ainsi dire rien d'autre qu'attendre, et quand bien même l'architecture à mutiple poller + NDX permettrai d'en lancer 10000 à la fois) signifirait saturer le/les système de processus sleeping.
Est-ce que des plugins très couramment utilisés comme check_tcp, check_http, et check_smtp pourraient être re-implementés en interne, et executés simultanément par multiplexage asynchrone et evenementiel de sockets ? par ex. en les regroupants quand c'est possible sur un seul (ou, disons, une poignée de) processus gerant x "checks classiques sur tcp ou udp ou raw (icmp)" et multiplexant via epoll()/kqueue() etc à la façon nginx/haproxy. Il existe plusieurs libs python pour faire ce genre de choses (twisted, mais il ne supporte pas IPv6, PyEvents, libevent-python...).
Le modèle des multiples pollers de shinken semble permettre ceci, au sens où avoir un couple de poller spécialisés/dédié aux checks de bases reposants sur tcp ne devrait pas empecher l'execution d'autres plugins en parralele (?).
- Quel est le niveau de compatibilité visé avec un nagios3 ?
seulement compatible au sens de pouvoir réutilise l'ancienne conf et certains plugins à condition d'y adjoindre des confs spécifiques à shinken ? générer un status.dat ? etc