Schema centreon

[julio]

Krbian pourrai tu poster le schema fonctionnel que tu as pensé ? ca iunterresserai bcp de monde ici je pense.. rien que pour comprendre...

Apres a mon avis les idées vont fuser

[krbian]

ok c'est parti...

je pense que le schéma est en soit assez clair mais pour toutes précisions n'hésitez pas.

Dans cette archi, la finalité est d'avoir une interface oreon sur chaque serveur integration. Mais un seul actif au meme moment. La réplication de conf entre les deux serveurs d'intégration peut etre fait je pense par une replication de DB oreon. Par Contre pour ceux qui de la gestion des serveurs distribués, c'est la qui faut eclaircir.

le schéma a été enlévé volontairement

[templuche]

Bonjour à tous,

Tout d'abord, bravo pour ce superbe schéma. Il est clair, documenté (légende), ect. Beau travail.

J'aimerais avoir un peu plus de détails. Qu'est ce que le "cache"? Est ce un système de fichier partagé? Si oui, par quel moyen souhaitez vous le géré (SMB/CIFS ou NFS ou SSH ou ...)?

Je suppose que les flèches rouges qui font le lien entre "Configuration et Visualisation" et les CS sont pour la mise à jour de la configuration. C'est bien cela? Si oui, j'ai du mal à voir pourquoi elles sont dans les 2 sens. Ne devraient elles pas être dans le sens suivant uniquement?
"Configuration et visualisation" ---> CS

Comment seront réintégrés les RRD sur le serveur de visualisation? Avez vous songé au problème des id identiques sur plusieurs serveurs?

PS: quel outil utilises tu pour ce schéma?

[krbian]

Bonjour templuche

J'aimerais avoir un peu plus de détails. Qu'est ce que le "cache"? Est ce un système de fichier partagé? Si oui, par quel moyen souhaitez vous le géré (SMB/CIFS ou NFS ou SSH ou ...)?

Le systeme de cache : il s agit de deux repertoires, qui correspondent chacun à un serveurs intégration, ces repertoires sont remplis avec les fichiers perfdata sous le nom : $TIME$-perfdata. Ils s'accumulent dans le rep en attendant que le CS les récupère par rsync over ssh. Cela perlmet d eviter de perdre des données si jamais un site est isolé. Et la redondance permet de dissocier l'intégration en cas de probleme sur un des deux serveurs intégration.

Je suppose que les flèches rouges qui font le lien entre "Configuration et Visualisation" et les CS sont pour la mise à jour de la configuration. C'est bien cela? Si oui, j'ai du mal à voir pourquoi elles sont dans les 2 sens. Ne devraient elles pas être dans le sens suivant uniquement?
"Configuration et visualisation" ---> CS

Lors que j ai fait ce schéma je n avais pas de réelle idée sur la manière de plugguer oreon sur cette architecture. Dorénavement j en sais un peu plus : un serveur oreon sur chaque CS. Cette partie du schéma n est pas tout à fait exact.


Comment seront réintégrés les RRD sur le serveur de visualisation? Avez vous songé au problème des id identiques sur plusieurs serveurs?

Il s agit d un script intégration qui ouvre les perfdata-file et qui lit ligne par ligne les données perfdata et qui décide la maniere du stockage de l info => RRD et/ou SQL et/ou Fichiers.
De cette maniere je peux utiliser les plugins officiels de nagios sans modif.
Pour l'id (je suppose que c'est ceux des services) ils peuvent etre identiques ou différents sur les serveurs cela ne gene pas car , c'est seulement ceux stocké dans la DB du serveur intégration qui sont utiliser comme numéro de base.
Pour ceux qui du liens avec les services et les graph sur le CS. J ai defini une check_command : check_graph_passive qui est un simple script de rafraichissement lancé par les check_freshness. Le nom de la command contient "graph" donc le lien vers les graphs est activé et lors du clic oreon ouvre la page graph avec en parametre le sid du services qui est celui utilisé lors de l intégration. Donc au final, on a le meme résultat que update rrd c'est fait sur le CS dans le plugin.

L outil utilisé pour le schéma est Dia

[julio]

Moi je me pose une question : pourkoi avoir 2 bases de données intégrées sur les serveurs d'intégration ? pourkoi ne pas avoir un serveur de base de données redondé discocié du serveur de supervision. On y gagnerai je pense en complexité... ca serait moins complexe. une seule base pour les deux nagios. Car si je me rapelle bien, les deux serveur d'intégration ne fonctionne pas tous les deux en meme temps... Ai je bien compris ?

