Какой подход к контролю кронов Вы используете?

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


Самый простой способ — делать вывод результата выполнения крона на консоль и получать это все на мыло. При этом ежедневно приходится вычитывать тонну писем, и это не гарантирует, что будет обнаружен крон, который отвалился и перестал запускаться.


Текущее видение решения — размещение кроном в бд результатов своей работы и вывод этих результатов в графики munin, zabbix, nagios кажется очень трудоемким.


А как это делаете вы?
  • Вопрос задан
  • 2448 просмотров
Пригласить эксперта
Ответы на вопрос 4
@bondbig
хм, как правило, добавляю в скрипт, запускаемый по крону, проверку успешности выполнения, if успешно — молчим, else — уведомление на мыло. Или у вас как раз неуспешных тонны?
Ответ написан
akalend
@akalend
программирую
реализовывал (в команде естенственно) крупную соц сеть, куча крон задач. Много скриптов должно постоянно крутиться (наверно их можно назвать демонами, хотя запускаются по крону).
Пришлось разрабатывать систему развертывания и управления задачами/скриптами (задачи крутились на разных серверах).
Основные принципы следующие:
Все крон задачи являются наследниками от базового класса.
Все крон задачи запускаются из единого скрипта (обертка) запуска.
Каждая крон задача имеет pid файл ( на тот случай чтоб не запустилось одновременно две одинаковых задачи )
Если нужно запустить одновременно два одинаковых скрипта, то на этот случай pid файл имел расширение
например crontask.1.pid crontask.2.pid
Каждый крон скрипт в централизованную БД ( в сой сети организован шардинг, все данные разбиты по шардам ) скидывал данные: время начала запуска, время окончания запуска, сколько сделано (некая мера, например кол-во обработанных элементов очереди)

было два скрипта анализа.
первый скрипт мониторил текущие данные в БД, сравнивал их с шаблоном (сколько должно быть) и выдавал в нагиус состояние 0 1 2
сисадмин по нагиусу если видел что что-то не так, то запускал таблицу мониторига скриптов и по ней наблюдали данные по скриптам, какой когда и как отработал

вот такой многослойный пирог
Ответ написан
Комментировать
Wott
@Wott
имхо скрипт должен молчать если все хорошо и информативно ругаться, если что-то не так. Соответвенно на мыло приходит информация если надо что-то че-нить.
Регулярная инфа скидывается в BD для статистики, графиков и прочего в админке.
Ответ написан
bagyr
@bagyr
В одно время писал на питоне костыль для отправки stdout через XMPP. Делалось по какому-то блогу (чуть ли не хабру), получилось ~ полсотни строк все про все.

Если сообщений слишком много, то можно немедленно отправлять только критические, остальные собирать в подобие дайджестов и отправлять раз в час или два.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы