• [^] # Re: questions (réutilisations, multiplexage, compatibilité)

    Posté par (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 1.

    En fait jusqu'à il ya une bonne grosse semaine, un poller était constitué de N workers qui sont un Poll de process pour Poller. Chacun lançait un et un seul check à la fois. Il "pollait" (oui ça fait beaucoup de poll ;) ) régulièrement la sonde lancée pour voir si elle était en vie.
    Le problème c'est que Python ça consomme un peu de RAM (non non, c'est vrai). Donc pour avoir 200 sondes en parallèles, il fallait 200 workers de 10Mo chacun. Ca commence à faire mal.

    C'est pourquoi j'ai diminué le nombre de worker, mais chacun peu lancer un certain nombre de sondes (par défaut 256, mais c'est configurable et surtotu limité par la limite sur le nombre de fichiers ouverts en même temps sur ton système). Il lance puis va poller régulièrement de la même manière chaque sonde. C'est un peu ce que tu proposes justement :)


    Pour le bypass du exec, je pense que le "moins pire" serait de déterminer au niveau du scheduler quel "plugin" utiliser suivant la tête (regexp) de la commande (ou bien si c'est direct dans le check_command, mais bon...). Il place l'info dans le check à effectuer, et le poller le fait gentiment. Si pas d'info de plugin, il exec().

    Ici le "plugin" est une sorte d'addon pour les daemons en gros. Pour l'instant seul celui qui récolte les informations en utilise, mais à terme d'autres vont en avoir :)