Integration de Nagios et cacti

[pqpak]

Bonjour,
j'aimerais savoir combien d'éléments réseau peuvent être surveillés et combien de ports peuvent être graphés simultanément avec votre solution.

j'utilise cacti pour contrôler l'activité de mes ports mais je graphe aussi les erreurs.

la masse total de mon répertoire rra pour une année est de 700 Mo pour mon plus petit réseau.

avoir un seul outil serait réellement un gain considérable.

[DonKiShoot]

Importer les fichiers XML de Cacti, pourquoi pas.
Mais créer des « services »[1] pour chaque OID après avoir choisi l'équipement, je suis plus que sceptique.
En fait, je dirais que si le projet Oreon pouvait utiliser plusieurs outils de « perfdata » avec, par exemple, Perfparse et nagiosgraph (qui utilise précisément des bases RRD), ce serait sans doute mieux que de chercher absolument à s'interfacer avec Cacti car on perdra forcément ce qui faisait l'intérêt de l'un ou l'autre des deux projets et ce sera dommageable.
Pour arriver au niveau de Cacti et son « auto-détection » des services, il faudrait avoir une plus grande interaction avec les plugins et je ne sais pas encore dans quelle mesure cela est possible. Il faudra même sans doute envisager de perdre la compatibilité avec Nagios 1.x...

Dans ma solution on ne se base que sur le modèle perfdata (check_snmp etant compatible perfdata il me semble)
Nagiosgraph n'est rien qu'un système de plus qui mix les principes des check_graph et des perfdata.

Le choix a faire et de savoir si on stock en base (mysql,...) ou en rrd.
Je pense que c'est en base qu'Oreon peut faire le plus de chose avec les data car une fois que c'est en rrd, c'est plus compliqué d'extraire ce que l'on souhaite notamment à cause de la consolidation des data.

Je dirais que l'on ne s'interface pas avec cacti mais on profite de la synergie de cacti en utilisant son modèle pour faciliter auprès des utilisateurs la compréhension de cette nouvelle gestion de service (snmp) en économisant en plus du développement.

Que cacti perde son interet c'est dans la logique de l'évolution.
Cacti s'est arrété à ce qu'il savait faire le mieux.
Si il y a des plugins pour cacti permettant d'envoyer des alertes c'est que le besoin est là.
Ces outils doivent converger c'est nécessaire.

Je ne pense pas que nagios 1.x soit en danger vu le modèle proposé.
De toute façon Oreon va arreter le support de nagios 1.x ca me parait évident.

Tout ça c la logique de l'évolution et cela se fait rarement sans douleur :wink:

[1] : Ce qui tu appelles « services » sont des services, des commandes ou des plugins ?

Un service pour moi est un check.
Chaque host possède des services qui sont checké par des plugins.
Donc pour moi c'est un peu la même chose tout ça.

[surcouf]

