Spraw, aby monitor czekał dłużej, zanim pomyśli, że coś jest martwe

Próbuję uruchomić program (Resque), ale napisanie pliku pid zajmuje trochę czasu. Dlatego myślę, że Monit uważa, że ​​program się nie uruchomił i uruchamia jeszcze jeden lub dwa programy przed zapisaniem pliku pid pierwszego.

Jak mogę opóźnić czas sprawdzania Monit tylko dla tego procesu? Czy powinienem rozwiązać to w inny sposób?

Jak mogę opóźnić czas sprawdzania Monit tylko dla tego procesu?

To, co próbujesz osiągnąć, można osiągnąć za pomocą funkcji monitorowania „ CZASU SERWISU ”

Dokumentacja Monit mówi

Usługi są sprawdzane w regularnych odstępach czasu podanych przez

set daemon n

komunikat. Kontrole są wykonywane w tej samej kolejności, w jakiej są zapisane w pliku .monitrc, z wyjątkiem sytuacji, w których konfigurowane są zależności między usługami, w którym to przypadku hierarchia usług może zmieniać kolejność kontroli.

Jedną z metod dostosowania ankiety serwisowej jest

1. niestandardowy interwał na podstawie wielokrotności długości cyklu odpytywania

KAŻDY [liczba] CYKLI

Przykład:

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

Czy powinienem rozwiązać to w inny sposób?

Zrobiłem też pierwszą próbę monitorowania zadań resque za pomocą monit, ponieważ monit jest bardzo lekkim demonem, ale ostatecznie został rozliczony z BOGIEM. Wiem, wiem, że BÓG jest bardziej głodny zasobów w porównaniu do monitorów, ale w przypadku resque okazało się, że jest to dobre dopasowanie.

Możesz sprawdzić określoną usługę w innym przedziale czasu niż domyślny ...

Zobacz CZAS ODPOWIEDZI SERWISU w dokumentacji Monit.

Przykładem twojego programu Resque byłoby sprawdzenie innej liczby cykli:

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

lub z sekcji przykładów:

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

lub możesz wykorzystać kontrole w stylu cron.

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

lub jeśli masz powolne uruchamianie, możesz wydłużyć limit czasu w poleceniu uruchomienia usługi:

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

Możesz także sprawdzić, czy coś nie działało X razy prosto:

 if failed 
    port 80 
    for 10 cycles 
 then alert

Lub X razy w ankietach Y:

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

Lub oba:

 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'

( stąd )

Członek mojego zespołu wymyślił dość sprytne rozwiązanie, które pozwala monitorowi sprawdzać często (co minutę) , ale gdy spróbuje ponownie uruchomić usługę (co zajmuje ~ 10 minut), poczeka określony okres karencji przed próbą uruchomienia jeszcze raz.

Zapobiega to zbyt długiemu czekaniu między czekami, co w połączeniu z wolnym startem ma znacznie większy wpływ na klientów. Działa przy użyciu skryptu pośredniego, który działa jak flaga, wskazując, że monitor podejmuje już działania od ostatniej awarii.

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'"

Jeśli bambus (wolno uruchamiająca się aplikacja internetowa) nie działa przez 3 minuty z rzędu, uruchom ponownie, ALE tylko wtedy, gdy skrypt restartu jeszcze nie działa.

Wywołany skrypt ma określony sen, który czeka DŁUŻEJ, a następnie najwolniejszy czas rozpoczęcia usługi (w naszym przypadku spodziewamy się, że skończy się za ~ 10, więc śpimy przez 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"

Obecna wersja Monit (5.16) obsługuje limit czasu dla skryptów startowych ze składnią:

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

W docs stwierdzić:

W przypadku kontroli procesu Monit będzie czekać do 30 sekund na zakończenie działania start / stop, zanim się podda, i zgłosi błąd. Możesz zmienić ten limit czasu, korzystając z opcji TIMEOUT.

To właśnie zrobi wartość limitu czasu.