Integration de Nagios et cacti

[thoms]

Bonjour,
Je ne sais pas vraiment où mettre ce topic alors je me lance ici.
Voila un moment que je cherche un moyen d'utiliser Nagios et Cacti tous les deux ensemble. J'ai bien essayé de regarder du coté des divers plugin pour nagios (perfparse, nagiosgrapher), mais je ne suis pas convaincu et j'ai du mal à me séparer de la souplesse d'usage de cacti.

Je cherche donc un moyen d'interface les deux chose pour éviter d'avoir deux poller pour faire la même chose (i.e. : nagios et cacti vont chercher les même choses).

Dans l'absolu, l'usage d'un poller unique et d'une base de données communs à Nagios et cacti serait la solution. Mais avant d'en arriver là, je pensais deja à stoquer les données issue de nagios dans les bases cacti. Voici mon idée : un peu comme cela fonctionne dans perfparse, on enregistre les données de performances dans un fichier tampon via nagios et les commandes Host Performance Data Processing Command et Service Performance Data Processing Command. Ensuite le poller de cati vient chercher ces données et les enregistrer dans les bases cacti.

La cerise sur le gâteau : rajouter des liens entre nagios et cacti pour la navigation.

Voila mon idée, qu'en pensez vous?

[Jm0u]

thoms ton idée est pas mal.

Mais pourquoi poster ce topic dans le forum de la communauté de Oreon ??

Jm0u

[thoms]

thoms ton idée est pas mal.
Mais pourquoi poster ce topic dans le forum de la communauté de Oreon ??

Surement parce que inconsciemment, j'ai du mal a envisager la conf de nagios sans oreon :-)

[Jm0u]

Ok je comprend mieux.

Mais quest ce que cacti fait de mieux ou fait que oreon n'a pas ??

Jm0u

[julio]

En fait tu voudrais qu'on fasse une api pour pouvoir voir les graphs de cacti dans oreon tout simplement nan ? car nous sommes en train de développer un module de remonté en base des données numérique remplacant perfparse. On pourra de plus choisir si on met les données dans une table mysql ou alors dans une base rrd. Tout ca sera fait a partir des perfdata.

Il reste maintenant qu'a faire une api pour avoir acces au données de cacti depuis oreon.

[DonKiShoot]

Ou améliorer le moteur graphique d'Oreon pour arriver à la précision de cacti.
Mais bon cacti est tellement complexe que si tu ne trouves pas ce que tu veux dans les templates par défaut, ni sur internet alors tu pars dans une galère terrible.

[daikinee]

En fait tu voudrais qu'on fasse une api pour pouvoir voir les graphs de cacti dans oreon tout simplement nan ? car nous sommes en train de développer un module de remonté en base des données numérique remplacant perfparse. On pourra de plus choisir si on met les données dans une table mysql ou alors dans une base rrd. Tout ca sera fait a partir des perfdata.

Il reste maintenant qu'a faire une api pour avoir acces au données de cacti depuis oreon.

Très bonne nouvelle !

Je trouvais l'idée de remplir les bases RRD directement dans les plugins de check pas terrible.

L'utilisation des perfdata fourni pas Nagios me semble donc une meilleur solution. Le fait que votre plugin supporte à la fois une BD et les fichiers RRD est très interressant.

En ce qui concerne Cacti, c'est vrai que c'est un vrai bazar. Je l'utilise en plus de Nagios car niveau présentation des graphes RRD il est à mon avis loin devant les autres logiciels. Cela oblige évidemment à faire des doubles déclarations des serveurs en conf et des doubles checks...

En ce qui me concerne j'ai viré les doubles checks en ne faisant pas tourner le poller de Cacti et en forçant le nom du fichier RRD dans la déclaration des "data sources" de Cacti.

[julio]

ca avance, on va revoir aussi du coup la visualisation des graphs... a la cacti

la nouvelle base sera plus rapide. On pourra donc generer plus vite et bcp plus simplement. Ca nous aidera bien.

[thoms]