Oui mais Cacti a une certaine philosophie et une certaine avance sur la façon d'ajouter de nouveaux hôtes. Il est possible, à partir d'un modèle et des définitions des sources, d'obtenir automatiquement la liste des interfaces ou partitions (via SNMP par exemple) et de cocher les éléments de notre choix pour qu'ils soient pris en compte. En outre et spécifique à SNMP, il existe un cache de ces instances afin de moins soliciter les équipements. Les scripts et addons de Cacti sont bien moins indépendants que les plugins de Nagios.
Que Cacti puisse interagir avec Nagios ou Oreon est une chose mais il y aura forcément des problèmes de conception entre les projets qu'il faudra résoudre. Devra-t-on utiliser Oreon pour ajouter de nouveaux hôtes et perdre l'excellente découverte automatique des instances (c'est du jargon SNMP) de Cacti ? Ou, au contraire, devra-t-on laisser à Cacti le soin d'ajouter de nouveaux hôtes ? Et dans ce cas, comment réaliser des alertes sur dépassement de seuils avec Oreon/Nagios ?

Oreon n'a qu'a avoir ègalement ses modèles de requêtes snmp.
Mais l'idéal et pour ne pas réinventer la roue, serait d'être full compatible avec les fichiers xml de cacti et ainsi proposer le même type de système de découverte des interfaces.
Ce qui est assez simple quand on s'appuie sur un modèle de gestion existant (à savoir cacti).
Cacti étant trés trés mature, il est évident que leur modèle tant à être le meilleur dans ce qu'on leur demande de faire.

Exemple d'intégration à Oreon :

Tu exportes tes modèles xml de cacti et tu les réimportes dans Oreon.
Tu choisi un équipement dans Oreon.
Tu cliques par exemple sur une nouvelle catégorie 'multi service'.
A ce moment là, tu accèdes à un choix de modèles de requetes (les fameux fichiers xml importé).
Tu selectionne les requetes qui t'interesses à l'aide de checkbox par exemple.
Tu clique sur 'vas y mémère'.
En retour des scripts xml (donc des requetes snmp), Oreon recois les oid qui répondes avec leur valeur.
Oreon te propose alors de créer pour toi autant de service check_snmp (compatible perfparse) que d'OID valide avec possibilité de nommer ces checks.
Tu coche tes checkbox, en face tu donnes un nom à ton check.
Tu rempli en dessous, par exemple, les paramêtres commun à tes X OID et tu clique sur enregistrer.

Importer les fichiers XML de Cacti, pourquoi pas.
Mais créer des « services »[1] pour chaque OID après avoir choisi l'équipement, je suis plus que sceptique.
En fait, je dirais que si le projet Oreon pouvait utiliser plusieurs outils de « perfdata » avec, par exemple, Perfparse et nagiosgraph (qui utilise précisément des bases RRD), ce serait sans doute mieux que de chercher absolument à s'interfacer avec Cacti car on perdra forcément ce qui faisait l'intérêt de l'un ou l'autre des deux projets et ce sera dommageable.
Pour arriver au niveau de Cacti et son « auto-détection » des services, il faudrait avoir une plus grande interaction avec les plugins et je ne sais pas encore dans quelle mesure cela est possible. Il faudra même sans doute envisager de perdre la compatibilité avec Nagios 1.x...


[1] : Ce qui tu appelles « services » sont des services, des commandes ou des plugins ?

[daikinee]

Pour ceux que ca interesse, c'est en gros comme cela que j'affiche mes graphes RRD par Cacti :

http://forums.cacti.net/about12202.html

Oreon progresse à grande allure mais pour l'instant je conserve Cacti en attendant mieux.

[DonKiShoot]

Oui mais Cacti a une certaine philosophie et une certaine avance sur la façon d'ajouter de nouveaux hôtes. Il est possible, à partir d'un modèle et des définitions des sources, d'obtenir automatiquement la liste des interfaces ou partitions (via SNMP par exemple) et de cocher les éléments de notre choix pour qu'ils soient pris en compte. En outre et spécifique à SNMP, il existe un cache de ces instances afin de moins soliciter les équipements. Les scripts et addons de Cacti sont bien moins indépendants que les plugins de Nagios.
Que Cacti puisse interagir avec Nagios ou Oreon est une chose mais il y aura forcément des problèmes de conception entre les projets qu'il faudra résoudre. Devra-t-on utiliser Oreon pour ajouter de nouveaux hôtes et perdre l'excellente découverte automatique des instances (c'est du jargon SNMP) de Cacti ? Ou, au contraire, devra-t-on laisser à Cacti le soin d'ajouter de nouveaux hôtes ? Et dans ce cas, comment réaliser des alertes sur dépassement de seuils avec Oreon/Nagios ?

Oreon n'a qu'a avoir ègalement ses modèles de requêtes snmp.
Mais l'idéal et pour ne pas réinventer la roue, serait d'être full compatible avec les fichiers xml de cacti et ainsi proposer le même type de système de découverte des interfaces.
Ce qui est assez simple quand on s'appuie sur un modèle de gestion existant (à savoir cacti).
Cacti étant trés trés mature, il est évident que leur modèle tant à être le meilleur dans ce qu'on leur demande de faire.

Exemple d'intégration à Oreon :

Tu exportes tes modèles xml de cacti et tu les réimportes dans Oreon.
Tu choisi un équipement dans Oreon.
Tu cliques par exemple sur une nouvelle catégorie 'multi service'.
A ce moment là, tu accèdes à un choix de modèles de requetes (les fameux fichiers xml importé).
Tu selectionne les requetes qui t'interesses à l'aide de checkbox par exemple.
Tu clique sur 'vas y mémère'.
En retour des scripts xml (donc des requetes snmp), Oreon recois les oid qui répondes avec leur valeur.
Oreon te propose alors de créer pour toi autant de service check_snmp (compatible perfparse) que d'OID valide avec possibilité de nommer ces checks.
Tu coche tes checkbox, en face tu donnes un nom à ton check.
Tu rempli en dessous, par exemple, les paramêtres commun à tes X OID et tu clique sur enregistrer.

Et le tour est joué :wink:

Bien sur Oreon aura d'ici là un moteur d'affichage des graphs permettant de voir plus d'un ghraph à la fois.

[surcouf]

Que cacti se dirige vers nagios (generation d'alerte) ou qu'oreon aille vers cacti (historisation) cela me semble naturel

Le but c'est de n'avoir qu'un soft pour n'avoir qu'un check et un résultat stocké en base avec une seul alerte reçu.

Oui mais Cacti a une certaine philosophie et une certaine avance sur la façon d'ajouter de nouveaux hôtes. Il est possible, à partir d'un modèle et des définitions des sources, d'obtenir automatiquement la liste des interfaces ou partitions (via SNMP par exemple) et de cocher les éléments de notre choix pour qu'ils soient pris en compte. En outre et spécifique à SNMP, il existe un cache de ces instances afin de moins soliciter les équipements. Les scripts et addons de Cacti sont bien moins indépendants que les plugins de Nagios.
Que Cacti puisse interagir avec Nagios ou Oreon est une chose mais il y aura forcément des problèmes de conception entre les projets qu'il faudra résoudre. Devra-t-on utiliser Oreon pour ajouter de nouveaux hôtes et perdre l'excellente découverte automatique des instances (c'est du jargon SNMP) de Cacti ? Ou, au contraire, devra-t-on laisser à Cacti le soin d'ajouter de nouveaux hôtes ? Et dans ce cas, comment réaliser des alertes sur dépassement de seuils avec Oreon/Nagios ?

[thoms]

Que cacti se dirige vers nagios (generation d'alerte) ou qu'oreon aille vers cacti (historisation) cela me semble naturel

Le but c'est de n'avoir qu'un soft pour n'avoir qu'un check et un résultat stocké en base avec une seul alerte reçu.

++++1

Et si possible un seul Oreon pour configurer le tout :-)

[DonKiShoot]

Que cacti se dirige vers nagios (generation d'alerte) ou qu'oreon aille vers cacti (historisation) cela me semble naturel

Le but c'est de n'avoir qu'un soft pour n'avoir qu'un check et un résultat stocké en base avec une seul alerte reçu.

[surcouf]

oauis mais en intégrant nagios.

ça me fait penser qu'il a des extensions pour Cacti comme :
- Nagios Plugins for Cacti ;
- Thresold (qui permet de générer des alertes sur dépassement de seuils).

Je précise toutefois que je n'ai pu tester ni l'un ni l'autre.

[julio]

oauis mais en intégrant nagios.

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

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

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

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.

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