Fai aspettare più a lungo prima di pensare che qualcosa sia morto

Sto cercando di avviare un programma (Resque) ma ci vuole un po 'di tempo prima che un pidfile venga scritto. Quindi, penso che Monit pensi che il programma non sia stato avviato e avvia uno o due altri programmi prima che sia scritto il file pid del primo.

Come posso ritardare di nuovo il controllo di Monit, solo per questo processo? O dovrei risolverlo in un altro modo?

Come posso ritardare di nuovo il controllo di Monit, solo per questo processo?

Quello che stai cercando di ottenere potrebbe essere fatto tramite la funzione " SERVICE POLL TIME " di monit

La documentazione di Monit dice

I servizi sono controllati a intervalli regolari forniti dal

set daemon n

dichiarazione. I controlli vengono eseguiti nello stesso ordine in cui sono scritti nel file .monitrc, tranne se le dipendenze sono impostate tra i servizi, nel qual caso la gerarchia dei servizi può alternare l'ordine dei controlli.

Uno dei metodi per personalizzare il sondaggio di servizio è

1. intervallo personalizzato basato sulla lunghezza del ciclo di polling multiplo

OGNI [numero] CICLI

Esempio:

check process resque with pidfile /your/app/root/tmp/pid/resque.pid
   every 2 cycles

O dovrei risolverlo in un altro modo?

Ho anche tentato inizialmente di monitorare i lavori di resque con monit perché monit è un demone molto leggero ma alla fine si è risolto con DIO. Lo so, so che DIO ha più fame di risorse rispetto al monit, ma in caso di resque abbiamo trovato che fosse una buona partita.

È possibile controllare un servizio specifico su un intervallo diverso rispetto all'impostazione predefinita ...

Vedere TEMPO POLL ASSISTENZA nella documentazione di Monit.

Un esempio per il tuo programma Resque sarebbe quello di verificare un numero diverso di cicli:

check process resque with pidfile /var/run/resque.pid
   every 5 cycles

o dalla sezione degli esempi:

Some servers are slow starters, like for example Java based Application Servers. 
So if we want to keep the poll-cycle low (i.e. < 60 seconds) but allow some services to take its time to start, 
the every statement is handy:

 check process dynamo with pidfile /etc/dynamo.pid every 2 cycles
       start program = "/etc/init.d/dynamo start"
       stop program  = "/etc/init.d/dynamo stop"
       if failed port 8840 then alert

oppure puoi sfruttare i controlli in stile cron.

check process resque with pidfile /var/run/resque.pid
   every 10 * * * *

o se si verifica un avvio lento, è possibile estendere il timeout nel comando di avvio del servizio:

check process apache with pidfile /var/run/httpd.pid
       start program = "/etc/init.d/httpd start" with timeout 90 seconds

Puoi anche verificare se qualcosa non ha funzionato per X volte consecutive:

 if failed 
    port 80 
    for 10 cycles 
 then alert

O per X volte nei sondaggi Y:

 if failed 
    port 80
    for 3 times within 5 cycles 
 then alert

O entrambi:

 check filesystem rootfs with path /dev/hda1
  if space usage > 80% for 5 times within 15 cycles then alert
  if space usage > 90% for 5 cycles then exec '/try/to/free/the/space'

( da qui )

Un membro del mio team ha trovato una soluzione piuttosto intelligente che consente a monit di controllare frequentemente (ogni minuto) , ma una volta che ha tentato di riavviare il servizio (che impiega ~ 10 minuti) attenderà un periodo di tolleranza specificato prima di tentare di iniziare ancora.

Ciò impedisce di attendere troppo a lungo tra i controlli, che combinato con l'avvio lento ha un impatto molto più grande per i clienti. Funziona utilizzando uno script intermedio che funge da flag per indicare che il monit sta già intervenendo dall'ultimo errore.

check host bamboo with address bamboo.mysite.com
   if failed
           port 443 type tcpSSL protocol http
           and status = 200
           and request /about.action
            for 3 cycles
   then exec "/bin/bash -c 'ps -ef | grep -v "$$" | grep -v "grep" | grep restartBamboo.sh >/dev/null 2>&1; if [ $? -ne 0 ]; then /opt/monit/scripts/restartBamboo.sh; fi'"

Se bamboo (app Web ad avvio lento) è inattivo per 3 minuti di seguito, riavviare, MA solo se uno script di riavvio non è già in esecuzione.

Lo script chiamato ha un sonno specificato che attende PIÙ LUNGO rispetto all'ora di inizio più lenta per il servizio (nel nostro caso prevediamo di terminare tra ~ 10, quindi dormiamo per 15)

#!/bin/bash
echo "Retarting bambo by calling init.d"
/etc/init.d/bamboo stop
echo "Stopped completed, calling start"
/etc/init.d/bamboo start
echo "Done restarting bamboo, but it will run in background for sometime before available so, we are sleeping for 15 minutes"
sleep 900
echo "done sleeping"

La versione corrente di Monit (5.16) supporta un timeout per gli script di avvio con la sintassi:

 <START | STOP | RESTART> [PROGRAM] = "program"
    [[AS] UID <number | string>]
    [[AS] GID <number | string>]
    [[WITH] TIMEOUT <number> SECOND(S)]

I documenti dichiarano:

Nel caso di un controllo del processo, Monit attenderà fino a 30 secondi prima che l'azione di avvio / arresto termini prima di arrendersi e segnalare un errore. È possibile ignorare questo timeout utilizzando l'opzione TIMEOUT.

Qual è ciò che farà il valore di "timeout".