[krbian]

ne fonctionne pas tous les deux en meme temps
Dans un fonctionnement nominal si, mais le fait d avoir un décalage entre les deux processus d integration n est pas génant car leurs fichiers perfdata sont dédiés

pourkoi avoir 2 bases de données intégrées sur les serveurs d'intégration ? pourkoi ne pas avoir un serveur de base de données redondé discocié du serveur de supervision.
Je suis pour la base redondé pour la partie conf d oreon/nagios mais pas pour les données.
L experience nous a montré que lors de l isolement d'un site la visibilité de gens isolés sur un site est nul si jamais la coupure dure. Le fait de savoir que les données ne seront jamais perdu par un système de cache est bien mais ne permet d'avoir la visibilité durant ce genre de cas. Or c'est a ce moment que nous en avons le plus besoin.

[krbian]

Il s agit d un script intégration qui ouvre les perfdata-file et qui lit ligne par ligne les données perfdata et qui décide la maniere du stockage de l info => RRD et/ou SQL et/ou Fichiers.

J ai utilisé cette méthode pour être directement compatible avec nagios v2

[julio]

okok.... va valloir vraiment detailler tout ce que doit faire chaque nagios/oreon... dans les differents emplacements(SI, SA et interface..)..

il nous faudrait les fonctionnalité de chacun...

[krbian]

Le SA possède les services actifs check_snmp, tcp, et ping + quelque autres. Les perfdata sont activé sur ces services, avec une commande qui écrit dans un fichier :

/bin/echo -e "$LASTCHECK$&$HOSTNAME$&$SERVICEDESC$&$SERVICESTATE$&$OUTPUT$&$PERFDATA$" >> /usr2/cache/service-perfdata

Toutes les t un service est lancé qui va copier ce fichier dans les deux caches et le vider.

Sur le SI : tout les t, les fichiers sont récupéré via rsync et supprimé du cache.
et tout les t le script d intégration est appellé.
Chaque service défini sur les SA possède un frère jumeau en mode passif sur le SI.
Les résultats des infos sont transmis par NSCA.

il y a d autres précisions a apporté mais voila l essentiel du processus.

[julio]

mais au niveau des bases de données RRD etc sur chacun des postes... qu'est ce qu'il se passe .?... comment est synchronisé la base ? comment l'interface accede aux données et a quelle données (sur quel SI) ? si un SI est down, aller sur l'autre... etc etc .... tout le processus de fonctionnement...

[templuche]

Bonjour krbian,

ces repertoires sont remplis avec les fichiers perfdata sous le nom : $TIME$-perfdata
Ne peut il pas y avoir un problème lorsque les checks sont concurrents? Par exemple, si 5 checks sont lancés au même moment et se terminent au même moment, le $TIMET$ est identique pour tous les 5. N'y-a-t-il pas un problème à ce niveau là? Je suppose que c'est le serveur central qui efface les fichiers de performance?

Il s agit d un script intégration qui ouvre les perfdata-file et qui lit ligne par ligne les données perfdata et qui décide la maniere du stockage de l info => RRD et/ou SQL et/ou Fichiers. ai utilisé cette méthode pour être directement compatible avec nagios v2Je pense que c'est la meilleure méthode: la moins couteuse en terme de performances et ensuite on fait ce que l'on veut des données (SQL, RRD, on les met à la poubelle, ...).


Dorénavement j en sais un peu plus : un serveur oreon sur chaque CS
Mouais... N'est il pas plus simple de faire un serveur Oreon qui ne fera que la configuration et poussera les fichiers Nagios sur le serveur d'intégration choisi?


L outil utilisé pour le schéma est Dia
Sérieux? Chapeau!

[krbian]

Julio :
mais au niveau des bases de données RRD etc sur chacun des postes... qu'est ce qu'il se passe .?... comment est synchronisé la base ? comment l'interface accede aux données et a quelle données (sur quel SI) ? si un SI est down, aller sur l'autre... etc etc .... tout le processus de fonctionnement...

Les bases RRD n'existent que sur les SI par sur les SA, le SA stocke la valeur a sauvé dans les perfdata et ainsi le cycle de récupération fait le reste.

pour la synchro de la base je ne comprends pas tres bien

