Я понимаю, что когда любой cron выводит результат, он отправляет этот вывод по электронной почте ... я пытаюсь определить, что если у меня есть сценарий, запланированный на 3 часа ночи во вторник, и по какой-либо причине он либо выдает ошибку, либо не запускается, Я хотел бы знать...
Прямо сейчас я думаю о настройке таблицы базы данных, в которой хранятся временные метки последнего запуска для каждой команды cron, и мы получаем еженедельный отчет для команд cron. Или, возможно, сохранение в базе данных, когда он должен запускаться и когда он запускался последний раз, если есть проблема, он отправит нам электронное письмо.
«Электронная почта» будет осуществляться нашими внутренними системами, в которые наши сотрудники постоянно входят в систему, поэтому она не будет основана на самом cron.
Есть ли лучшее решение?
Я думаю, что мониторинг системного журнала был бы самым простым решением.
Отправьте системные журналы в вашу систему мониторинга, а затем настройте оповещения в своей системе мониторинга.
Раньше я также настраивал пользовательские базы данных SNMP MIB, в которые можно было поставить отметку времени последнего выполнения этого конкретного задания cron. Тогда некоторая внешняя система сможет отслеживать этот snmp MIB на предмет наличия отметки времени старше 24 часов.
Ваше решение работоспособно, но оно изобретает некоторые колеса, которые вам, вероятно, не нужны.
Во-первых, у вас действительно должна быть какая-то служба мониторинга. Я обычно использую нагиос, но их очень много. Выберите одну из этих систем и пусть она будет следить за вашим демоном cron.
Затем напишите плагин, который будет использовать обертки, упомянутые voretaq7. Вы получите предупреждение, если задание cron завершится неудачно, а также если crond также не сработает.
Причина, по которой я предлагаю это, заключается в том, что у вас будет весь ваш мониторинг в одном месте. В конечном итоге вам придется иметь систему мониторинга для всего сайта, и имеет больше смысла приложить усилия для этого, чем иметь разрозненную серию систем мониторинга.
Я создал простой инструмент для этого типа мониторинга - https://cronitor.io
Он позволяет вам устанавливать как интервалы (каждые 24 часа), так и продолжительность (более 10 минут, менее 2 минут и т. Д.), А затем получать уведомления по электронной почте / SMS, если ваше задание cron (или любая другая автоматическая задача) не выполняется. в соответствии с определенными вами правилами.
Инструмент бесплатен для отдельных мониторов, а платные планы доступны для тех, у кого несколько потребностей в мониторинге.
Ваше решение звучит нормально в зависимости от вашей среды, но это может быть немного излишним (если вам не нужно иметь возможность проверять историю этого задания в долгосрочной перспективе, и в этом случае бит базы данных может иметь смысл).
Другой вариант, который следует рассмотреть, - просто обернуть ваши задания cron в сценарий проверки (если задание cron завершается со статусом ошибки (! = 0), отправьте электронное письмо или сгенерируйте вывод и позвольте cron отправить электронное письмо за вас).
Ваше решение звучит немного сложнее, чем я думаю.
Начните с обзора и / или мониторинга /var/log/cron.log (или куда бы ни пошли ваши журналы cron). cron хорошо регистрирует каждую выполняемую команду вместе с ошибками. Если вы хотите знать, что произошло, вам сюда. Если вы беспокоитесь о том, что cron умирает, вы можете настроить биение cron, которое будет регистрироваться каждые 5 минут, и если вы не видите биение, отправьте какое-то предупреждение. Если вы действительно чувствуете, что вам нужен второй инструмент для наблюдения за cron, есть пакет perl (Schedule::Cron), с помощью которого вы можете регулярно проверять свое сердцебиение. Если вас беспокоит надежность локальной машины, вы также можете отправить журналы на вторую машину для мониторинга / обработки / предупреждения и т. Д.
В качестве альтернативы вы можете просто использовать какой-то инструмент системного мониторинга (SNMP, Nagios, Hobbit / BigSister и т. Д.) Для внешнего мониторинга того, что процесс cron запущен. Вы ведь следите за здоровьем своих систем?
Хотя, если ты действительно вы беспокоитесь о том, что cron умирает, возможно, вы захотите восстановить или заменить свою машину. cron должен быть довольно надежным, и если он дает сбой, это, вероятно, симптом более серьезной проблемы.
Я имел дело с аналогичным требованием:
Скрипт, запущенный cron, отправляет результат в logger команда. logger отправляет сообщение системного журнала в средство Local4, которое обрабатывается rsyslog. Затем local4. * Отправляется удаленному слушателю Syslog - в моем случае - экземпляру Splunk. В Splunk есть сохраненный поиск, который запускает оповещения по электронной почте, если события не происходят в ожидаемом временном окне. Помимо предупреждений, Splunk также дает мне удобную хронологическую шкалу событий с возможностью поиска.
Вы можете использовать PushMon и создать URL-адрес с расписанием «до 3:30 каждый вторник». Затем выполните эхо-запрос по URL-адресу PushMon, когда ваш сценарий будет успешно выполнен. Если URL-адрес PushMon не вызывается из-за того, что компьютер выключен, или cron не удалось запустить (это случается), или ваш скрипт не работает, PushMon предупредит вас к 3:30 утра. Вы можете получать уведомления по электронной почте, SMS, телефону, мгновенным сообщениям или в Twitter, и эта услуга бесплатна.
Отказ от ответственности: я связан с PushMon.
Пытаться healthchecks.io, это отличное бесплатное решение с открытым исходным кодом. Вы даже можете разместить его, если хотите.