Моніторинг cron-завдання однією командою curl

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

Виправлення настільки мале, що вміщується в один рядок вашого crontab. Цей посібник показує сам прийом, варіанти для платформ, якими ви, імовірно, користуєтеся, і помилки, через які монітор heartbeat бреше.

Ідея: нехай завдання відмічається

Звичайний монітор доступності питає ваш сайт: «Ти тут?». У запланованого завдання питати нема кого. Єдиний сигнал — те, що воно виконалося. Тож ви змінюєте напрямок: коли завдання завершується, воно запитує адресу. Якщо цей запит не надійшов вчасно, монітор сповіщає вас.

Крок 1: створіть монітор

Створіть монітор heartbeat. Ви отримаєте адресу виду https://ping.tenium.app/h/<id>. Ідентифікатор є секретом, тому ставтеся до адреси як до пароля й не кладіть її в публічні репозиторії. Монітори heartbeat доступні від тарифу Starter ($7 на місяць, 20 heartbeat-моніторів); у Pro їх 100, в Agency — 500.

Виберіть, як виражається розклад:

• Період (every 15 minutes) для обробників і споживачів черг.
• Вираз cron із часовим поясом (0 3 * * *, Europe/Tallinn) для завдань, що виконуються у фіксований час. Якщо ви не певні щодо виразу, конструктор cron-виразів прочитає його простою мовою й покаже п’ять найближчих запусків.

Потім задайте grace-період: найдовший звичайний запуск плюс запас.

Крок 2: додайте рядок у crontab

Найменша корисна версія:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://ping.tenium.app/h/abc123 > /dev/null

Три деталі в цьому рядку мають значення:

• && означає, що curl запускається, лише якщо скрипт завершився успішно. З ; ви повідомили б про успіх для завдання, яке впало.
• -m 10 --retry 3 не дає повільній мережі зависити запис cron і повторює невдалий ping.
• -fsS падає на помилках HTTP, мовчить за успіху й усе одно виводить помилки, які cron надсилає вам поштою.

Щоб повідомляти про збої одразу, а не чекати, поки закінчиться grace-період:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://ping.tenium.app/h/abc123 || curl -fsS -m 10 https://ping.tenium.app/h/abc123/fail

Крок 3 (краще): оберніть завдання один раз

Коли завдань десять, копіювати цей рядок незручно. Невелика обгортка тримає його в одному місці й надсилає код виходу та кінець виводу, які потім з’являються в інциденті:

#!/bin/sh
# usage: ping-wrap ID command args...
ID="$1"; shift
BASE="https://ping.tenium.app/h/$ID"
curl -fsS -m 10 "$BASE/start" > /dev/null
OUT=$("$@" 2>&1); CODE=$?
if [ "$CODE" -eq 0 ]; then
  curl -fsS -m 10 --retry 3 "$BASE" > /dev/null
else
  printf '%s' "$OUT" | tail -c 4000 | curl -fsS -m 10 --data-binary @- "$BASE/fail?exit=$CODE" > /dev/null
fi
exit "$CODE"

Користуйтеся так: 0 3 * * * /usr/local/bin/ping-wrap abc123 /usr/local/bin/backup.sh. Виклик /start вмикає облік тривалості: ви бачите, скільки триває завдання, а завдання, яке почалося, але не завершилося, виглядає як запізніле.

Вибір періоду та grace-періоду

Ці два числа визначають, як швидко ви дізнаєтеся про проблему і як часто вас будитимуть даремно. Виходьте з того, як завдання поводиться насправді, а не з того, як воно мало б поводитися.

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

Перевірте, перш ніж довіряти

Монітор, який ви ніколи не бачили в стані збою, — це здогад. Перевірте всі три результати один раз, у спокійну годину:

