features pour lister les host/sondes

[Sauron De Mordor]

cela serais bien d avoir un filtre (dynamique ou non) pour afficher la liste des services (en detail)

quand on en a bcp et que l on a pls pages, c est pas pratique de chercher un host; car on ne sais pas si cest la page 5 ou 10 ou 34


ce filtre serais top si c etait un expression rationelle (php permet ca assez facilement)

[julio]

t'as un moteur de recherche sinon, mais nous savons que nous devons améliorer ca...

on étudie...

[templuche]

e filtre serais top si c etait un expression rationelle (php permet ca assez facilement)

En fait c'est déjà présent. Tu as une partie recherche. Tu peux utiliser les expressions SQL. Par exemple:

Linux_%_/usr%_Usage

Ceci va te trouver les éléments suivants s'ils sont présents:

Linux_FileSystem_/usr/local_Usage
Linux_Nfs_/usr/local/export/serveur1_Usage
Linux_FileSystem_/usr/local/tmp_FreeSpace
...

[Sauron De Mordor]

heu, je pense pas qu on parle de la meme chose.

le moteur de recherche c est gentil mais ou se trouve il ? si c est celui de id card, cela n a pas d interet pour moi.

car je veux avoir la main sur le fait de refaire un scan d une sonde pour un groupe de host


je suis sur la page oreon.php?p=20201&o=svc

ce qui me donne toutes les sondes / host ( qq miliers)
si je fais search avec le browser web, il ne me montre que ce qu il voit.
si j affiche toutes les sondes autant dire que mon pc s ecroule car la page doit affcher plus de 3000 elements

et si je met 100 elements par page, cela me fait un peu plus d un trentaine de pages.


et null par dans cette page je ne trouve ce que tu me dit a savoir une boite de daialogue de saisie d un filtre de recherche pour l afichage



en fait ce que je veut exprimer comme besoin c est bien un filtre d affichage, pas une recherche, un affinage en quelque sorte.

[templuche]

OK, tu parles de la visualisation des états? Moi je parlais de la partie configuration. C'est vrai que cela n'est pas présent sur la vue monitoring. Maintenant, je ne pense pas que ce soit quelque chose d'insurmontable. Tu peux regarde comment c'est fait dans la partie Configuration, faire la même chose dans le monitoring et envoyer le patch à l'équipe.

[julio]

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.

[templuche]

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?

[julio]

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

[Sauron De Mordor]

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.

[julio]

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...

[DonKiShoot]

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:

[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é...

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.

[DonKiShoot]

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:

[templuche]

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.

[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.