Jak monitorować opóźnione zadanie za pomocą monit

Jeśli to coś warte, zawsze możesz użyć /usr/bin/env z monit do konfiguracji środowiska. Jest to szczególnie ważne w bieżącej wersji delayed_job, 1.8.4, gdzie opcja environment (- e) jest przestarzała.

check process delayed_job with pidfile /var/app/shared/pids/delayed_job.pid
start program = "/usr/bin/env RAILS_ENV=production /var/app/current/script/delayed_job start"
stop  program = "/usr/bin/env RAILS_ENV=production /var/app/current/script/delayed_job stop"

W niektórych przypadkach może być również konieczne ustawienie ścieżki za pomocą env.

Okazało się, że łatwiej jest stworzyć skrypt init dla opóźnionego zadania. Jest on dostępny tutaj: http://gist.github.com/408929 lub poniżej:

#! /bin/sh
set_path="cd /home/rails/evatool_staging/current"

case "$1" in
  start)
        echo -n "Starting delayed_job: "
                su - rails -c "$set_path; RAILS_ENV=staging script/delayed_job start" >> /var/log/delayed_job.log 2>&1
        echo "done."
        ;;
  stop)
        echo -n "Stopping sphinx: "
                su - rails -c "$set_path; RAILS_ENV=staging script/delayed_job stop" >> /var/log/delayed_job.log 2>&1
        echo "done."
        ;;
      *)
            N=/etc/init.d/delayed_job_staging
            echo "Usage: $N {start|stop}" >&2
            exit 1
            ;;
    esac

    exit 0

Następnie upewnij się, że monit jest ustawiony na uruchomienie / ponowne uruchomienie aplikacji, więc w pliku monitrc:

check process delayed_job with pidfile "/path_to_my_rails_app/shared/pids/delayed_job.pid"
start program = "/etc/init.d/delayed_job start"
stop program = "/etc/init.d/delayed_job stop"

Znalazłem fajny sposób na rozpoczęcie delayed_job z cronem na boocie. Używam kiedykolwiek do kontrolowania crona.

# custom job type to control delayed_job
job_type :delayed_job, 'cd :path;RAILS_ENV=:environment script/delayed_job ":task"'

# delayed job start on boot
every :reboot do
  delayed_job "start"
end

Uwaga: uaktualniłem kiedykolwiek gem do wersji 0.5.0, aby móc używać job_type

Nie wiem z monitem, ale napisałem kilka wtyczek Munin do monitorowania wielkości kolejki i średniego czasu wykonywania zadania. Zmiany, które wprowadziłem do delayed_job w tej łatce, mogą również ułatwić Ci pisanie wtyczek Monit na wypadek, gdybyś trzymał się tego.

Dzięki za scenariusz.

Jeden, ponieważ monit z definicji ma'spartan path' z

/bin:/usr/bin:/sbin:/usr/sbin

... a dla mnie ruby został zainstalowany / połączony w /usr / local / bin, musiałem się całymi godzinami zastanawiać, dlaczego monit po cichu zawodził podczas próby ponownego uruchomienia delayed_job(nawet z-v dla trybu monit verbose).

W końcu musiałem to zrobić:

check process delayed_job with pidfile /var/www/app/shared/pids/delayed_job.pid
start program = "/usr/bin/env PATH=$PATH:/usr/local/bin /var/www/app/current/script/delayed_job -e production start"
stop program = "/usr/bin/env PATH=$PATH:/usr/local/bin /var/www/app/current/script/delayed_job -e production stop"

Jeśli monit działa jako root i chcesz uruchomić delayed_job jako my_user to zrób to:

/etc / init.d / delayed_job :

#!/bin/sh
#   chmod 755 /etc/init.d/delayed_job
#   chown root:root /etc/init.d/delayed_job

case "$1" in
  start|stop|restart)
    DJ_CMD=$1
    ;;
  *)
    echo "Usage: $0 {start|stop|restart}"
    exit
esac

su -c "cd /var/www/my_app/current && /usr/bin/env bin/delayed_job $DJ_CMD" - my_user

/var / www / my_app/shared/monit / delayed_job.monitrc :

check process delayed_job with pidfile /var/www/my_app/shared/tmp/pids/delayed_job.pid
start program = "/etc/init.d/delayed_job start"
stop  program = "/etc/init.d/delayed_job stop"
if 5 restarts within 5 cycles then timeout

/etc / monit / monitrc :

