Мониторинг 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 дней бесплатно.

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