Мониторинг крон-заданий: Dead Man's Switch

Проблема невидимых сбоев

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

мониторинг сайтов крон-задач — это не проверка «работает ли сервер», а проверка «выполнилась ли задача в ожидаемое время».

Dead Man's Switch — принцип работы

Dead Man's Switch (DMS) — паттерн мониторинга, инвертирующий обычную логику. Вместо проверки «сервис доступен?» он проверяет «сервис не перестал сообщать о себе?»

Как работает

1. Вы создаёте мониторинг с ожидаемым интервалом (например, «крон должен отчитаться каждый час»)
2. После успешного выполнения крон-задача отправляет HTTP-запрос (Ping/heartbeat) на URL мониторинга
3. Если heartbeat не получен в ожидаемое время + grace period — срабатывает алерт

Реализация

# Crontab: задача каждый час с heartbeat
0 * * * * /path/to/job.sh && curl -fsS https://monitor.example.com/ping/abc123 > /dev/null

Ключевой момент: && означает, что heartbeat отправляется только при успешном завершении задачи (exit code 0). Если задача упала — heartbeat не отправлен — алерт.

Что мониторить в крон-задачах

Выполнение по расписанию

Задача должна запускаться в ожидаемое время. DMS обнаруживает пропущенные запуски — если cron daemon остановился, сервер перезагрузился или crontab был повреждён.

Успешное завершение

Задача может запуститься, но завершиться с ошибкой. Проверяйте exit code и отправляйте heartbeat только при успехе.

Время выполнения

Если задача обычно выполняется за 5 минут, а внезапно заняла 2 часа — это признак проблемы (растущая БД, deadlock, утечка памяти).

START=$(date +%s)
/path/to/job.sh
END=$(date +%s)
DURATION=$((END - START))

if [ $? -eq 0 ]; then
    curl -fsS "https://monitor.example.com/ping/abc123?duration=$DURATION"
fi

Зависание

Задача может зависнуть (deadlock, бесконечный цикл). Используйте timeout:

timeout 3600 /path/to/job.sh

Если задача не завершится за час, timeout убьёт процесс и вернёт ненулевой exit code.

Перекрытие запусков

Если предыдущий запуск не завершился до следующего, возникает перекрытие. Используйте lock-файлы:

#!/bin/bash
LOCKFILE="/tmp/job.lock"
if [ -f "$LOCKFILE" ]; then
    echo "Job already running, exiting"
    exit 1
fi
trap "rm -f $LOCKFILE" EXIT
touch "$LOCKFILE"

# Основная логика задачи
/path/to/actual-job.sh

Best Practices

Логирование

Каждая крон-задача должна писать логи: время начала, время завершения, количество обработанных записей, ошибки. Без логов диагностика невозможна.

# Crontab с логированием
0 * * * * /path/to/job.sh >> /var/log/jobs/hourly-job.log 2>&1

Grace period

Не алертите сразу при пропуске heartbeat. Добавьте grace period — запас времени, учитывающий нормальную вариацию длительности выполнения. Для часовой задачи — 10-15 минут grace period.

Разделение алертов по критичности

• Critical: обработка платежей, резервное копирование, отправка заказов
• Warning: генерация отчётов, очистка старых данных, обновление кэша
• Info: статистика, аналитика, неважные уведомления

Документация

Для каждой крон-задачи документируйте:

• Что делает задача
• Расписание и ожидаемое время выполнения
• Что делать при сбое (runbook)
• Зависимости (БД, внешние API документацию, файлы)

Мониторинг с Enterno.io

Настройте Heartbeat Monitor на Enterno.io для мониторинга крон-задач. Создайте мониторинг для каждой критической задачи, укажите ожидаемый интервал и grace period. После выполнения задачи отправляйте HTTP-запрос на URL мониторинга.

Используйте панель мониторов для обзора статуса всех крон-задач в одном месте.

Итоги

Крон-задачи — невидимая, но критически важная часть инфраструктуры. Dead Man's Switch — оптимальный паттерн для их мониторинга: задача сама сообщает о здоровье, а отсутствие сообщения — сигнал проблемы. Мониторьте не только выполнение, но и длительность, используйте timeout и lock-файлы, логируйте всё.