Ou améliorer le moteur graphique d'Oreon pour arriver à la précision de cacti.
Mais bon cacti est tellement complexe que si tu ne trouves pas ce que tu veux dans les templates par défaut, ni sur internet alors tu pars dans une galère terrible.

Je ne suis pas tout à fait d'accord avec toi. Certes, cacti est complexe à configurer, mais j'ai l'impression que c'est le lot commun de tous les outils qui font des graphs. Une fois qu'on a compris les mécanismes de collecte de données et graph, c'est assez facile se faire ses propre outils de mesure.

J'ai peur que s'embarquer dans la réécriture d'un moteur 'a la cacti' ne soit particulière lourde et complexe alors que l'outil existe déjà.

En ce qui me concerne j'ai viré les doubles checks en ne faisant pas tourner le poller de Cacti et en forçant le nom du fichier RRD dans la déclaration des "data sources" de Cacti.

Ca m'interesse ca! Tu peux m'en dire plus ?

ca avance, on va revoir aussi du coup la visualisation des graphs... a la cacti
la nouvelle base sera plus rapide. On pourra donc generer plus vite et bcp plus simplement. Ca nous aidera bien.

Serait-il possible de s'interfacer avec Cacti, un peu la manière de ce que suggère daikinee?

[julio]

qu'est ce qu'il te manque absoluement et qui est dans cacti ? l'arbo ? les vues, les options ? Donnes tes besoins et moi je les integre. je pense que c'est vraiment pas complexe. Ca peut aller vite.

[DonKiShoot]

qu'est ce qu'il te manque absoluement et qui est dans cacti ? l'arbo ? les vues, les options ? Donnes tes besoins et moi je les integre. je pense que c'est vraiment pas complexe. Ca peut aller vite.

+1

Ca evitera de multiplier les outils de monitoring.
Même si on n'arrive pas au niveau de cacti, le but c'est d'avoir de beau graph dans un format lisible par tous.

[thoms]

J'utilise deja nagios et cacti en parallèle. Nagios me sert à suivre un certain nombre d'indicateurs d'état (ping, état de disques sur des serveurs, température de capteurs sur des serveurs, etc) sur des serveurs locaux et distant via un réseau WAN. D'un autre coté, j'utilise cacti pour avoir un historique principalement pour l'utilisation des interfaces réseaux de mes routeurs et de mes switches sur les principaux sites. Tous les ports de cascade sont suivis ce qui me permet rapidement d'analyser les problèmes.

Ce j'apprécie dans cacti :
- la vue arboresence comme tu l'as dis,
- les zoom en javascript sont vraiment sympas,
- les temps de réponses toujours impeccables,
- la portabilité des template (data, graph) : le partage des graphs et des sources de données (OID, scripts etc.) est super simple.
- la gestion super simple des interfaces multiples sur un même host via snmp. Plus généralement, la gestion des données indexées dans SNMP.
- la tailles limitées des bases de données des stats. Mon installation cacti surveille 96 hosts et compte 900 sources de données, 500 graphs et les .rrd occupent 114Mo.
- La possibilité de poller et grapher n'importe quoi : par exemple, je fais des tests temps de réponse HTTP sur des sites internet (yahoo, google, et d'autres sites professionnels) qui me servent à avoir une idée de la qualité de service HTTP pour mes utilisateurs, mais je n'ai pas d'alerte correspondante dans Nagios.
- La facilité d'ajout un element standard, surtout si le template est défini.
- Il y aussi le fait que c'est un outil que j'utilise depuis un moment et qu'il y a toujours une résistance (involontaire) au changement :-(

Maintenant, si vous arrivez à intégrer les fonctionnalités de Cacti dans Oreon et Nagios avec la même ergonomie, ca peut le faire.

Cela dit, le fait que l'on soit toujours toujours dépendant de Nagios pour faire le polling peut aussi être gênant : par exemple pour grapher les stats réseaux de mes interfaces, cela n'est pas faisable avec la même simplicité que Cati où le template SNMP par défaut permet deja de faire beaucoup de chose.

[julio]

- la vue arboresence comme tu l'as dis,

