Announcement

Collapse
No announcement yet.

features pour lister les host/sondes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • julio
    replied
    ca fait moins d'entrées en base pour rien.... mais bon je peux le mettre et voir le mettre en option...

    Leave a comment:


  • templuche
    replied
    oui mais le mieux n'est il pas de le definir dans le template de graph dans oreon ?
    Ca peut le faire aussi.

    Leave a comment:


  • julio
    replied
    oui mais le mieux n'est il pas de le definir dans le template de graph dans oreon ?

    Leave a comment:


  • templuche
    replied
    De meme que les min et max ? ca te sert a toi ? moi pas souvent voir jamais.
    Les min et max servent à fixer l'axe des ordonnées automatiquement. En effet, dans le cas d'un pourcentage par exemple les valeurs sont 0 et 100. Automatiquement le graph doit être dessiné avec ces valeurs au niveau des ordonnées.

    Leave a comment:


  • DonKiShoot
    replied
    Originally posted by julio
    De meme que les min et max ? ca te sert a toi ? moi pas souvent voir jamais.

    Ok de toute facon je communiquerai bientot la dessus.
    Oui mais il faut laisser la possibilité au gens de choisir, enfin je pense :roll:

    Leave a comment:


  • julio
    replied
    De meme que les min et max ? ca te sert a toi ? moi pas souvent voir jamais.

    Ok de toute facon je communiquerai bientot la dessus.

    Leave a comment:


  • templuche
    replied
    Je pense que c'est un sujet sur lequel on doit reflechir. Si perfparse est si lourd pourkoi pas refaire un module de remonté en base plus performant.
    Pourquoi pas... Pensez à regarder les optimisations que j'ai indiqué la dernière fois. Evitez aussi de stocker données numériques et les données d'états en même temps, ça prend trop de place et trop de temps. Bref si vous voulez un coup de main sur cette partie, n'hésitez pas.

    Leave a comment:


  • DonKiShoot
    replied
    Originally posted by julio
    Moi plus j'utilise perfparse, plus il me soaule... la base est bien trop grosse par rapport a ce qu'elle devrait etre, la compile, personnes y arrive et on est obligé sans arret d'explique a tout le monde comment faire,

    En plus, C'est un projet qui est a moitié abandonné...

    Tout mes clients me le disent clairement : "Pourquoi c'est si complexe et pourkoi si mal foutu ce truc : C'etait son premier projet au mec qu'a développé ca ou koi ? Y a pas moyen de mettre autre chose en place ?"

    donc a voir. mais moi je vais continuer mon truc et je vous le soumettrai.
    +1000 :wink:

    Leave a comment:


  • julio
    replied
    Moi plus j'utilise perfparse, plus il me soaule... la base est bien trop grosse par rapport a ce qu'elle devrait etre, la compile, personnes y arrive et on est obligé sans arret d'explique a tout le monde comment faire,

    En plus, C'est un projet qui est a moitié abandonné...

    De mon coté j'ai fait un parseur qui rentre tout dans une base perforeon. C'est 100000 fois plus simple a mettre en place: un cron. C'est en PHP, mais la je vais le faire en perl, pour aller plus vite. La base sans optimisation prend 4 fois moins de place (3 tables avec des indexe lié inodb). Et ca m'a pris 2 h de dev.

    Je pense que c'est un sujet sur lequel on doit reflechir. Si perfparse est si lourd pourkoi pas refaire un module de remonté en base plus performant.

    Tout mes clients me le disent clairement : "Pourquoi c'est si complexe et pourkoi si mal foutu ce truc : C'etait son premier projet au mec qu'a développé ca ou koi ? Y a pas moyen de mettre autre chose en place ?"

    donc a voir. mais moi je vais continuer mon truc et je vous le soumettrai.

    Leave a comment:


  • DonKiShoot
    replied
    Tant qu'on est dans les dev.

    Ne serait-il pas envisageable de livrer avec Oreon un perfparse optimisé qui stock par défaut en base, sans passer par un cron et tout une usine à gaz. Et dont les résultats en base seraient bien entendu compréhensible par Oreon.

    Le tout s'appuyant sur une version perfparse optimisé précité sur le forum et qui semble être trés bien pensé même si je n'ai malheureusement pas pu la tester car je ne connais qu'Oreon pour interpreter une base perfparse.

    PS: Le but serait de stopper les dev et la maintenance des check_graph pour se concentrer sur le moteur graphique et ne pas rougir devant cacti :wink:

    PS2: C'est juste un point de vu. Pas une directive :wink:

    Leave a comment:


  • julio
    replied
    la version alégée de la LCA est sur le svn...

    Pour la partie avec le script qui alege, c'est en cours, et NDO c pas pour maintenant encore...

    Leave a comment:


  • Sauron De Mordor
    replied
    c ets kool tout cela, et on peut l avoir ou cette petite perle?

    une version dispo bientot? ou une beta? une cvs/svn ?

    car je vais m approcher des 5000 ou 6000 sondes (mon serveur est dimensionne en consequence)

    pas forcement pour le ndo, mais pour la partie php, la partie ndo etant pour moi une phase2 de ma migration.

    Leave a comment:


  • julio
    replied
    D'Ethan lui même... Y a 2 semaines.

    Leave a comment:


  • templuche
    replied
    Cool! Très bonnes nouvelles. Merci pour ces informations.

    Surtout que future version de nagios, version 3, n'intégrera pas d'interface PHP. Il n'y aura encore que les même CGI.
    Ha bon? Je ne savais pas. Intéressant. D'où tiens tu cette information?

    Leave a comment:


  • julio
    replied
    Alors a ce niveau la nous avons deja patché...

    Le premier problème venait de l'implémentation de l'ACL qui ralentissait tout l'affichage. Nous avons modifié pour que tout soit bcp plus rapide.

    Ensuite nous avons donc patché pour que le moteur de recherche soit effectif dans le monitoring. Maintenant tout est fonctionnel. E plus, le monitoring a un rafraishissement en ajax pour un gain de temps.

    Le Seul problème maintenant est la grosseur du fichier de log de nagios qui est vraiment tres mal pensé.

    exemple :

    4900 hosts avec 4900 services => le fichiers de status fait 9Mo. Soit a chaque reload de page on lit ces 9Mo. Nous sommes arrivé sur un serveur en prod a 4s pour la lecture, avec analyse et compagnie.

    Nous sommes maintenant en train d'intégrer un script pour aleger la lecture du fichier en passant par un fichiers tiers, deja parsé avec tout sur une meme ligne qui nous fait passer par exemple la gosseur du fichier de 9Mo a 1Mo et de 455 000 lignes a 4500 lignes.

    Pour le futur nous avons déja préparé l'intégration de NDo qui rendrait la visualisation quasiement instantanée avec des moteur de recherche poussé en ajax (autocomplétion) et des vues comnfigurables à la demande...

    Si pour le moment la partie monitoring d'oreon n'est pas son point fort, Je pense que pour la suite on ne pourra plus s'en passer. Surtout que future version de nagios, version 3, n'intégrera pas d'interface PHP. Il n'y aura encore que les même CGI.

    voila pour notre avancement de ce coté la.

    Leave a comment:

Working...
X