Методи моніторингу задач на хрон?

Чи є хороші методики моніторингу завдань Cron над кластером?

Ми починаємо використовувати cron для запуску завдань через щоденні інтервали. Кілька ідей для перевірки інформації:

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

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

Окрім інших відповідей:

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

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

Мій загальний підхід такий:

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

На додаток до вищезазначеного:

• Зателефонуйте "реєстратору" разом із написанням на stderr, коли щось піде не так. Налаштуйте syslog, щоб додатково переслати на центральний хост, він же "loghost". (За замовчуванням Logger використовуватиме об'єкт "user.notice", але ви можете змінити його.)

Існує кілька методів, які ви можете використовувати для моніторингу кроні.

Щоб отримувати сповіщення про збої в роботі, виконайте вказані нижче дії.

• Використовуйте стандартну функцію MAILTO = cron. Якщо cronjob видає результат на STDERR, він буде надісланий поштою на обрану вами адресу.
• Для відстеження та обробки електронних листів ви можете направити їх у систему квитків.

Система, яку ви пропонуєте ввести інформацію в місце "свідоме мережі", звучить як syslog . syslog пропонує простий метод створення журналів, він зазвичай управляє файлами, такими як / var / log / messages. Ви можете зробити основні налаштування, такі як вибір файлів, які отримують повідомлення журналу.

Syslog можна запустити в режимі інформатизації мережі. Наприклад, ви можете налаштувати його, щоб підлеглий міг увійти до ведучого:

[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 ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

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

Однак однією з потреб, яку зазначає ОП у своєму коментарі, є потреба бути поінформованою, коли робота починає занадто довго працювати.

У мене була така ж потреба, і я виявив, що подібні інструменти не дуже легко підтримують цей тип моніторингу. Cronitor вирішує це, дозволяючи необов'язково запускати подію початку та кінця, щоб відстежувати тривалість.

Відстеження тривалості було для мене обов'язковим, тому що у мене була робота, яка була запланована щогодини, але з часом почала займати більше години для бігу. Сподіваюся, вам це стане в нагоді!

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

Відмова: Я розробник, який працює над цим.

Це виглядає як класичний випадок використання для AlertGrid .

Він не потребує встановлення. Все, що вам потрібно зробити, щоб скористатися цим інструментом, це:

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

якщо my_job не відповів за X хвилин (години у вашому випадку) -> надішліть SMS адміністратору

або

якщо Execution_time> 60 секунд -> надсилайте електронний лист зацікавленим особам

Насправді це все. Ви можете керувати правилами сповіщень за допомогою приємного візуального редактора. Вам не потрібно змінювати вихідний код або деякі файли конфігурації, якщо щось змінилося. Це централізоване рішення, тож ви можете скористатися керуванням правилами з одного місця.

Сподіваюся, що це комусь допоможе. Існує безкоштовний рахунок, щоб ви могли протестувати та використовувати AlertGrid, якщо вам це цікаво. Я один із членів команди AlertGrid - не соромтеся запитати, чи є у вас якісь питання.

Ваші завдання на Cron вже реєструються через syslog. Ці дані можна надіслати на центральний сервер за допомогою syslogd, іншої стандартної послуги.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ має детальну інформацію про те, як це налаштувати.

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

Я створив Power 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 отримує та записує ці пінг-файли. Він постійно перевіряє, чи надходять пінгви через очікувані інтервали. Коли він виявить проблему, він надсилає вам сповіщення. Підтримувані способи сповіщення - це електронна пошта, веб-каси, слабість, телеграма, розбрат, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Ви можете все це налаштувати і розмістити самостійно, але, як і будь-яка веб-служба, потрібні певні зусилля для налаштування доменного імені, сертифіката, налаштування зворотного проксі-сервера HTTP, налаштування резервного копіювання бази даних тощо. Досить простий спосіб отримати працює, щоб використовувати цю адаптовану до Heroku версію: https://github.com/iphoting/healthchecks . Мені відомі люди, які самі керують цим проектом і використовують його для моніторингу сотень служб.

Відмова: Я автор, і я також запускаю Healthchecks як розміщену службу на веб- сайті https://healthchecks.io