Cron моніторинг: дізнайтеся, коли завдання не виконалось

Як визначається запізнення

У heartbeat-монітора є два числа, обидва в секундах: як часто завдання має пінгувати і скільки запасу часу допустимо. Дедлайн — це час останнього пінга про завершення плюс період плюс запас. Щойно годинник проходить цей момент, відкривається інцидент із повідомленням на кшталт «Heartbeat пропущено, останній пінг 26 годин тому». До першого пінга відлік іде від моменту створення монітора, тож новий heartbeat, від якого завдання так і не озвалося, теж сповіщає.

Дедлайн зсувається разом із кожним пінгом, а не прив’язаний до годинника на стіні. Нічний бекап із періодом 86400 і запасом 3600 вважається запізнілим, якщо наступний пінг надійшов пізніше ніж через 25 годин після попереднього. З цього є практичний висновок: обирайте запас так, щоб він покривав найдовший звичайний запуск разом із розкидом старту. Якщо завдання стартує о 03:00, зазвичай завершується до 03:20, але іноді триває 80 хвилин, запас у годину замалий, а дві години — безпечно. Дедлайни перевіряються з інтервалом самого монітора, тому сповіщення може відставати від дедлайну на один інтервал.

Три адреси

Після збереження монітора ви отримуєте адресу для пінга виду https://YOUR-APP-HOST/hb/hb_TOKEN. Токен — єдиний секрет, тому не кладіть його в публічні репозиторії. Працюють і GET, і POST, а успішний виклик відповідає «ok».

• Сама адреса або /finish: завдання виконано. Дедлайн скидається, відкритий інцидент закривається, і надсилається сповіщення про відновлення.
• /fail: завдання зазнало невдачі. Інцидент відкривається одразу, не чекаючи дедлайну, а причиною стає повідомлення, яке ви надіслали.
• /start: завдання стартувало. Це зберігається в історії монітора, тож видно запуск, який почався й не завершився, але дедлайн не зсувається.
• Нотатки: ?msg=текст або ?exit=2 у GET-запиті чи тіло POST до 10 КБ, наприклад хвіст логу. Інцидент покаже їх.

Рецепти з curl

Робіть ці однорядкові команди короткими, решту зробить оболонка. Підставте свою адресу.

• Звичайний cron: 0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://YOUR-APP-HOST/hb/hb_TOKEN > /dev/null. Через && невдалий скрипт пінга не надсилає, і спрацьовує сповіщення про пропуск.
• Негайне сповіщення про збій: backup.sh && curl -fsS $URL || curl -fsS "$URL/fail?msg=backup+failed". Друга гілка одразу відкриває інцидент.
• Вивід у сповіщенні: out=$(backup.sh 2>&1); curl -fsS --data-binary "$out" $URL/finish. У гілці збою викликайте $URL/fail, щоб хвіст логу потрапив в інцидент.
• systemd: додайте ExecStartPost=/usr/bin/curl -fsS https://YOUR-APP-HOST/hb/hb_TOKEN до сервісу типу oneshot, щоб виклик виконувався лише після успішного завершення основної команди.
• Kubernetes CronJob або CI: поставте curl останнім кроком скрипта завдання, у GitHub Actions чи GitLab — завершальним кроком запланованого workflow.

Розклади, які форма не вміє описати

Heartbeat працює зі звичайним періодом, а не з виразом cron і не з часовим поясом. Тому завдання, що запускається лише у будні, потребує періоду, достатнього, щоб перекрити вихідні, наприклад 3 доби, а це означає, що збій у п’ятницю помітять лише в понеділок. Краще так: період в одну добу і два монітори, або нехай завдання пінгує щодня, включно з пінгом «робити нічого» у вихідні. Для щомісячних завдань підійде період 32 дні плюс добовий запас. Щоб порахувати справжній інтервал між запусками незвичного виразу, скористайтеся конструктором cron.

Що heartbeat помічає, а що ні

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

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

Ліміти й тарифи

Heartbeat-монітори починаються зі Starter, на Free їх немає. Кількість: 20 на Starter, 100 на Pro і 500 на Agency. Кожна адреса для пінга приймає до 30 викликів на хвилину, а з однієї IP-адреси на всі токени разом дозволено 60. Понад це ендпоінт відповідає 429, тож пінгувати частіше ніж раз на кілька секунд із завантаженого циклу немає сенсу. Для воркерів черг пінгуйте раз на хвилину з періодом 120 і запасом 60. Канали сповіщень такі самі, як для будь-якого монітора, а для нічного завдання, яке не може не виконатись, з тарифу Pro доступна ескалація, див. ескалацію сповіщень. Формати адрес наведено в документації heartbeat API.