1. Запустіть рядок curl вручну й переконайтеся, що монітор показує свіжий час ping.
2. Запитайте адресу /fail вручну й переконайтеся, що інцидент відкривається, а сповіщення доходить до контакту, який ви справді читаєте.
3. Закоментуйте завдання в crontab, зачекайте, поки мине період плюс grace-період, і переконайтеся, що сповіщення «немає ping» надходить. Потім поверніть завдання на місце.

Запишіть назву монітора й власника завдання поруч із записом у crontab. Через рік ніхто не пам’ятатиме, який із двадцяти heartbeat-моніторів належить якому скрипту. Корисно також раз на квартал перевіряти список: монітори для завдань, яких більше не існує, мають бути видалені, інакше вони або сповіщатимуть даремно, або, що гірше, привчать команду ігнорувати сповіщення.

Варіанти для платформ

Таймер systemd. Додайте рядок у unit сервісу:

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
ExecStartPost=/usr/bin/curl -fsS -m 10 https://ping.tenium.app/h/abc123

З Type=oneshot рядок ExecStartPost виконується лише після успішного завершення ExecStart, тож завдання, яке впало, ping не надсилає.

Docker. Надсилайте ping з тієї самої команди оболонки, що й завдання, бо в контейнера, який завершився, немає «після»:

docker run --rm myimage sh -c 'run-job && wget -q -O- https://ping.tenium.app/h/abc123'

Kubernetes CronJob. Додайте ping останнім кроком команди контейнера або запустіть у поді другий контейнер, що чекає на перший. Тримайте ідентифікатор у Secret, а не в маніфесті.

Windows Task Scheduler. Як дію PowerShell: .\backup.ps1; if ($?) { Invoke-RestMethod https://ping.tenium.app/h/abc123 | Out-Null }.

WordPress. wp-cron запускається, лише коли хтось відвідує сайт. У дописі про п’ять перевірок WordPress є готовий плагін must-use, який надсилає ping під час кожного запланованого запуску.

Помилки, через які heartbeat бреше

1. Ping лише на початку. Ви дізнаєтеся, що завдання почалося, але не що воно завершилося. Надсилайте ping наприкінці, а /start використовуйте як додаток.
2. ; замість &&. Ping надсилається, навіть якщо скрипт упав.
3. Ping з іншого місця, ніж виконується завдання. Якщо завдання на сервері A, а ping cron надсилається з сервера B, монітор нічого не каже про A.
4. Grace-період коротший за найгірший запуск. Запуски наприкінці місяця найповільніші. Підбирайте запас під них.
5. Зсув часового поясу. Вираз cron у моніторі має використовувати той самий пояс, що й сервер, зокрема з переходом на літній час.
6. Запуски, що перекриваються. Завдання, яке триває довше за свій інтервал, запускається двічі. Поставте перед скриптом flock -n /tmp/backup.lock і дозвольте монітору повідомити, коли запуски пропущено.
7. Успіх, що нічого не означає. Скрипт резервного копіювання, який завершується з кодом 0 після запису порожнього файлу, — це зелене світло для зламаної копії. Нехай скрипт перевіряє розмір результату або запускає тест відновлення й надсилає ping, лише якщо він пройшов.

Що поставити поряд

Для кожного важливого завдання чек-лист короткий: heartbeat із розумним grace-періодом, контакт для сповіщень, який ви читаєте (e-mail на кожному тарифі, Telegram на платних), і примітка про те, хто відповідає за завдання. Варіанти дивіться на сторінці моніторингу cron-завдань, а порівняння Tenium з Cronitor допоможе, якщо моніторинг cron і черг — ваша головна вимога: Cronitor побудований саме навколо цього, і сторінка каже, де він сильніший.

Створіть безкоштовний акаунт, щоб спробувати решту перевірок; heartbeat-монітори доступні від Starter.

Поширені запитання

Читайте також

Пов’язані сторінки Tenium

• Моніторинг cron-завдань
• Конструктор cron-виразів
• Tenium проти Cronitor
• Усі матеріали блогу
• Тарифи