Моніторинг cron-задач та фонових worker'ів через heartbeat

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

Проблема: фонові задачі без HTTP-endpoint

У типового backend є шляхи:

• Web-запити (HTTP/HTTPS на сервер) - моніторите uptime-check'ом.
• Cron-задачі (щоденний backup, місячне виставлення рахунків, щогодинна sync) - не мають HTTP-endpoint, зовнішній моніторинг їх не бачить.
• Workers (Celery, BullMQ, Sidekiq), що споживають queue - теж без HTTP.

Якщо cron впаде (змінили crontab і зробили друкарську помилку, на сервері немає диска, відсутня environment variable, upgrade залежності зламав import), вас ніхто не попередить - доки в понеділок вранці не помітите, що рахунки не надіслано за вихідні.

Heartbeat-патерн: cron пінгує моніторинг

Принцип зворотний нормальному моніторингу:

1. У службі моніторингу створюєте heartbeat-монітор з очікуваним інтервалом (наприклад, «кожні 60 хвилин»).
2. Отримуєте унікальний heartbeat URL: https://epulz.io/heartbeat/abc123xyz.
3. У своїй cron-задачі в кінці успішного запуску викликаєте цей URL (HTTP GET або POST).
4. Якщо ping не приходить в очікуваний час (+ grace-період), моніторинг попередить.

Практичний приклад: bash cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

Ключ - && - heartbeat надсилається лише якщо backup.sh завершується exit code 0. Якщо скрипт впаде, ping не прийде, і протягом години ви отримаєте alert.

Порада: Для більш ретельного покриття додайте й «start» heartbeat:

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

Моніторинг тоді розрізнить «почав і не закінчив» (скрипт завис) від «зовсім не запустився» (cron-задача не спрацювала).

Python: requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # ваша логіка
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # Heartbeat не надсилається - моніторинг попередить
    raise

Node.js: async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Grace-період: скільки часу дати перед alert

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

Практичні значення:

• Hourly cron: інтервал 60 хв + grace 10 хв
• Daily backup (в середньому 20 хв): інтервал 1440 хв + grace 60 хв
• Weekly report: інтервал 10080 хв + grace 360 хв (6 год)

Занадто тісний grace = false-positive alerts. Занадто вільний = затримане попередження, коли реально впаде.

Де heartbeat-патерн допомагає найбільше

• Нічні DB backups
• Синхронізація із зовнішніми API (CRM, accounting, payment)
• Розрахунки звітів
• Cleanup задачі (видалення старих session, логів, тимчасових файлів)
• Healthcheck цикл довгоживучих worker'ів
• Заплановані email'и, newsletter'и, виставлення рахунків

Висновок

Фонові задачі часто критичніші за сам web, але залишаються сліпою плямою моніторингу. Heartbeat-патерн вимагає 5 хвилин реалізації (додавання curl у кінець cron-рядка) і дає той самий спокій, що й uptime-моніторинг для frontend.

Почніть моніторити cron-задачі

ePulz.io підтримує heartbeat-checks з конфігурованим grace-періодом. 7 днів безкоштовно.

Запустити моніторинг →