Intrégration perfparse et cie

[krbian]

Bonjour,

Comme l indique mon post, j ai quelque question sur l intégration :
Avec une architecture distribuée, on se rend vite compte de l intéret de réalier une mise en base de données à l'extérieur des plugins.
Il existe déja des addons remplissant ce role comme perfparse ou nagiosgrapher.
Néanmoins le plus connu est perfparse, lors de notre rencontre (julien et romain) vous nous avez parlé de l intéret que vous pretiez a perfparse, de plus tepluche et linagora on également choisi d'utiliser perfparse. Dans l avenir souhaitez vous intégrer perfparse à Oreon/Centreon? quand est il de son interface?

Pour rappel actuelllement nous utilisons notre propre module d'intégration qui nous permet d avoir plus de choix sur le support de DB.

[julio]

je suis actuellement en train d'intégrer perfparse a l'interface d'Oreon. Ca avance pas mal. Je pense qu'on va rester sur perfparse mais bon si tu arrive à nous convenir que tu as mieux, pourkoi pas... C'est du fait maison chez vous ?

[krbian]

La raison pour laquelle je n ai pas choisi perfparse est parceque ce projet n avez pas bouger d un pouce depuis un bon moment, je ne voyais pas de support pour les versions avenir de nagios. Pour moi il s agissait d un probleme important pour l utiliser. De plus perfparse semble relier à une base de données genre SQL , aucune liaison avec les RRD par exmple.

Je ne connais pas perfparse car je ne l ai jamais tester mais penses tu qu il est capable de s adapter a nagios v2?

De plus avec un modules fait main on peut avec une perfdata => ne rien faire, stocker dans un fichier et/ou une base rrd et/ou une base sql et/ou etc...
Sachant qu'un patch sur rrdtool permet la création de graphs basé sur des base de données MySQL. Donc plus besoin de récréer une interface pour cette partie, c'est également une raison qui ma fait aller dans ce sens.

[julio]

ouais jepense qu'il est deja compatible nagios 2... car c'est les plugins qui importe plutot qu'autre chose. Apres la gestion de perfparse est intégrée a nagios2.

apres pour la mise en base RRD doit etre possible par un script externe comme tu le fait en fait. Par perfparse ca va etre dur. Mais je pense qu'on peut faire un mix de tout ca.

templuche va peut etre nous eclairer la dessus.

[templuche]

Bonsoir,

PerfParse gère bien sûr la version 2 de Nagios. Le projet ne bouge plus trop c'est vrai mais l'utilisation que nous en avons est suffisante. De plus, l'idée de base est géniale: mettre en base de données les données de performance, de plus sans avoir besoin de reconfigurer les hosts et les services.

PerfParse est modulaire: il peut être étendu pour stocker les informations dans n'importe quel type de bases de données. Cependant, dans ces cas là, il faudra refaire la partie interface web.

[krbian]

Bonjour,

Je vais tester perfparse pour voir si je peux faire des update RRD de la meme maniere avec perfparse.

Lorsque l on rajoute une nouvel check_command, comment perfparse reconnait la valeur intéressante à stocker/grapher ?? on le spécifie quelque par?

[julio]

il fait tout automatiquement.... il prend ce qu'il y a apres le | .

si c genre time=90s

il va te creer en base une metric time a laquelle il associera la valeur 90... et a chaque check il associera les nouvelles valeurs a cette metric.

[krbian]

ok d accord il faut donc que les plugins respecte scrupuleusement le format des plugins nagios officiels

question :
il existe plusieurs méthode pour l utilisation de perfparse
5.2. Periodic Nagios Log Parse
5.3. Nagios Invokes Perfparse
5.4. Periodic User Log Parse
5.5. Pipe to Perfparse

Laquelle prédomine dans une architecture distribué?

[julio]

ok d accord il faut donc que les plugins respecte scrupuleusement le format des plugins nagios officiels


Hé ouais... normal... en meme temps si on veut que nagios fonctionne bien il faut toujours aller dans ce sens je pense.

pour la methode je ne sais pas trop... moi j'utilise la Periodic User Log Parse..

[krbian]

Donc je viens d installer perfparse, et regarder ce qu il fait.
Il ne sauvegarde pas seulement les valeurs mais également les états en fait il redonne d une autre le reporting (trends) de nagios, non?

Je n ai pas vu comment rajouter un autre support de DB, quelqu un peut m éclairer?

note: sur le wiki de perfparse il y une archive nommé php_gui_for_perfparse

[templuche]

Bonjour,

Alors, on va essayer de reprendre dans l'ordre. J'utilise la méthode "Periodic User Log Parse".

Laquelle prédomine dans une architecture distribué?
Aucune. Toutes fonctionnent. Il est possible que chaque serveur collecteur (chaque serveur distribué) mette à jour la base de données.

Il ne sauvegarde pas seulement les valeurs mais également les états en fait il redonne d une autre le reporting (trends) de nagios, non?
Tout à fait. Cependant, l'interface de rendu n'est pas exeptionnelle, malheureusement.
Je n ai pas vu comment rajouter un autre support de DB, quelqu un peut m éclairer?
Il est possible de prendre le support Postgres à la place du support MySQL.

note: sur le wiki de perfparse il y une archive nommé php_gui_for_perfparse
Apparement, c'est exactement la même interface.

[krbian]

en fait je ne vois pas tres bien l interet de stocker l'etat du service en parlant de perfdata
pour moi les perfdata sont seulement les valeurs intéressante pour faire des courbes.

Pour ce qui du reste ca rssemble a peut de chose à ceux que l on peut faire avec une moulinnette dintégration sauf je n ai aucune idée pour mettre du rrdtool avec.

[krbian]

Voici un lien sur RRD et perfparse/nagios

http://wiki.perfparse.org/tiki-view_faq.php?faqId=5#q21

certains points sur RRD y sont énoncé comme le step fixe d une Base RRD vis à vis du check_interval

[templuche]

Bonsoir,

en fait je ne vois pas tres bien l interet de stocker l'etat du service en parlant de perfdata
Perfparse fait plus que stocker l'état du service. Il trace aussi des compte rendu de disponibilité pour les services stockés. Ce qui est très bien. Mais l'interface n'est pas "parlante": les utilisateurs préfèrent avoir un graphique de performance avec des courbes ou avoir un camembert de disponibilité sur un temps donné. Je désactive de mon côté la mise en base de données des états de service.

[julio]

et c'est koi la colonne state dans la table perfdata_service_bin ? c'est quoi comme state ca ? ca serait bete ca. parce que la table des status gonfle trop vite je trouve... c'est dommage.

[templuche]

Bonjour,

C'est l'état du service. Tout simplement.

[julio]

ok impec alors... donc pas besoin de garder les raw alors. a moins que... ;) mais bon moi j'en vois pas le besoin de garder les logs. surtout que comme tu dis l'interface donne pas grand chose comme info...

[krbian]

Dans mon cas, les seules valeurs qui devront etre mise en base c'est seulement les perfdata , une valeur numérique pas plus. Pour ceux qui est du non-numérique ca sera mis en fichiers (ex: trapsnmp)

Perfparse étend son périmètre a beaucoup d autre choses en stockant toutes les infos comme du reporting (de ce que j ai vu)

C'est plus un logparse....

[templuche]

On n'est pas obligé de les activer. Moi par exemple je désactive la mise en base de données des raw_data. Donc, je gagne en performance et en espace de stockage.

[julio]

moi de meme :D