Oreon - Thread + Adobe Flex = ???

[umoorjani]

Salut,

Personnellement, je voudrais félicité les développeurs de ce projet, bravo ! C'est un outil de supervision carrément génial.

J'aimerai porté ma contribution d'idée conernant l'évolution future du projet si je peux me permettre.

Nagios a fait ses preuves au niveau de ses fonctionnalités de supervision dans l'open source, adopté par des sociétés tels que france télécom et centralisé sur des hyperviseurs de type micro muse il mérite sa place dominante sur le marché de la supervision open source. J'ai beaucoup réfléchi à l'évolution de ses deux outils et j'ai vu qu'il manquait une petite touche pour amené l'avenir de ses deux outils vers un nouveau cap.

Ce que je reproche a Nagios, la gestion de l'execution des plugins, si ne me trompe pas, nagios n'excute pas encores les plugins dans des threads pour accélerer le retoure ces derniers. J'ai trouvé un petit "workaround" a cela si je peux me permettre:

Oregano project, un serveur XMLSocket qui permet de faire du "data push", la gestion des utilisateurs, la synchro et plein d'autre fonctionnalités. Avec son API en Java, il est possible d'un coté de lancer des groupes de threads d'execution de scripts check et de retourné l'output de ces derniers, dans un base de données ou en temps réel vers un socketxml qui lui fera un push data vers l'array de clients connecté.

D'un coté, on utilise la conf d'execution de l'ensemble des scritps check défini dans les fichiers conf de nagios (interval, type de check, nom du check etc...), mais au lieu d'executer un script dans le fifo nagios un par un dans la queue du fifo, on envoi une requette XMLsocket vers le serveurs oregano qui lui éffectue la transaction vers le controlleur d'execution de scripts (toutes l'execution se fait dans des threads). Le serveur oregano sers de middleware de communication entre nagios, le controlleur d'execution de script et le client final. On peut aussi stocket les retours dans une base de données ou stocké dans le fichiers status.log de nagios sans que oreon l'utilise forcement.

Enfin je ne sais pas encore comment reprendre nagios pour cela, mais j'espère just que j'ai bien pu communiquer l'idée.

Bon passons coté client, ce qui concerne oreon, Adobe flex propose des compilateurs flex gratuitement pour le déploiement de petites applications. XMLSocket est un standard dans la version gratuite (étant inclus ActionScript 3.0), et permet de crée un connexion persistante avec oregano serveur qui lui pourra communiqué en temps réel avec le client.

Pour les questions de transaction les communications entre oregano et oreon peuvent être sérialisé pour préservé l'intégrité des remontés. L'application client peut être sur le post client directement avec adobe central ou en ASP comme l'architecture aujourd'hui. Enfin pour les graphes coté client il est possible d'interface flex avec html ou ajax dans leurs version d'adobe du <iframe> de microsoft. Les applications flex peuvent communiquer avec ajax et vice versa.

Enfin, voilà ma petite contribution pour les suggestions.

Si l'idée n'est pas bonne dite le moi aussi, ça m'aidera beaucoup a comprendre.

Cordialement,

umoorjani

[julio]

Ha voila un sujet interressant...

Nagios gere deja ca... enfin il fork... il peut faire plusieurs checks à la fois... Mais la je pense qu'on remet tout en cause nan ? ca changerai koi en bref ?

[Apo]

Re: Oreon - Thread + Adobe Flex = ???

Salut,

Personnellement, je voudrais félicité les développeurs de ce projet, bravo ! C'est un outil de supervision carrément génial.
...
Cordialement,

umoorjani

Merci

[umoorjani]

Ha voila un sujet interressant...

Nagios gere deja ca... enfin il fork... il peut faire plusieurs checks à la fois... Mais la je pense qu'on remet tout en cause nan ? ca changerai koi en bref ?

Je pense que lorsqu'on thread et lorsqu'on fork c'est jeu chose différentes.

Lorsqu'on fork nous executons plusieurs processes a la fois, donc nous reproduisons plusieurs instances des "global variables", du codes et le stack, ce qui consume beaucoup de temps et de ressource mémoire, or les threades, souvent appelé en anglais "lightweight process" duplique uniquement le stack d'execution tout en utilisant la meme instance de variables et de codes du process principal(tres souvent compilé en binaires, Langage C etc..). En gros pour un check_ping executé, 50 host peuvent être checké.

Il s'agit ici de limité l'utilisation des ressources et de boucler les instances d'executions dans des stacks d'execution et non dans tout un tas process.

Prenons mon cas, je suis dans une société avec plus d'une centaine d'équipement qui check des services souvent tres critique. Nous avons même développé des plugins maison. Nous avons 5 sites avec plus 60 équipement par site et plus 250 clients a supervisé. Qu'allons nous faire lorsque nous allons grossir ? L'avantage avec Micro Muse, tous est éxecuter dans des threads (Java) et les remontés sont en temps réel. Nous avons des processeurs que nous utilisions même pas la moitié de la capacité.

