Cron joby és háttér worker-ek monitorozása heartbeat-en keresztül

Röviden: A klasszikus HTTP monitorozás nem észleli, hogy leesett az éjszakai cron, ami számlákat küld vagy adatokat szinkronizál. A heartbeat minta megfordítja a kommunikáció irányát - a cron jelentkezik a monitorozásnak, és ha a várt időben nem hív, riasztást kapsz.

A probléma: háttér feladatok HTTP végpont nélkül

Egy tipikus backend útvonalai:

• Webes kérések (HTTP/HTTPS a szerverre) - uptime check-kel monitorozod.
• Cron job-ok (napi backup, havi számlázás, óránkénti szinkronizáció) - nincs HTTP végpontjuk, a külső monitorozás nem látja őket.
• Worker-ek (Celery, BullMQ, Sidekiq), amik egy queue-t fogyasztanak - szintén HTTP nélkül.

Ha a cron leesik (megváltoztatod a crontab-ot és elgépeled, a szerveren nincs disk, hiányzik egy environment variable, egy dependency upgrade eltörte az importot), senki nem figyelmeztet - amíg hétfő reggel észre nem veszed, hogy a hétvégén nem küldtél ki számlákat.

Heartbeat minta: a cron pingeli a monitorozást

Az elv fordított a normál monitorozáshoz képest:

1. A monitoring szolgáltatásban létrehozol egy heartbeat monitort a várt intervallummal (pl. "60 percenként").
2. Egyedi heartbeat URL-t kapsz: https://epulz.io/heartbeat/abc123xyz.
3. A cron job-od végén sikeres futás után meghívod ezt az URL-t (HTTP GET vagy POST).
4. Ha a ping nem érkezik meg a várt időben (+ grace periódus), a monitorozás riaszt.

Gyakorlati példa: bash cron

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

A kulcs a && - a heartbeat csak akkor küldődik, ha a backup.sh exit kód 0-val végződik. Ha a script hibázik, a ping nem jön, és egy órán belül riasztást kapsz.

Tipp: Alaposabb lefedettséghez adj hozzá egy "start" heartbeat-et is:

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

A monitorozás akkor megkülönbözteti a "elindult és nem fejezte be" (script befagyott) a "egyáltalán nem indult el" (a cron job nem futott).

Python: requests + try/except

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

def sync_data():
    # a te logikád
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # A heartbeat nem küldődik - a monitorozás riaszt
    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 period: mennyi időt adj a riasztás előtt

A heartbeat monitornak tolerancia kell - a cron olykor tovább fut, mint általában, a hálózatnak van latency-je, az NTP szinkronizáció enyhén el lehet csúszva. A grace period az az idő a várt intervallum után, ami alatt a monitorozás még vár.

Gyakorlati értékek:

• Hourly cron: intervallum 60 perc + grace 10 perc
• Daily backup (átlagosan 20 perc): intervallum 1440 perc + grace 60 perc
• Weekly report: intervallum 10080 perc + grace 360 perc (6 ó)

Túl szoros grace = false-positive riasztások. Túl laza = késleltetett figyelmeztetés, amikor tényleg leesik.

Hol segít a heartbeat minta a legtöbbet

• Éjszakai DB backup-ok
• Szinkronizáció külső API-kkal (CRM, accounting, payment)
• Riport kalkulációk
• Cleanup feladatok (régi session-ök, logok, ideiglenes fájlok törlése)
• Hosszú futású worker-ek healthcheck ciklusa
• Ütemezett emailek, hírlevelek, számlázás

Következtetés

A háttér feladatok gyakran kritikusabbak, mint maga a web, mégis a monitorozás vakfoltja maradnak. A heartbeat minta 5 perces implementációt igényel (egy curl hozzáadása a cron sor végéhez) és ugyanazt a lelki nyugalmat adja, mint a frontend uptime monitorozása.

Kezdd el monitorozni a cron job-okat

Az ePulz.io támogatja a heartbeat check-eket konfigurálható grace periódussal. 7 nap ingyen.

Monitoring indítása →