# add at bottom
include /var/www/my_app/shared/monit/*

Ponieważ nie chciałem uruchamiać jako root, skończyłem tworząc skrypt init bash, którego monit używał do uruchamiania i zatrzymywania (PROGNAME byłoby absolutną ścieżką do script/delayed_job):

start() {
    echo "Starting $PROGNAME"
    sudo -u $USER /usr/bin/env HOME=$HOME RAILS_ENV=$RAILS_ENV $PROGNAME start
}

stop() {
    echo "Stopping $PROGNAME"
    sudo -u $USER /usr/bin/env HOME=$HOME RAILS_ENV=$RAILS_ENV $PROGNAME stop
}

Musiałem połączyć rozwiązania na tej stronie z innym skryptem wykonanym przez toby ' ego, aby działało z monitem i zaczynało od odpowiedniego użytkownika.

check process delayed_job
  with pidfile /var/app/shared/pids/delayed_job.pid
  start program = "/bin/su -c '/usr/bin/env RAILS_ENV=production /var/app/current/script/delayed_job start' - rails"
  stop program = "/bin/su -c '/usr/bin/env RAILS_ENV=production /var/app/current/script/delayed_job stop' - rails"

Poświęciłem sporo czasu na ten temat. Miałem dość nie posiadania dobrego rozwiązania, więc napisałem wtyczkę delayed_job_tracer, która konkretnie dotyczy monitorowania delayed_job i jego zadań.

Oto artykuł, który o nim napisałem: http://modernagility.com/articles/5-monitoring-delayed_job-and-its-jobs

Ta wtyczka będzie monitorować proces opóźnionego zadania i wysłać e-mail w przypadku awarii delayed_job lub jeśli jedno z jego zadań nie powiedzie się.

Dla Rails 3, możesz potrzebować set HOME env, aby kompas działał poprawnie, a poniżej Config działa dla mnie:

check process delayed_job
  with pidfile /home/user/app/shared/pids/delayed_job.pid
  start program = "/bin/sh -c 'cd /home/user/app/current; HOME=/home/user RAILS_ENV=production script/delayed_job start'"
  stop program  = "/bin/sh -c 'cd /home/user/app/current; HOME=/home/user RAILS_ENV=production script/delayed_job stop'"

Natknąłem się na problem, w którym jeśli opóźnione zadanie umrze, gdy nadal ma zadanie zablokowane, to zadanie nie zostanie uwolnione. Napisałem skrypt owijający wokół opóźnionego zadania, który spojrzy na plik pid i uwolni wszystkie zadania od martwego pracownika.

Skrypt jest dla rubber/capistrano

Role / delayedjob/delayed_job_wrapper:

<% @path = '/etc/monit/monit.d/monit-delayedjob.conf' %>
<% workers = 4 %>
<% workers.times do |i| %>
<% PIDFILE = "/mnt/custora-#{RUBBER_ENV}/shared/pids/delayed_job.#{i}.pid" %>
<%= "check process delayed_job.#{i} with pidfile #{PIDFILE}"%>
group delayed_job-<%= RUBBER_ENV %>
<%= " start program = \"/bin/bash /mnt/#{rubber_env.app_name}-#{RUBBER_ENV}/current/script/delayed_job_wrapper #{i} start\"" %>
<%= " stop program = \"/bin/bash /mnt/#{rubber_env.app_name}-#{RUBBER_ENV}/current/script/delayed_job_wrapper #{i} stop\"" %>
<% end %>

Role / delayedjob / delayed_job_wrapper

#!/bin/bash
<%   @path = "/mnt/#{rubber_env.app_name}-#{RUBBER_ENV}/current/script/delayed_job_wrapper" %>

<%= "pid_file=/mnt/#{rubber_env.app_name}-#{RUBBER_ENV}/shared/pids/delayed_job.$1.pid" %>
if [ -e $pid_file ]; then
 pid=`cat $pid_file`
 if [ $2 == "start" ]; then
   ps -e | grep ^$pid
   if [ $? -eq 0 ]; then
     echo "already running $pid"
     exit
   fi
   rm $pid_file
 fi

locked_by="delayed_job.$1 host:`hostname` pid:$pid"

<%="   /usr/bin/mysql -e \"update delayed_jobs set locked_at = null, locked_by = null where locked_by='$locked_by'\" -u#{rubber_env.db_user} -h#{rubber_instances.for_role('db', 'primary' => true).first.full_name}  #{rubber_env.db_name} " %>

fi
<%= "cd /mnt/#{rubber_env.app_name}-#{RUBBER_ENV}/current" %>

. /etc/profile
<%= "RAILS_ENV=#{RUBBER_ENV} script/delayed_job -i $1 $2"%>

Aby zobaczyć, co się dzieje, Uruchom monit w trybie foreground: sudo monit -Iv

Używając rvm zainstalowanego pod użytkownikiem "www1" i grupy "www1".

W pliku /etc/monit/monitrc:

#delayed_job
check process delayed_job with pidfile /home/www1/your_app/current/tmp/pids/delayed_job.pid
    start program "/bin/bash -c 'PATH=$PATH:/home/www1/.rvm/bin;source /home/www1/.rvm/scripts/rvm;cd /home/www1/your_app/current;RAILS_ENV=production bundle exec script/delayed_job start'" as uid www1 and gid www1
    stop program "/bin/bash -c 'PATH=$PATH:/home/www1/.rvm/bin;source /home/www1/.rvm/scripts/rvm;cd /home/www1/your_app/current;RAILS_ENV=production bundle exec script/delayed_job stop'" as uid www1 and gid www1
    if totalmem is greater than 200 MB for 2 cycles then alert