Методы для Контроля задач крона?

В дополнение к вышеупомянутому:

• Действительно назовите "регистратор" наряду с записью в stderr, когда что-то пойдет не так, как надо. Настройте системный журнал для дополнительной передачи центральному хосту, иначе "loghost". (Регистратор будет использовать "user.notice" средство по умолчанию, но можно изменить его.)

Мой общий подход таким образом:

• Не производите stdout, когда Ваше cron'ed приложение завершится успешно.
• Не передавайте вывод по каналу к/dev/null.
• Действительно произведите значимый вывод stderr, когда что-то пойдет не так, как надо.
• Действительно установите адрес $MAILTO в crontab, чтобы отправить тот вывод ошибок необходимой команде.

Существует несколько методов, которые Вы могли использовать для контроля cronjobs.

Получить предупреждения cronjob отказов:

• Используйте стандартный MAILTO крона = функция. Если cronjob произведет вывод на STDERR, то он будет отправлен по почте к адресу, который Вы выбираете.
• Чтобы отследить и иметь дело с письмами крона, можно направить их в систему билета.

Система Вы предлагаете зарегистрировать информацию в "сетевое осведомленное" место, походит на системный журнал. системный журнал обеспечивает простой метод для создания журналов, это обычно управляет файлами, такими как/var/log/messages. Можно сделать основное удовлетворение требованиям заказчика, такое как выбор, какие файлы получают сообщения журнала.

Системный журнал может быть запущен в сетевом осведомленном режиме. Например, можно настроить его так, ведомое устройство может зарегистрироваться ведущему устройству:

[root@slave ~]#  echo "hello world from slave" | logger -p local1.info

[root@master ~]# tail /var/log/myapp
Jun 29 13:07:01 192.168.1.2 logger: hello world from slave

Для основанного на Red Hat распределения конфигурация в качестве примера следующие:

[root@slave ~]# cat /etc/syslog.conf | grep local1
local1.*                                                @192.168.1.3