Forké des process c'est du gaspiage de ressource cpu, mémoire et cache. Nos cpu font du Hyper threading, et maintenant sont capable d'encaisser de la charge, sauf que nous ne savons pas comment l'optimisé.

Pourquoi nagios n'as pas des remonté en 30 minutes pile lorsqu'il est configurer pour checké un service tout les 30 mins? Dans le cas d'un thread il es possible d'exuter un seul check_host_alive et de crée de multiple threads pour checké tous les hosts en meme temps.

Avec les meme ressources cpu et mémoire (Dual Xeon 3.2 Ghz avec 7Go de mémoire) j'arrive pas a avoir des remonté plus rapide, pourtant j'ai des ressources non ?

Voici un lien qui explique bien la différence entre les threads et le fork :

http://www.cs.rpi.edu/~hollingd/netp...ds/threads.pdf

J'espère que ça peux vous aider.

umoorjani

[julio]

a ma connaissance, la différence est que le fork duplique la memoire du processus alors que le thread partage la memoire du processus pere... apres je ne sais pas si c'est vraiment ca qui fait ramer nagios sur des grosse conf...

Apres c'est le choix d'ethan de faire ca....

je vais etudier ton doc... et voir si je peux pas lui faire part de tes idées.

Es tu sur que java soit plus rapide que le moteur C de nagios... Si c'est vrai c'est alors que c'est mal codé le C....

Combien de services as tu ? MicroMuse te permet aussi de faire de redistribué ? quelle est ta frequence de check ? y a plein de choses en parametres...

[umoorjani]

a ma connaissance, la différence est que le fork duplique la memoire du processus alors que le thread partage la memoire du processus pere... apres je ne sais pas si c'est vraiment ca qui fait ramer nagios sur des grosse conf...

Apres c'est le choix d'ethan de faire ca....

je vais etudier ton doc... et voir si je peux pas lui faire part de tes idées.

Es tu sur que java soit plus rapide que le moteur C de nagios... Si c'est vrai c'est alors que c'est mal codé le C....

Combien de services as tu ? MicroMuse te permet aussi de faire de redistribué ? quelle est ta frequence de check ? y a plein de choses en parametres...

Non au contraire, je ne pense pas que c'est mal codé, je pense qu'il manque de l'optimisation. Prenons l'exemple de "cactid", il incremente les threads selon un nombre de threads max dans la conf ce qui permet la collecte des variables oids beaucoup plus rapide que le graphage avec le moteur de check oreon. Nous avons plus de 800 services graphé avec cacti, en utilisant le daemon cactid et nous arrivons a avoir un retour en 60sec max.

Sur chaque site nous avons en moyenne 200 services et nous avons 5 sites, les services sont graphé et non-graphé tous confondu. Je prend plus de 15 mins avec le moteur de nagios ce que je peux faire avec cactid en 1mins et encore c'est parceque j'ai limité les threads a un trentaine mais mes ressources cpu peuvent supporté bien d'avantage. C'est un question d'architecture et d'optimisation, je reproche a nagios de ne pas évolué en performance a ce niveau. Petite parenthese, cacti propose un plugin qui s'appelle "threshold" et permet de determine les seuils d'alerte par service graphé selon leurs type retour respectif. Ma fréquence de check est a interval de 30mins.

Un exemple: Je pense qu'en intégrant des fonctions généric prédéfinie, (exemple le check_snmp) dans le code et dupliquer les instances d'execution de cette petite portion du code, nous gagnerons beaucoup performance au lieu d'executer carrement plusieurs instances d'un script check_snmp. En gros nous compilons nagios avec les fonctions prédéfinie de type check directement dans le moteur nagios et non dans dans des scripts séparé du moteur.

Par contre si nous voulons garder la séparation check et moteur, ce que je pense est plus sage, nous créeons un moteur de check qui lance les threads en temps réel en boucle infinie et qui ne s'occupe pas des seuils d'alerte ni aucune conf nagios, qui s'occupe seulement de checké les services et les hosts en boucle infinie et que le moteur nagios lui, lorsque son heure est venu pour checké, il fait appel au moteur de check pour un service ou un host correspondant, et fait juste un retour de variable (mis a jour en boucle inifini dans le moteur).

J'espère que je me suis fait comprendre, je suis anglophone par naissance donc ça peux arrivé que je n'arrive pas a bien communiquer mes idées.

umoorjani

[julio]

en fait je pense que tu confond 2 choses...

