Техники для мониторинга задач cron?

Существуют ли хорошие методы для мониторинга задач cron в кластере?

Мы начинаем использовать cron для ежедневного запуска задач. Несколько идей для проверки информации:

1. Добавьте специальную обработку приложения, которая регистрирует информацию в каком-то «сетевом» месте, например, в БД
2. Создайте систему файлов журналов, которая периодически передает журнал cron в центральную точку для обработки / запроса (наряду с другими возможными файлами журналов)

Мне интересно, были ли у людей успехи в том, что они делали вещи отдельно для cron по сравнению с другими вещами, или же задачи были полностью интегрированы в другой подход. Я склоняюсь к # 2, но я хотел бы знать, что могут попробовать более опытные люди.

В дополнение к другим ответам:

• позвольте заданию записать временную метку в файл, когда он завершится вместе с возвращаемым значением из фактического задания
• распространять возвращаемое значение обратно на исходный вызывающий

Мы используем первое, чтобы упростить проверку Nagios ( Icinga ), например, если последняя записанная метка времени старше n часов (плюс любая логика, которая вам нужна) - мы знаем, что что-то пошло не так.

Мой общий подход таков:

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

В дополнение к вышесказанному:

• Вызывайте «logger» вместе с записью в stderr, когда что-то идет не так. Сконфигурируйте системный журнал для дополнительной пересылки на центральный хост, он же «логхост». (Logger будет использовать средство user.notice по умолчанию, но вы можете изменить его.)

Есть несколько методов, которые вы можете использовать для мониторинга cronjobs.

Чтобы получать уведомления о сбоях cronjob:

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

Система, которую вы предлагаете для регистрации информации в «сетевом» месте, звучит как системный журнал . Системный журнал предоставляет простой метод для создания журналов, он обычно управляет файлами, такими как / 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 ("master"). Вторая опция -r строки SYSLOGD_OPIONS включает поддержку сети. Наконец, третья строка конфигурации направляет сообщения local1. *, Полученные на "master". в файл).

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

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

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

Я опубликовал аналогичный ответ на вопрос в StackOverflow ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

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

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

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

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

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

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

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

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

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

если my_job не ответил в течение X минут (в вашем случае, часов) -> отправить SMS администратору

или

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

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

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

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

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

я использую http://cronrat.com просто добавляю && curl "... ваш cronrat url" к вашей работе cron. Лучшая функция, которая мне нравится, это то, что вам не нужно ничего настраивать после создания первоначального аккаунта. Каждое предупреждение активируется в ту минуту, когда вы его используете. поэтому я могу использовать любые автоматизированные инструменты для запуска моих работ, которых еще нет, в отличие от некоторых служб, где мне нужно сначала настроить работу.

Я создал 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 получает и регистрирует эти пинги. Он постоянно проверяет, поступают ли эхо-запросы с ожидаемыми интервалами. Когда он обнаруживает проблему, он отправляет вам уведомление. Поддерживаемые методы уведомления: электронная почта, веб-хуки, провал, Telegram, Discord, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

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

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