[root@master ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"

[root@master ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp

(Первая строка конфигурации перенаправляет local1.* зарегистрируйте уведомления @192.168.1.3 ("ведущее устройство"). Флаг-r второй строки SYSLOGD_OPIONS включает сетевую поддержку. Наконец, третья строка конфигурации направляет local1.* сообщения, полученные на "ведущем устройстве" в файл).

Подход системного журнала лучше для того, чтобы только зарегистрировать ошибки/информацию. Файлы журнала имеют меньше видимости, чем электронная почта, таким образом, Вы, вероятно, не посмотрите на журналы, если что-то не пошло не так, как надо.

Если Вы принимаете решение пойти путем стиля системного журнала, также рассмотрите системный-журнал-ng: http://freshmeat.net/projects/syslog-ng/.

Конечно, можно получить лучший из обоих методов при помощи обоих. Например, syslog'ing и отказы и успехи, и просто отправляющий по почте для отказов.

Это похоже на классический вариант использования для AlertGrid.

Это не требует установки, все, что необходимо сделать для взятия преимуществ от этого инструмента, к:

1. отправьте Сигнал AlertGrid каждый раз, когда Ваше задание крона закончилось, это - работа (это может быть сделано экстремальным образом простым API, сигналом является просто Запрос HTTP). Можно также отправить некоторые параметры как execution_time!
2. установите правила уведомления как следующее:

если my_job не ответил за X минут (часы в Вашем случае)-> отправляют SMS администратору

или

если execution_time> 60 секунд-> посылают электронное письмо заинтересованным людям

На самом деле это - все. Можно управлять правилами уведомления с помощью хорошего визуального редактора. Вы не должны изменять исходный код или некоторые конфигурационные файлы, если бы что-то изменилось. Это - централизованное решение, таким образом, можно извлечь выгоду из управления правилами от единственного места.

Надежда это помогает кому-то. Существует бесплатная учетная запись, обеспеченная, таким образом, можно протестировать и использовать AlertGrid, если Вам интересно. Я - один из членов команды AlertGrid - не стесняются спрашивать, есть ли у Вас некоторые вопросы.

Ваши задания cron уже зарегистрированы через системный журнал. Эти данные могут быть отправлены на центральный сервер с помощью syslogd, другой стандартной службы.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ есть подробности о том, как это настроить.

i use http://cronrat.com just append && curl "...your cronrat url " to your cron jobs. The best feature i like is that you dont need to set up anything after you create initial account. Each alert is up and running the minute you use it. therefore i can use any automated tools to start my jobs that dont exists yet, unlike on some services where i need to set up job first.

На момент написания этой статьи он все еще находится в стадии интенсивной разработки, но я бы посоветовал взглянуть на https://github.com/jamesrwhite/minicron . Он был разработан для решения описанных вами проблем. После небольшого изменения команды, которую вы запускаете, он может записывать статус вывода и завершения заданий и отправлять эти данные обратно на центральный сервер в режиме реального времени, а также может отправлять предупреждения по электронной почте, SMS и PagerDuty при сбое задания (статус выхода> 0) или не выполняется, когда должен.

Отказ от ответственности: я разработчик, работающий над этим.

Я разместил аналогичный ответ на вопрос на StackOverflow(https://stackoverflow.com/questions/21025495/system-for-monitoring-cron-jobs-and-automated-tasks)

Кронитор (https://cronitor.io) был инструментом, который я создал именно для этой цели. В основном он сводится к тому, что он является маячком слежения, который использует http запросы в качестве пинга.

Однако, одна из потребностей, которую упоминает ОП в своем комментарии - это необходимость быть информированным, когда работа начинает занимать слишком много времени.

У меня была такая же потребность, и я обнаружил, что подобные инструменты не так легко поддерживают этот тип мониторинга. Cronitor решает эту проблему, позволяя вам по желанию запускать начальное и конечное событие, чтобы отслеживать длительность.

Отслеживание длительности было для меня обязательным, потому что у меня была работа по расписанию каждый час, но с течением времени на ее выполнение уходило более часа. Надеюсь, вы найдете это полезным!

Я создал Power Cron именно для этих нужд. Мне требовалось централизованное представление моих заданий cron и понятие зависимости между заданиями разных членов кластера.

Мне также требовалось больше информации, чем то, что я мог найти в журналах, и добавлено профилирование заданий.

Для этого мы создали PushMon, http://www.pushmon.com . Допустим, ваша ежедневная работа начинается в 3 часа ночи и обычно заканчивается в 4 часа ночи. Вы можете настроить расписание PushMon «до 4:00 каждый день». Или более сложный график, например «до 4:00 каждый день в течение 1 часа». Все, что вам нужно сделать, это «пинговать» URL-адрес PushMon каждый раз при запуске вашего задания, и он будет предупреждать вас о пропущенных пингах. Если вы точно знаете, что произошла ошибка, например, когда вы перехватываете исключение, которое не можете обработать, вы можете использовать функцию оповещения по запросу.

Healthchecks ( https://github.com/healthchecks/healthchecks/ ) - это сервис и панель инструментов, созданная специально для мониторинга заданий cron. Он используется в производстве, поддерживается и принимает код.

Он работает так же, как Cronitor, Dead Man's Snitch и его друзья: вы настраиваете задание cron на отправку HTTP / HTTPS-запроса на специальный уникальный URL-адрес непосредственно перед его завершением. Healthchecks получает и регистрирует эти эхо-запросы. Он постоянно проверяет, поступают ли эхо-запросы с ожидаемыми интервалами. Когда он обнаруживает проблему, он отправляет вам уведомление. Поддерживаемые методы уведомления: электронная почта, веб-перехватчики, Slack, Telegram, Discord, SMS, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Вы можете настроить и разместить все это самостоятельно, но, как и в случае с любой другой веб-службой, требуются некоторые усилия для настройки имени домена, сертификата, настройки обратного прокси-сервера HTTP, создания резервных копий базы данных и т. Д. Достаточно просто способ начать работу - использовать эту адаптированную для Heroku версию: https://github.com/iphoting/healthchecks . Я знаю людей, которые сами запускают этот проект и используют его для мониторинга сотен служб.

Отказ от ответственности: я являюсь автором, и я также запускаю Healthchecks в качестве размещенной службы на https://healthchecks.io