qual è il vantaggio di usare supervisord su monit

Question

Abbiamo una configurazione personalizzata che ha diversi daemon (applicazioni web + attività in background) in esecuzione. Sto cercando di utilizzare un servizio che ci aiuti a monitorare quei daemon ea riavviarli se il loro consumo di risorse supera più di un livello.

Apprezzerò qualsiasi idea su quando uno è migliore dell'altro. Come ho capito, Monit gira un nuovo processo mentre supervisord avvia un sottoprocesso. Qual è il pro e il contro di questo approccio?

Utilizzerò anche upstart per monitorare monit o supervisord stesso. La distribuzione webapp verrà eseguita utilizzando capistrano.

Grazie

Answer 1

Se si desidera monitorare ulteriormente le risorse si dovrebbe accontentarsi di Monit. Oltre a verificare se un processo è in esecuzione (disponibilità), Monit può anche eseguire alcuni controlli sull'utilizzo delle risorse (prestazioni, utilizzo della capacità), livelli di carico e anche controlli di sicurezza di base (md5sum di un file bianry, file di configurazione, ecc.). Ha una configurazione basata su regole che è abbastanza facile da comprendere. Inoltre ci sono un sacco di pronto per l'uso configurazioni: http://mmonit.com/wiki/Monit/ConfigurationExamples

Monit richiede processi per creare file PID, che può essere un difetto, perché se un processo non crea il file pid è necessario creare qualche wrapper intorno. Vedi http://mmonit.com/wiki/Monit/FAQ#pidfile

Supervisore d'altra parte è più legato a un processo, lo genera da solo. Non può effettuare alcun controllo basato sulle risorse come monit. Però ha una bella CLI servicectl e una GUI web.

Answer 2

Non ho usato Monit ma ci sono alcuni difetti significativi con supervisord.

1. programmi dovrebbero correre in primo piano

Questo significa che non si può semplicemente eseguire /etc/init.d/apache2 iniziare. La maggior parte delle volte puoi semplicemente scrivere una fodera, ad es. "source/etc/apache2/envvars & & exec/usr/sbin/apache2 -DFOREGROUND" ma a volte è necessario il proprio script di wrapper. Il problema con gli script wrapper è che si finisce con due processi, un genitore e un figlio. Vedere la prossima falla ...

2. supervisord non gestisce bambino processi

Se il programma viene avviato processo figlio, supervisord solito rilevare questo. Se il processo genitore muore (o se viene riavviato usando supervisorctl) i processi figli continuano a funzionare ma saranno "adottati" dal processo init e resteranno in esecuzione. Ciò potrebbe impedire future chiamate del tuo programma in esecuzione o consumare risorse aggiuntive. Le recenti opzioni di configurazione stopasgroup e killasgroup dovrebbero risolvere questo problema, ma non ha funzionato per me.

3. supervisord non ha la gestione delle dipendenze - vedere #122

Recentemente ho calamari messa a punto con qlproxy. qlproxyd deve iniziare prima altrimenti il ​​calamaro può fallire. Anche se entrambi i programmi sono stati gestiti con supervisord, non c'era modo di garantirlo. Avevo bisogno di scrivere uno script di avvio per calamaro che lo facesse aspettare il processo qlproxyd.Aggiunta del script di avvio ha provocato il problema processo orfano descritto in difetto 2

4. supervisord non consente di controllare il ritardo tra startretries

volte, quando un processo non riesce per iniziare (o si blocca), è perché non può accedere a un'altra risorsa, probabilmente a causa di una oscillazione della rete. Supervisore può essere impostato per riavviare il processo un numero di volte. Tra riavvii il processo entrerà in uno stato "BACKOFF" ma non c'è documentazione o controllo sulla durata del backoff.

Nel suo supervisore difensore soddisfa le nostre esigenze l'80% delle volte. La configurazione è ragionevole e la documentazione piuttosto buona.