Pour l acces aux données chaque interface oreon a ces propres bases sql et rrd. Car les bases rrd doivent etre situées localement pour les graphs.
Si un SI est down , les stats continuent a etre intégrées sur l autre et il suffit d aller sur l autre interface pour les voir (chez nous ce switch de serveur pour une url est fait par la résolution dns)

Templuche:
Ne peut il pas y avoir un problème lorsque les checks sont concurrents? Par exemple, si 5 checks sont lancés au même moment et se terminent au même moment, le $TIMET$ est identique pour tous les 5. N'y-a-t-il pas un problème à ce niveau là? Je suppose que c'est le serveur central qui efface les fichiers de performance?

Non, ce n est pas a ce niveau qu 'est utilisé le $TIMET$ : tout les perfdata sont écrit dans le meme fichier, mais c'est lors de la copie dans le cache que je les tag pour en stocker plusieurs. Oui c'est le CS qui efface les fichiers apres un test de validité des fichiers (taille non nulle).

Mouais... N'est il pas plus simple de faire un serveur Oreon qui ne fera que la configuration et poussera les fichiers Nagios sur le serveur d'intégration choisi?
En réalité, c'est quasiment le cas. Il y aura un seul serveur qui effectue la config et qui push la conf sur les DS, la conf du CS esclave peut etre réalisé par une replication sql.
Je souhaite avoir deux interfaces pour que les deux sites principaux garde une visiblité a tous moment. Néanmoins un seul sera utilisé a un instant t.
Dans un premier tps je ne me fais pas de réelle soucis sur cette partie. vous n avez qu a imaginer un cluster du serveur de supervision principale.

Sérieux? Chapeau! MERCI :)

[julio]

Bon je pense qu'on ne va pas pouvoir faire oreon et centreon en une seule arbo... sinon on va tout peter et plus rien ne va marcher.. a mon avis va falloir creer une deuxieme arbo. De plus on vire une grosse partie de l'object donc c sera plus simple a mettre a jour...

je vais reflechir a la solution.

a mon avis y aura 2 oreon.

[krbian]

Voici l idée que je me suis faite du centreon : il s agit d un oreon capable de gérer x serveurs nagios en mode distribué. Sur lesquels on a pas besoin d avoir une visualiisation de l etat mais juste une "porte d entrée" de configuration.
c'est bien ca?

[templuche]

Hello,

En tout cas la conversation est très intéressante.

a mon avis y aura 2 oreon.
Un fork d'Oreon? Déjà? Ca va vite! :lol:

Plus sérieusement, je pense qu'il faut faire un tag dans le CVS pour faire une version de dev. Cette version de dev s'appellerait par exemple Oreon-2.0 et servirait à mettre en place Oreon+Centreon. Ensuite les personnes migreraient ou pas selon leur choix.

De plus on vire une grosse partie de l'object donc c sera plus simple a mettre a jour...
Tu veux supprimer la partie objet? C'est bien ça?

[templuche]

Voici l idée que je me suis faite du centreon : il s agit d un oreon capable de gérer x serveurs nagios en mode distribué. Sur lesquels on a pas besoin d avoir une visualiisation de l etat mais juste une "porte d entrée" de configuration.
c'est bien ca?
Je suis d'accord. Donc dans ce cas, on pourrait l'envisager comme une couche au dessus d'Oreon. Je ne sais pas si c'est possible et qu'elle est la meilleure solution: modifier Oreon pour qu'il Oreon+centreon ou ajouter une couche Centreon au dessus d'Oreon.

[julio]

Un fork d'Oreon? Déjà? Ca va vite! Laughing

non non pas un fork. Une evolution. le oreon 2.0 cest tout a fait ce que je pensais. la version 1.x reste une version simple d'oreon pour les petites et moyennes structures. La 2 est desormais une version plus evolué donnant les possibilités de gerer la supervision de structures complexes avec hotdispo... redondance etc etc. c oreon version pro on va dire.

Tu veux supprimer la partie objet? C'est bien ça?

Avec romain on a audité un peu tout ce qu'on avait fait. Ca sera la seul facon de gagner en memoire. Biensur des choses resterons en memoire de la session mais des choses qui ne prennent pas de place. Les conf de l'interface, de nagioscfg, etc... Mais tout ce qui est conf de nagios ne sera plus dans l'object. ca va aleger quand meme bcp les pages.

qu'en pense tu ?

[julio]

Je ne sais pas si c'est possible et qu'elle est la meilleure solution: modifier Oreon pour qu'il Oreon+centreon ou ajouter une couche Centreon au dessus d'Oreon.

