Назад | Перейти на главную страницу

Методы мониторинга задач cron?

Есть ли хорошие методы для мониторинга задач cron в кластере?

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

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

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

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

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

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

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

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

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

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

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

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

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

Система, которую вы предлагаете для регистрации информации в "сетевом" месте, звучит как системный журнал. syslog предоставляет простой метод создания журналов, обычно он управляет такими файлами, как / 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/.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

или

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

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

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

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

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

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

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

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

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