Як моніторити cron-завдання: 5 патернів із heartbeat

Cron-завдання падають тихо. П'ять heartbeat-патернів - від dead man's switch до grace-вікон - щоб про збій дізналися ви першими.

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

Heartbeat (або "dead man's switch") перевертає логіку навпаки. Замість сповіщення, коли щось не так, ваше завдання пінгує моніторинговий endpoint, коли все в порядку. Якщо очікуваний пінг не приходить вчасно, монітор сповіщає. Немає пінгу, немає повідомлень, велика проблема.

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

Патерн 1: Класичний dead man's switch

Найпростіше можливе налаштування. Ваше завдання після завершення викликає URL. Якщо монітор в очікуваному вікні не отримає повідомлення, він сповіщає.

# Щоденна резервна копія о 02:30, пінг після завершення
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://vash-monitor/ping/abc123

&& має значення: curl запуститься лише тоді, якщо backup.sh завершиться з кодом 0 (успіх). Якщо резервна копія провалиться, жодного пінгу не надішлеться і монітор це зловить. Прапорці -fsS змушують curl при HTTP-помилках падати тихо, але справжні проблеми все одно покаже.

Слабке місце: підтверджує лише те, що скрипт виконався і завершився нулем. Якщо скрипт проковтне власні помилки і все одно завершиться нулем, ви отримаєте хибне "все в порядку".

Патерн 2: Пінг лише при справжньому успіху

Зробіть сигнал успіху явним замість покладання на ланцюжок exit-кодів у shell. У скриптах із кількома кроками це зрозуміліше.

#!/bin/bash
set -euo pipefail   # при будь-якій помилці падай гучно
run_the_backup
verify_the_backup    # справді перевір, що вивід існує і має сенс
curl -fsS https://vash-monitor/ping/abc123   # досягається лише якщо все вище пройшло

set -euo pipefail означає, що будь-яка невдала команда перерве скрипт ще до пінгу. Додавання реального верифікаційного кроку (файл резервної копії існує, він більший за нуль байтів) закриває діру "завершився нулем, але нічого не зробив" із Патерну 1.

Патерн 3: Обгортка exit-коду

Коли ви не можете змінити саме завдання (бінарник третьої сторони, скрипт постачальника), оберніть його. Обгортка сигналізує старт, запускає завдання і повідомляє exit-код.

#!/bin/bash
URL=https://vash-monitor/ping/abc123
curl -fsS "$URL/start"                  # сигнал "я запустився"
/opt/vendor/report-generator            # завдання, яким ви не керуєте
EXIT=$?
curl -fsS "$URL/$EXIT"                   # повідом exit-код

Сигналізування старту дозволяє монітору ще й вимірювати тривалість виконання і виявити завдання, яке запустилося, але ніколи не завершилося (зависло). Повідомлення exit-коду дозволяє йому відрізнити "пройшло в порядку" від "пройшло і провалилося".

Патерн 4: Умовний пінг (пінгуй лише коли робота мала сенс)

Деякі завдання виконуються за розкладом, але справжню роботу роблять лише іноді (обробник черги, який часто знаходить чергу порожньою). Ви не хочете сповіщення про "відсутній heartbeat", коли завдання легітимно нічого не зробило. Пінгуйте лише тоді, коли справжня робота сталася, і відповідно розширте розклад.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://vash-monitor/ping/abc123?count=$PROCESSED"
fi

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

Патерн 5: Jitter і grace-вікна

Реальні розклади дрейфують. Завдання, налаштоване на 02:00, може запуститися о 02:00:04 через навантаження, а тривалість виконання щоденного завдання коливається. Якщо монітор очікує пінг точно в інтервалі, нормальний jitter даремно вас сполошить.

Рішення - grace-період: скажіть монітору почекати після очікуваного часу ще певний запас, перш ніж сповіщати. Щоденна резервна копія, яка зазвичай триває 8 хвилин, може використати 20-хвилинне grace-вікно. Також вам потрібен певний jitter у самому плануванні, коли у вас багато завдань, щоб вони не навантажували той самий ресурс в одну й ту саму секунду:

# Додай невелику випадкову затримку (0-59с), щоб завдання о 02:00 розклалися
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://vash-monitor/ping/abc123

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

Швидкий огляд

Патерн	Найкращий для	Ловить
Dead man's switch	Прості завдання з однією командою	Завдання не виконалося / завершилося ненульом
Пінг при успіху	Багатокрокові скрипти	Тихе "завершився нулем, але нічого не зробив"
Обгортка exit-коду	Завдання, які не можна змінити	Зависання, реальні exit-коди, тривалість
Умовний пінг	Завдання з нерегулярною роботою	Збої без хибних "відсутніх" сповіщень
Jitter і grace	Будь-що зі змінним часом виконання	Усуває хибні тривоги від дрейфу

Як це втілити на практиці

Почніть Патерном 1 на найважливішому завданні ще сьогодні (резервна копія, виставлення рахунків, синхронізація даних). Додайте верифікацію (Патерн 2) і grace-вікно (Патерн 5), перш ніж почнете на нього покладатися. Детальніший посібник з налаштування heartbeat знайдете в нашому гайді моніторинг cron-завдань через heartbeat.

Якщо ваше завдання спілкується з послугою через конкретний порт, досяжність спершу перевірите безкоштовним перевірячем портів. А коли будете готові моніторити планові завдання разом із сайтами та API в одному місці, подивіться як працює моніторинг доступності ePulz.io - 7-денна пробна доба безкоштовна, без картки.