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 v2

Je 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?