Heartbeat monitoring: как отслеживать cron-задачи и фоновые джобы

Heartbeat monitoring — это способ контролировать не доступность сайта, а регулярность работы фоновых задач: cron-джобов, бэкапов, очередных воркеров, периодических ETL-процессов. Иначе его называют dead man's switch: если сигнал перестал приходить, считается, что задача сломалась.

В отличие от обычных проверок «жив ли сервер», heartbeat-мониторинг ловит куда более коварные сбои — те, при которых процесс не падает, а просто молча перестает выполняться.

Зачем это нужно

Бэкапы, отчеты, ротация логов, уведомления, синхронизация данных — всё это часто живёт в cron или в шедулере очереди. Беда в том, что у таких задач нет «фронта», на который можно посмотреть глазами. Они либо идут, либо нет. И если они не идут, обычный мониторинг сайта об этом не узнает.

Типичные истории, которые ловит heartbeat:

бэкап молча перестал отрабатывать после смены пароля к S3, обнаружили только через две недели;
cron-задача пропала после обновления crontab, никто не заметил;
worker очереди продолжает запускаться, но ничего не обрабатывает, потому что подвис коннект к базе;
скрипт раз в час падает с ошибкой, но в логи никто не смотрит.

Как работает heartbeat monitoring

Идея простая. У задачи есть ожидаемое расписание, например, «раз в 5 минут». На стороне мониторинга заводится отдельный «слот» этой задачи. Каждый раз, когда задача отработала, она шлёт сигнал — пингует HTTP-эндпоинт.

Дальше мониторинг проверяет:

пришёл ли пинг в ожидаемом окне;
не пришёл ли он слишком рано (сигнал, что что-то перезапускает её внепланово);
не пришёл ли несколько раз подряд с ошибкой;
не растёт ли время выполнения.

Если ожидаемое окно прошло, а сигнала нет — открывается инцидент. Это и есть «dead man's switch»: молчание само по себе становится ошибкой.

Что считается heartbeat-сигналом

Самый простой вариант — HTTP-пинг в конце скрипта. Например:

#!/bin/bash
set -e
 
run_backup.sh
curl -fsS --retry 3 https://heartbeat.example/abc123/ > /dev/null

Здесь стоит обратить внимание на три детали:

set -e — если бэкап упал, до curl мы не дойдём, и мониторинг это заметит по молчанию;
--retry 3 — на случай кратковременных сетевых проблем;
пинг идёт после успешного выполнения, а не до.

Более продвинутые варианты:

Старт + конец. Можно пинговать отдельные URL для начала и для успешного завершения. Тогда мониторинг увидит и долго работающие задачи, и зависшие.
Сигнал об ошибке. Если задача упала, можно дернуть отдельный «fail»-эндпоинт с кодом ошибки. Это даст быстрый алерт без ожидания тайм-аута.
Лог-нагрузка. Иногда вместе с пингом отправляется короткий summary: сколько строк обработано, сколько ошибок, размер бэкапа.

Что мониторить в фоновых задачах

Помимо самого факта запуска, у фоновых задач есть свой набор полезных метрик:

успешность последнего запуска;
длительность последнего запуска и тренд;
задержка относительно расписания (drift);
количество ошибок за период;
размер обработанных данных, если это применимо;
лаг очереди для воркеров.

Особенно важна длительность. Часто задача начинает деградировать задолго до того, как окончательно сломается: бэкап, который раньше шёл 10 минут, теперь идёт 50, и однажды просто не уложится в окно.

Где обычно применяется heartbeat monitoring

Бэкапы. Самый классический случай. Молчаливо сломанный бэкап — это худшее, что можно обнаружить в момент, когда он понадобится.
Cron-задачи в Linux. Любые периодические скрипты: ротация, чистка, агрегации, отправка отчётов.
Queue worker'ы. Воркеры RabbitMQ, Kafka, Redis Streams, SQS, у которых вместо «сайт упал» бывает «сообщения копятся, никто не обрабатывает».
Периодические синхронизации. Импорт прайс-листов, обмен с внешними API, выгрузка в DWH.
Healthcheck микросервисов. Сервис может пинговать heartbeat сам каждые 30 секунд — если умер, мониторинг это видит независимо от его собственного состояния.
Scheduled jobs в Kubernetes (CronJob). Особенно полезно: CronJob может молча создавать упавшие поды, и без heartbeat это легко не заметить.

Как настроить расписание ожидания

Это самая частая ошибка. Поставили «раз в 5 минут», задача иногда выполняется 6 минут, и мониторинг всё время шумит false positives.

Полезный подход:

ожидание = период + допуск на дрифт;
для задач раз в 5 минут разумно ставить окно 7-10 минут;
для задач раз в час — окно 70-75 минут;
для дневных задач — несколько часов запаса, особенно если запуск ночью и зависит от внешних систем.

Лучше иметь чуть больший допуск и ловить реальные пропуски, чем будить команду каждый раз, когда задача зацепилась за блокировку в БД.

Heartbeat и обычный мониторинг — в чём разница

Параметр	Uptime / HTTP-проверка	Heartbeat
Кто инициирует	мониторинг → сервис	сервис → мониторинг
Что проверяется	доступность	факт выполнения
Тип сигнала	«есть ответ»	«пришёл пинг»
Пропуск сигнала	возможно из-за сетевых проблем	напрямую означает «не выполнилось»
Лучше всего ловит	сбои фронта и API	сбои фоновых процессов

Эти два подхода дополняют друг друга. Сайт может быть полностью доступен, а ночной бэкап при этом не делается уже неделю.

Типичные ошибки при настройке

Пинговать в начале, а не в конце. Если отправлять heartbeat до выполнения работы, мониторинг будет считать всё хорошо, даже если задача падает каждый раз.
Игнорировать exit code. Если скрипт состоит из нескольких шагов, важно убедиться, что пинг отправляется только при успехе всего пайплайна. Самый простой способ — set -e в начале shell-скрипта.
Слишком жёсткое окно. Жадные пороги дают лавину false positives. Длительность задач плавает, и это нормально.
Один heartbeat на пачку задач. Если 10 разных скриптов пингуют один URL, вы потеряете возможность понять, какой именно сломался.
Нет алерта на «сигнал пришёл, но это была ошибка». Полезно различать «не пришёл вовсе» и «пришёл, но fail» — реакция может быть разной.

Heartbeat в облачных и контейнерных средах

В Kubernetes удобный паттерн — обернуть задачу в скрипт, который шлёт heartbeat в postStart/preStop или прямо из CronJob. У большинства cloud-провайдеров есть свои планировщики, и для них heartbeat — единственный универсальный способ контроля «снаружи»: вы не зависите от внутренней телеметрии облака.

Полезное правило: heartbeat должен жить вне той же инфраструктуры, которую он мониторит. Если бэкапный сервер сгорел вместе с heartbeat-агентом, никто не узнает.

Что почитать дальше

Вывод

Heartbeat monitoring закрывает класс инцидентов, который обычные проверки сайта не видят в принципе: молчаливо сломанные бэкапы, пропавшие cron-задачи, зависшие воркеры. Логика проста — задача должна периодически кричать «я жива», и если крик прекратился, мониторинг бьёт тревогу.

Чтобы это работало надёжно, важны три вещи: пинговать после успеха, ставить адекватное окно ожидания и держать heartbeat-сервис вне самой контролируемой инфраструктуры. С этим минимумом фоновые процессы становятся такой же наблюдаемой частью системы, как и пользовательские сервисы.