Мониторинг на cron задачи

Проблем с планираните задачи

Жестока черта на cron задачите е, че когато спрат, никой няма да ти каже. Уеб приложението продължава да обслужва заявки, началната страница изглежда ОК, мониторингът свети в зелено – но някъде на сървъра нощният бекъп не е стартирал от две седмици. Queue worker е паднал след deploy и изостаналите задачи се трупат. Почасовата синхронизация тихомълком губи редове поради проблем с правата. Разбираш едва когато нещо надолу по веригата най-накрая се счупи – обикновено точно тогава, когато най-много ти трябва. Data team иска export, support – опашка с мейли, ops – бекъп. Тогава вече е късно.

Стандартният uptime мониторинг няма да го хване, защото няма какво да пингва. Cron не отваря HTTP endpoint, не отваря порт, не стартира сървър. Пуска се, завършва, толкова. Ако спре да работи – нямаш никакъв сигнал за липсата му, докато не започнеш да търсиш.

Обратен модел: heartbeat мониторинг

Heartbeat мониторингът (наричан още „dead man’s switch” или „мониторинг на cron-и”) обръща посоката. Вместо ние да проверяваме твоята услуга, твоята услуга се отчита при нас. Добавяш един ред в crona – curl към уникален URL, който ние генерираме – този URL записва timestamp при всяко „почукване”. Ние следим липсата на тези ping-ове. Ако URL не бъде посетен в очаквания интервал (с известен толеранс), го считаме за пропуснат run и пращаме аларма.

Моделът е прост, надежден и независим от езика. Всичко, което може да направи HTTP заявка – се интегрира. Bash чрез curl, Python чрез requests, Node чрез fetch, PHP чрез curl_init, Task Scheduler под Windows чрез Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – всичко. Без SDK, без агент, без daemon за инсталиране.

Как да конфигурирате

В DiagnoSEO Uptime Monitoring кликни „Добави монитор“, избери тип „Heartbeat / cron“. Инструментът генерира уникален URL с token – нещо като https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Задай очаквания интервал (колко често да работи задачата, минути) и толеранса (с колко закъснение run-ът е ОК, преди да вдигнем тревога). Запази.

Сега редактирай crona така, че да ping-ва URL-а след всяко успешно изпълнение. Три стила според средата:

# Bash cron – ping само при успех
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Или ако частичен успех е ОК
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

От този момент всеки успешен run ни ping-ва, а ние записваме timestamp. Ако не получим ping в рамките на интервал + толеранс минути, се открива инцидент и се изпращат уведомления по всички активни канали: Email, Telegram, Slack, Discord, SMS.

Избор на интервал и толеранс

Интервалът трябва да пасне точно на графика на задачата. Нощен backup в 3:00 – интервал 1440 минути (24ч). Часова синхронизация – 60. Worker, който проверява на 5 минути – 5.

Толерансът поема естествения jitter. Cron-ите не стартират абсолютно в nanosecond – нареждат се на опашка, чакат да свърши предишният run, правят back-off при временни грешки. 24-часова задача с 1-часов толеранс дава достатъчен буфер без да бави алармите. 5-минутен worker с 2-минутен толеранс хваща истинските падания бързо, без false-positives от 30-секундни лагове. Най-общо: сложи толеранса на 10-50% от интервала според това колко „джитка” задачата ти.

Препоръчвани практики

• Ping само при успех. Използвай && в bash – паднал run не пингва. Ние ще видим липсата на ping и ще алармираме.
• Ping след всяка итерация на цикъла. За дълго работещи worker-и пингвай вътре в цикъла, след всяка успешна обработена единица, не накрая. Така увиснал worker се хваща по време на изпълнение.
• Един heartbeat на логическа задача, не на скрипт. Ако три скрипта са един нощен pipeline, пингвай веднъж – в края на веригата. Дава чист сигнал „жив ли е pipeline-ът“.
• Комбинирай с логове. Heartbeat казва, че job-ът се е стартирал. Логовете показват какво е направил. Заедно дават пълна картина.

Какво става, ако heartbeat изчезне

Инцидент се отваря в момента на изпускане на крайната точка. Dashboard-а показва монитора в червено с грешка „Липсва heartbeat от X минути“. Нотификациите летят по всички включени канали. Когато свеж heartbeat пристигне, монитора автоматично се връща в up – отбелязан като up, инцидентът се затваря, а (ако имаш recovery alerts включени) получаваш уведомление „обратно онлайн“.

Всичко това се третира като останалите монитори – heatmap, процент uptime, история, тагове, търсене, експорт. От гледна точка на dashboard-а, heartbeat мониторът е просто още един ред, който можеш да сортираш и филтрираш редом до HTTP, ping, port и API.

Чеклист

Добави монитор → тип Heartbeat → копирай генерирания URL → сложи в cron / worker / scheduler → задаj интервал и толеранс → запази → готово. Вече ще знаеш за спряна планирана задача за секунди – което дългосрочно е едно от най-важните мониторинг решения, които можеш да вземеш.

Често задавани въпроси

• Какво е heartbeat / cron-job мониторинг?

  Обратен мониторинг – твоята планирана задача пингва нашия URL, когато се стартира успешно. Ако не я чуем в очаквания прозорец, алармираме. Решава проблема на тихите сривове: повреденият cron job не хвърля грешка и не задейства стандартен uptime alert.

• Как да интегрирам heartbeat URL-а в моя cron?

  Добави curl -fsS <heartbeat_url> в края на cron командата. Ако командата преди него се провали, curl няма да се изпълни и heartbeat ще бъде пропуснат. Алтернативно – пингувай в началото И края на задачата по различни пътища – така имаш отделни сигнали „started“ и „completed“.

• Какъв grace период да задам?

  Около 2-3x типичното време за изпълнение на задачата. Ако дневният ти backup отнема 30 минути, сложи grace на 90 – поема закъснения без фалшиви аларми. За задачи с променливо време на работа задай щедро и ползвай dashboard-а за откриване на outliers.

• Мога ли да наблюдавам cron job-и, които се пускат на всеки час?

  Да – настрой интервала според нуждата (напр. 60 минути очаквано + 15 минути grace). Мониторът изисква ping поне всеки 75 минути. Ако задачата е по-честа (напр. на 5 минути), heartbeat URL също го поддържа – просто нагласи интервала.

• Работи ли heartbeat мониторинга за AWS Lambda / serverless?

  Да. Добави изходящ HTTP request към heartbeat URL-а в края на Lambda функцията. Мониторът го третира също както cron heartbeat – същото алармиране, също grace. Полезно за планирани Lambd-и, където CloudWatch алармите не улавят неми сривове.