Salut, Moi utiliserai god, c'est assez simple a utiliser et ça relance les "processes", envoie des email le "works" quoi :) .
Pour verifier que God marche tu peu faire cron job qui relance god s'il n'est pas lancer toute les 15 minutes. Bruno On Jan 13, 2012, at 4:55 AM, Frederic de Villamil wrote: > Le 13 janv. 2012 à 10:46, Alexandre Friquet a écrit : > >> Salut, >> >> J'utilise pour une application Rails la gem delayed_job, sur un hébergement >> mutualisé. delayed_job possède déjà un système de monitoring de ses process >> : script/delayed_job start -m. Mais bien évidemment cela ne fonctionne que >> si le process père delayed_job_m n'est pas lui même tué... >> >> J'ai donc commencé à regarder une solution de monitoring de process et je >> suis bien évidemment tombé sur des pages et des pages concernant God >> (http://god.rubyforge.org/) et Bluepill (https://github.com/arya/bluepill). >> Mais d'après ce que j'ai pu voir, ces solutions sont assez complexes à >> mettre en place, surtout sur un hébergement mutualisé où par définition on >> ne peut pas faire ce que l'on veut. De plus, je me pose la question du >> monitoring de God et/ou Buepill : l'oeuf ou la poule ? >> >> Je suis donc preneur de toute information sur le sujet : quelle solution >> préconisez-vous ? L'utilisez-vous sur un hébergement mutualisé ? >> >> Merci. > > Bonjour, > > Amusant, j'ai eu exactement la même problématique la semaine dernière, et > j'ai testé 3-4 trucs, je dois publier un truc sur le sujet. > > J'était parti sur supervisord, un truc Python assez simple à mettre en place, > qui dit papa, maman et fait le café. J'ai finalement laissé tomber pour 4 > raisons : > – Ça dit papa, maman et ça fait le café. Et en plus ça relance les process > qui tombent. > – J'ai une stack python pour ainsi dire inexistante sur mon infra, ça me > faisait chier de commencer à en mettre une d'autant qu'il n'y a pas de > packages Debian, et que j'aime bien l'idée de ne pas avoir à me trainer un > système de packages de plus (les .egg). Déjà que je dois refaire les gems > sous forme de packages Debian… > – Y'avait un memory leak, pas gros, mais suffisamment pour qu'un truc qui > doit juste superviser 5 process me bouffe 20 megs en RAM. C'est trop. > – À bien y réfléchir, j'utilisais déjà supervise (DNSTools) pour superviser > mes DNS. > > Du coup, je suis parti sur supervise, pour plusieurs raisons : > – C'est du C, le code n'a pas du changer depuis 1999, et juste ça marche ©®™. > – Ça ne bouffe rien, ça ne prend pas de place. > – J'utilisais déjà ailleurs. > – C'est déjà packagé. > – Et SURTOUT: ça supervise un processus, le relance quand il tombe et ça ne > fait _que_ ça. > > Reste juste à voir quelle latitude tu as sur ton hébergement mutu, mais si > poser un binaire en C et créer 2-3 répertoires ne pose pas de problèmes… > > Fred > > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