Ca c'est pas la mort. En y reflechissant bien, oreon doit etre capable de le faire très vite

- les zoom en javascript sont vraiment sympas,

Oui ca on sait et on est conscient. A etudier

- les temps de réponses toujours impeccables,

Pourquoi oreon est long ?

- la portabilité des template (data, graph) : le partage des graphs et des sources de données (OID, scripts etc.) est super simple.

une api XML simple peut etre bien faire l'affaire

- la gestion super simple des interfaces multiples sur un même host via snmp. Plus généralement, la gestion des données indexées dans SNMP.

oui

- la tailles limitées des bases de données des stats. Mon installation cacti surveille 96 hosts et compte 900 sources de données, 500 graphs et les .rrd occupent 114Mo.

la je pense que nous ne sommes pas plus gros. C'est RRD qui gere ca et en rien cacti

- La possibilité de poller et grapher n'importe quoi : par exemple, je fais des tests temps de réponse HTTP sur des sites internet (yahoo, google, et d'autres sites professionnels) qui me servent à avoir une idée de la qualité de service HTTP pour mes utilisateurs, mais je n'ai pas d'alerte correspondante dans Nagios.

dans oreon actuellement tu peux aussi poller et grapher tout ce que tu veux....

- La facilité d'ajout un element standard, surtout si le template est défini.

idem

- Il y aussi le fait que c'est un outil que j'utilise depuis un moment et qu'il y a toujours une résistance (involontaire) au changement Sad

ha ouais mais ca je ne peux rien y faire sauf te convaincre qu'en avancant tous les deux dans le meme chemin on peut aller plus vite.

Cela dit, le fait que l'on soit toujours toujours dépendant de Nagios pour faire le polling peut aussi être gênant : par exemple pour grapher les stats réseaux de mes interfaces, cela n'est pas faisable avec la même simplicité que Cati où le template SNMP par défaut permet deja de faire beaucoup de chose.

moi ca me prend 3 coups de clicks, Une modification d'id au clavier et un redemarrage de nagios. Cependant il faut avoir aussi défini ses templates et tout ce qu'il faut avant de déployer. La méthodo est primordiale.

Donc je pense qu'on peut tres vite avori les meme fonctionnalités. Et on aura un plus meme si on est pas meilleur, c'est que oreon nagios alerte et il y aura encore une autre chose c'est que pour remonter le traffic sur un port :

nagios + cacti = 2 checks pour grapher et surveiller
oreon = 1 check

donc la je pense que c toujours mieux.

[thoms]

Pourquoi oreon est long ?

Oreon non. Perfparse oui. L'affichage des graphs dans Oreon rammait chez moi avant que je n'ajoute quelques indexes (faisant exploser la taille de la bdd deja sujette à un embonpoint certain ;-) ). Maintenant je n'ai pas encore utilisé de graph basé sur RRD avec Oreon.

nagios + cacti = 2 checks pour grapher et surveiller
oreon = 1 check
donc la je pense que c toujours mieux.

+1

Un gros plus serait de pouvoir grapher les informations disponibles via la MIB SNMP basique (interfaces réseaux, CPU, espace disques, mémoire) en quelques clics avec un Oreon fraichement installé (sous la forme de templates et d'un tuto qui va bien?).

[surcouf]

Pourquoi oreon est long ?

Oreon non. Perfparse oui. L'affichage des graphs dans Oreon rammait chez moi avant que je n'ajoute quelques indexes (faisant exploser la taille de la bdd deja sujette à un embonpoint certain ;-) ). Maintenant je n'ai pas encore utilisé de graph basé sur RRD avec Oreon.

nagios + cacti = 2 checks pour grapher et surveiller
oreon = 1 check
donc la je pense que c toujours mieux.

+1

Un gros plus serait de pouvoir grapher les informations disponibles via la MIB SNMP basique (interfaces réseaux, CPU, espace disques, mémoire) en quelques clics avec un Oreon fraichement installé (sous la forme de templates et d'un tuto qui va bien?).

Refaire Cacti en somme...