c'est exactement la question que je me pose et a laquelle je n'arrive pas a repondre de meme. C'est pour ca qu'il faut faire une liste de tous les points techniques que nous devront modifier et ajouter pour que cela marche. Sans ces points techniques rien ne sera possible et il ne sera alors pas possible de faire du bon boulot.

je pense qu'on va commencer oreon+centréon sur une branche du cvs et continuer a avancer oreon sur une autre. Par la suite l'un remplacera l"autre. Sachant que les developpement seront rendu compatibles pour une mise a jour constantes des deux produits.

[templuche]

Avec romain on a audité un peu tout ce qu'on avait fait. Ca sera la seul facon de gagner en memoire. Biensur des choses resterons en memoire de la session mais des choses qui ne prennent pas de place. Les conf de l'interface, de nagioscfg, etc... Mais tout ce qui est conf de nagios ne sera plus dans l'object. ca va aleger quand meme bcp les pages.

qu'en pense tu ?
Ai je besoin de répondre à ça? :D C'est une très bonne idée.


C'est pour ca qu'il faut faire une liste de tous les points techniques que nous devront modifier et ajouter pour que cela marche.
Tout à fait d'accord.

je pense qu'on va commencer oreon+centréon sur une branche du cvs et continuer a avancer oreon sur une autre. Par la suite l'un remplacera l"autre. Sachant que les developpement seront rendu compatibles pour une mise a jour constantes des deux produits.
Très bon choix.

[krbian]

