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

Единое ведение журнала заданий Cron

У меня есть серия заданий cron на сервере. Я знаю, что могу перенаправить их вывод stdout / stderr в файл. Если я перенаправлю несколько выходных данных cronjob в один и тот же файл, будет ли это работать, даже если некоторые из заданий могут выполняться одновременно?

Еще более простой способ - направить весь вывод в инструмент logger и записать его в системный журнал, т.е.

* * * * * cronjob1.sh 2>&1 | logger -t cronjob1
* * * * * cronjob2.sh 2>&1 | logger -t cronjob2

затем посмотрите / var / log / messages

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

Нет, скорее всего, они друг друга перезапишут.

В качестве простого метода добавьте

MAILTO=you@yourdomain.com

в верхней части crontab, то cron отправит вам любой вывод по электронной почте.

Более сложный метод может включать настройку cronolog прослушивание FIFO, а затем отправка вывода этих сценариев в FIFO. Это потребует некоторой осторожности и обработки, если FIFO выйдет из строя, ваши задания cron заблокируют запись в него.

Честно говоря, я предпочитаю задания cron, которые ничего не выводят, если нет проблем, и в этом случае MAILTO Дай мне знать.

Прочитав множество таких сообщений, я обнаружил, что для cron нет единого журнала. Для большинства из нас графики рабочей нагрузки предприятия не подходят, и самый частый совет - использовать регистратор и / или отправлять выходные данные ваших скриптов по электронной почте или добавлять выходные данные в файл. Ни один из этих методов не может обеспечить полезное ведение журнала и оповещение. Итак, я написал сценарий Perl, которым я поделился на GitHub, который решает:

  • ведение журнала / оповещения по электронной почте: проблематично, потому что, если ваш скрипт шумный, он будет спамить вас, и вы перестанете обращать внимание на эти сообщения электронной почты

  • logger: записывает в системный журнал - как узнать, успешно или нет сценарий? свидетельствует ли отсутствие ошибок об успехе?

  • ведение журнала в файл - то же самое, что и регистратор, но означает, что вам нужно настроить собственную ротацию журнала

  • предупреждает о конкретном сбое (ненулевой код выхода, выход из-за перехвата сигнала, вывод на STDERR / STDOUT)

Проверить это. Это работает и бесплатно: https://github.com/ttubiak/utils/blob/master/bs

Он называется «BS» (няня), и вы можете использовать его / усыновить. Таким образом, это «родительский» сценарий, который запускает вашу программу как дочерний процесс. Вы говорите ему, что запускать, и он запустит это за вас с осмысленным протоколированием и созданием файла флагов, если ваш сценарий столкнется с проблемами. Он работает, присоединяясь к STDOUT и STDERR вашей программы и ожидая завершения работы вашей программы. Когда bs запускает вашу программу, он будет использовать syslog, чтобы сообщить об этом, когда ваша программа / сценарий записывает в STDOUT / ERR, он записывает это в syslog и, если вы так выберете, записывает в файл, который вы можете отслеживать. Если программа умирает, она, естественно, регистрирует эту информацию через системный журнал и создает файл флагов, за которым вы можете следить. Кроме того, он будет регистрировать строку статистической информации через системный журнал, чтобы вы знали, сколько времени требуется для запуска вашего кода. Есть более сложные вещи, которые он может сделать в сочетании с проверкой Nagios, которую я собираюсь опубликовать вовремя.