- nagios le fait expres de ne pas tout faire en meme temps... il reparti la charge armonieusement... et c'est bien je trouve, je ne suis pas pour le fonctionnement de cacti.. tout faire en 1 s. ca provoque des piques de check qui font monter le cpu des hosts checkés... C'est pas top... et nagios fait expres de mettre des temps d'interval en tre chaque thread... si tu regarde bien y a des moment il ne fait rien. Il est la pour ne pas troubler le fonctionnement ni perturber les valeurs remontées.

Combien de services as tu ????

[umoorjani]

J'ai plus de 800 services par site check et graph confondu.

[julio]

et le load de la machine ? Quel type de machine ? quelle frequence de check ?

[umoorjani]

en fait je pense que tu confond 2 choses...

- nagios le fait expres de ne pas tout faire en meme temps... il reparti la charge armonieusement... et c'est bien je trouve, je ne suis pas pour le fonctionnement de cacti.. tout faire en 1 s. ca provoque des piques de check qui font monter le cpu des hosts checkés... C'est pas top... et nagios fait expres de mettre des temps d'interval en tre chaque thread... si tu regarde bien y a des moment il ne fait rien. Il est la pour ne pas troubler le fonctionnement ni perturber les valeurs remontées.

Combien de services as tu ????

D'accord, mais la performance c'est une limitation pour nagios, c'est pkoi d'ailleurs nagios ne pourra pas concurrencer des solutions de types micro muse orienté telecom et gros réseau.

Micro Muse, dispose des modules de check, dns ftp http ping jitter snmp etc... ce sont tous des modules, qui seront ensuite threadé dans un container de check, ce qui fait que micro muse est plus performant que nagios avec les ressources cpu, meme avec un Xeon 3.2Ghz avec 7Go de mémoire c'est pas plus rapide, c'est dommage.

Mais c'était juste une idée pas plus. Sinon bravo pr oreon.

umoorjani

[umoorjani]

et le load de la machine ? Quel type de machine ? quelle frequence de check ?

IBM x336 Dual Xeon 3.2Ghz 7Go de RAM 2 DD SCSI 146Go
Frequence de check : Tout les 30 mins

Serveur dédié pour la supervision.

[julio]

et ton serveur rame vraiment ??? je demande a voir quand meme... C'est vraiment etrange.... y a la fenetre de reschedule aussi a verifier...

[julio]

je ne vois pas ce que ca va change Muse.... il a quand meme la verification a faire... c du temps cpu... c pas la memoire qui change qq chose a mon avis... le 7 Go doivent etre utilisé a 20% max nan ? sans compté apache ?

il vaudrait mieux avoir une double coeur pour permettre au cpu d'etre moins fort en load et c tout... mais nagios gere aussi bien le dns, ftp, etc etc...

[umoorjani]

je sais que nagios gère tous ça, mais il arrive a limitation quand il doit gérer une quantité hosts et service a la fois. Il n'est performant pour de la supervision en temps réel.

Exemple de besoins en temps réel, les services voix dans le milieu télécom, il faut que le service check en temps réel la qualité de chaque terminaison.

Les services Video pour la transmission de flux en Haute définition, il y a besoin de supervision en temps réel.

Autre besoins de supervision en temps réel, la transmission fibre et radio (wimax blr etc..), le besoins de graphes et de détection d'interference en temps réel est critique pour assurer les SLAs proposé. C'est pour ça beaucoup de service providers, ne peuvent compté sur les solutions opensource de supervision car ils ont besoins de plus de maitrise.

C'est pour ça le remoting temps réel avec XMLSocket est important pour les graphes, le reporting, et les alertes en temps réel. Prenons le Ping: a chaque changement du retour en miliseconds, on éffectue un PUSH DATA vers l'application flex qui l'affiche sur le tableau de bord dès qu'il le reçoit.

Le temps réel, c'est l'évolution de nagios, si nagios arrive a faire du temps réel, il arrivera a respecter ses delaie de check de 30min.

Lorsque je balance un check pour un service ou un host X, en regardant le temps de du dernier check, il differe ENORMEMENT. Si je demande une interval de 30 mins c'est parce qu'il arrive des fois a avoir un retour du check 10 à 15min plutard parcequ'il prend tu temps pour traiter la queue, non par manque de performance mais par manque d'optimisation. Croit moi 10 à 15 mins c'est beacoup qd tu propose des SLAs de 99,999% par mois et que tu es aveugle dans l'espace de 10 à 15 mins sur le host.

Si nagios fork, il devrait forké exponentiellement et dynmiquement par rapport au nombre de host et de service a checké et par rapport au interval donné pour pouvoir être dans les temps pour les remonté.

Je le re-dit, si nagios arrive a faire du temps réel, il sera le maitre de la supervision opensource croit moi.

umoorjani

[romain]

[mode=blague]
moi j'aime bien muse, ils font un plugin qui s'appelle baby plugin baby ...
[/blague]