sur ce point j ai deja commencé (c'est juste un début) à y réfléchir un peu mais je vous laisse plutot juger :

la différence entre un service (en mode distr) situé sur un DS et CS est minime.
les 3 paramètres qui changent sont :
active_checks_enabled [0/1]
passive_checks_enabled [0/1]
check_command

Sachant que la check command sur le CS est toujours la meme,
Donc une premiere chose est donc de pouvoir séléctionner le DS sur lequel le service tourne. (un id de plus)

La configuration du Nagios.cfg doit par contre être possible pour tous.

La confiuration des host est exactement la meme sur un serveur CS et DS car nagios v1 ne supporte par la supervision distribué pour les host (contrairement a la v2)

Pour le processus de génération de conf je peux malheureusement peu vous aider : à définir la maniere la plus judicieuse à mettre en oeuvre mais mes collègues de PHP auront plus d idée que moi sur le sujet...

Pour le processus de déploiement de conf : un rsync et
ssh nagios@serveur -t 'nagios -v /etc/nagios.cfg'
ssh nagios@serveur -t '/etc/init.d/nagios restart'

[julio]

ha voila c bien ca... va falloir detailler tout les choses qui changent comme ca... c cool...

[krbian]

premiere étape :
pouvez vous monter une architecture distribué avec deux serveurs?

[templuche]

En fait, je pense pas qu'il faille modifier la configuration des services mais plutôt celle de nagios.cfg. La seule différence entre un CS et un DS est: est ce que le CS va faire les checks? La réponse étant "non", il faut désactiver les checks des services de manière globale. Donc on n'est pas obligé de modifier la configuration pour tous les services mais uniquement pour le paramètre execute_service_checks de nagios.cfg. Cela me parait plus simple à gérer. Qu'en pensez vous?

[krbian]

on peut etre pas obligé de modifier la conf pour les directives active/passive_check
mais pour les check_command si

si vous pouvez faire une maquette de deux serveurs je vous montrer les conf que j ai mis en place et le processus d intégration pour réfléchir sur quelque chose de plus concret

[julio]

En fait, je pense pas qu'il faille modifier la configuration des services mais plutôt celle de nagios.cfg. La seule différence entre un CS et un DS est: est ce que le CS va faire les checks? La réponse étant "non", il faut désactiver les checks des services de manière globale. Donc on n'est pas obligé de modifier la configuration pour tous les services mais uniquement pour le paramètre execute_service_checks de nagios.cfg. Cela me parait plus simple à gérer. Qu'en pensez vous?

oui oui pas con ca. Pourquoi faire compliqué quand on peut faire simple. bien ca. mais qui a la priorité ? nagioscfg ou la conf de l'host ? sur nagios2 aussi ?

[julio]

Quote:
premiere étape :
pouvez vous monter une architecture distribué avec deux serveurs?


Genre on est plein de sous et on a plein de serveurs chez nous ! heu c pas moi qui ai des serveurs Very Happy nan je crois que ca va etre dur... on va regarder.

je vais essayer avec des VM ce soir... mais faut le temps de l'installer...

[templuche]

mais qui a la priorité ? nagioscfg ou la conf de l'host ?
nagios.cfg

sur nagios2 aussi ?
Oui.

[krbian]

Genre on est plein de sous et on a plein de serveurs chez nous ! heu c pas moi qui ai des serveurs Very Happy nan je crois que ca va etre dur... on va regarder.

mouarf .. qui as rajouté ca à mon post??

[julio]

oula je corrige... au mieux de faire un edit de mon post c le tien que g edité
pardon je corrige :oops:

[krbian]

lol

[julio]

premiere étape :
pouvez vous monter une architecture distribué avec deux serveurs?

bon désolé... g pété ton message... j'ai repondu un peu trop vite... un peu trop de choses a faire en ce moment...

je ne me rapelle plus ce que tu avais ecrit... encore désolé...

nous on a pas vraiment de budget. Donc ca sera testé sur un serveur perso. donc on verra des que j'aurai eu le temps de mettre ca en place.

[julio]

mais qui a la priorité ? nagioscfg ou la conf de l'host ?
nagios.cfg

sur nagios2 aussi ?
Oui.

ok impec alors... a moins que krbian ai encore des options plus poussé sur les fonctionnalités des SA.

[krbian]

pas de soucis, je comprends.

est ce que pour commencer on peut simuler le serveur distribué et vérifier la genération des conf est correctes/faisables.?

[krbian]

ok impec alors... a moins que krbian ai encore des options plus poussé sur les fonctionnalités des SA.

je met un chti ola sur le fait de ne modifier seulement le nagios.cfg car :
on peut etre pas obligé de modifier la conf pour les directives active/passive_check
mais pour les check_command si

dans la def des services la checkcommand varie entre le DS et le CS

d un coté c'est un check_snmp (par ex) et de l autre un check_graph_passive

[julio]

je met un chti ola sur le fait de ne modifier seulement le nagios.cfg car :
Quote:
on peut etre pas obligé de modifier la conf pour les directives active/passive_check
mais pour les check_command si


dans la def des services la checkcommand varie entre le DS et le CS

d un coté c'est un check_snmp (par ex) et de l autre un check_graph_passive

ouais ok de toute facon c pas complexe. Quand on genere on change simplement 2 ou 3 valeurs et hop c parti. Ya rien de complexe.

[krbian]

oki, je ferais une archive de la conf des serveurs pour avoir un exemple, j enverrai ca demain

[krbian]

Bonjour,
voici l archive avec les conf des deux serveurs.

[gollum123]

hello,

le schema a été volontairement enlevé..soit, mais on le trouve où ?

j'arrive un peu après la guerre et je suis pommé sans le schéma...

@+

[julio]

ha oauis c balo ca....

[krbian]

je peux le remettre , mais pas le laisser.

dis moi quand tu es loggué et je le remet

[rom]

Pourquoi tu ne le laisses pas ? Le fait qu'il devienne obsolete ou pour des soucis de confidentialite ?

Si c'est ce deuxieme cas, c'est assez dommage dans la mesure ou les gens qui y ont acces sont interesses par cette evolution et sont des contributeurs actifs et de la premiere heure pour le projet Oreon. :D Leurs avis pourra nous etre utile.

En plus je l'ai sous les yeux et ne vois rien de bien confidentiel :roll:

[krbian]

pour une raison de divulgation de notre architecture de notre réseau de supervision qui possede un acces priviligié vis a vis des équipements.

Je n ai auncun probleme si vous l avez enregistré sur vos postes persos mais le laissez en ligne je n ai pas le droit

[skydevforum]

Bonjour,

J'aimerais bien voir le schéma d'architecture du futur centreon afin de m'y préparer à l'avance pour la migration du serveur de monitoring...

Comment fonctionne précisément entre les deux serveurs nagios, comment l'un ou l'autre sache qu'un tombe en panne, et basculera automatiquement.
Si une erreur persiste (par exemple TRAP SNMP), nagios serait obligé de nous avertir par e-mail, verais je 2 fois même e-mail?

Etc...

Serait-il compatible avec SAN, stockage en réseau en RAID 5?

Offrirez-vous une meilleure support d'administration pour le fichier de configuration snmptt.conf?

Merci beaucoup

Fred