Időzített feladatok felügyelete

Probléma az ütemezett feladatokkal

A cronok kegyetlen tulajdonsága, hogy amikor leállnak, nem szól senki. A webalkalmazás továbbra is kiszolgálja a kéréseket, a főoldal rendben néz ki, a monitorozás zöld - de valahol a szerveren az éjszakai mentés két hete nem futott le. A queue worker deploy után elszállt, a feldolgozatlan feladatok csak gyűlnek. Az óránkénti szinkronizáció csöndben elveszít néhány sort jogosultsági probléma miatt. Csak akkor jössz rá, amikor valami downstream végül összeomlik – általában pont akkor, amikor a legnagyobb szükséged lenne rá. Az adatelemző csapat exportot kér, a support pedig e-mail sort, az ops a backupot. Akkor pedig már késő.

A szokásos uptime monitorozás ezt nem veszi észre, mert nincs mit pingelni. A cron nem biztosít HTTP végpontot, nem nyit portot, nem indít szervert. Elindul, befejeződik, ennyi. Ha leáll – nincs semmilyen jelzése annak, hogy eltűnt, amíg el nem kezded keresni.

Ellenkező minta: heartbeat monitoring

A heartbeat monitoring (más néven "dead man's switch" vagy "cron monitorozás") megfordítja az irányt. Ahelyett, hogy mi ellenőriznénk a Te szolgáltatásodat, a Te szolgáltatásod jelentkezik nálunk. Hozzáadsz egy sort a cronhoz – egy curl egy általunk generált egyedi URL-re –, és ez az URL minden bejelentkezésnél elmenti az időbélyeget. Mi figyeljük ezeknek a pingeknek a hiányát. Ha az URL nem kapja meg a hívást a várt időközönként (plusz tűrés), azt kihagyott futásnak tekintjük és riasztást küldünk.

A modell egyszerű, megbízható és nyelvtől független. Bármi, ami tud HTTP kérést küldeni – integrálható. Bash curl-lal, Python requests-cel, Node fetch-csel, PHP curl_init-tel, Windows Task Scheduler Invoke-WebRequest-tel, GitHub Actions, Kubernetes CronJobs, Lambda ütemezett események – akármi. Nincs SDK, nincs ügynök, nincs háttérfolyamat telepítése.

Hogyan konfiguráld

A DiagnoSEO Üzemidő Monitorozásban kattints a "Monitor hozzáadása" gombra, válaszd a "Heartbeat / cron" típust. Az eszköz generál egy egyedi URL-t tokennel – valami ilyesmit: https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Állítsd be a várt időközt (milyen gyakran fusson a feladat, percben) és a tűrést (mennyire késhet a futás, mielőtt pánikot keltenénk). Mentsd el.

Most módosítsd a cront, hogy minden sikeres futás után pingelje ezt az URL-t. Három stílus attól függően, hogy milyen környezetben vagy:

# Bash cron - ping csak siker esetén
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Vagy ha a részleges siker is elfogadható
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

Innentől kezdve minden sikeres futás jelez nekünk, mi pedig elmentjük az időbélyeget. Ha intervallum + tűrés percen belül nem látunk új pinget, akkor incidenst nyitunk, és értesítést küldünk minden bekapcsolt csatornán: Email, Telegram, Slack, Discord, SMS.

Intervallum és tűrés kiválasztása

Az intervallum pontosan illeszkedjen a feladat ütemezéséhez. Éjszakai mentés 3:00-kor – intervallum 1440 perc (24 óra). Óránkénti szinkronizáció – 60. 5 percenként polloló worker – 5.

A tűrésben elfér a természetes szórás. A cronok nem indulnak nanosekundumra pontosan – sorba állnak, megvárják az előző futás végét, esetleges hibáknál hátrébb lépnek. Egy 24 órás feladat 1 órás tűréssel kényelmes puffer, nincs felesleges riasztás. Egy 5 percenként polloló worker 2 perces tűréssel gyorsan elkapja a valódi leállásokat, anélkül hogy egy 30 másodperces késés téves riasztást okozna. Általános ökölszabály: a tűrést állítsd az intervallum 10-50%-ára, attól függően, mennyire "ingadozó" a feladat.

Ajánlott minták

• Ping csak siker után. Használj &&-t bash-ben – a hibás futás nem küld pinget. Mi érzékeljük a ping hiányát és riadót küldünk.
• Ping minden ciklus után. Hosszú ideig futó workereknél pingelj a cikluson belül minden sikeres munkadarab után, ne a végén. Így egy beragadt worker futás közben is detektálható.
• Egy heartbeat egy logikai feladathoz, nem minden scripthez. Ha három scripttel építesz fel egy éjszakai pipeline-t, csak egyszer pingelj a lánc végén. Ez ad egy tiszta "pipeline él" jelet.
• Kombináld logokkal. A heartbeat azt mutatja, hogy lefutott a feladat. Az alkalmazás logjaiból derül ki, mit csinált. Együtt teljes képet kapsz.

Mi történik, ha eltűnik a heartbeat

Az incidens a határidő túllépésekor nyílik meg. A dashboard pirossal mutatja a monitort "Nincs heartbeat X perce" hibával. Az értesítések minden bekapcsolt csatornára elküldésre kerülnek. Amint új heartbeat érkezik, a monitor automatikusan visszavált zöldre – jelzi, hogy elérhető, az incidens lezárul, és (ha bekapcsoltad a helyreállítási riasztásokat) kapsz egy "újra elérhető" értesítést.

Mindez ugyanúgy működik, mint bármely más monitor – hőtérkép, üzemidő százalék, előzmények, címkék, keresés, export. A dashboard szempontjából a heartbeat monitor csak egy újabb sor, sorba rendezhető és szűrhető HTTP, ping, port vagy API mellett.

Ellenőrzőlista

Monitor hozzáadása → Heartbeat típus → generált URL másolása → hozzáadás cronhoz / workerhez / ütemezőhöz → intervallum és tűrés beállítása → mentés → kész. Mostantól azonnal értesülsz, ha egy ütemezett feladat leáll – ami hosszú távon az egyik legfontosabb monitoring döntés, amit meghozhatsz.

Gyakran ismételt kérdések

• Mi az a heartbeat/croon-job monitorozás?

  Fordított monitorozás — az ütemezett feladatod pingeli a mi URL-ünket, ha sikeresen lefut. Ha a várt időablakban nem hallunk felőle, riasztunk. Megoldja a csendes hibák problémáját: az elromlott cron job nem dob hibát, és nem indít hagyományos uptime riasztást.

• Hogyan integrálom a heartbeat URL-t a cronomhoz?

  Tedd a curl -fsS <heartbeat_url> parancsot a cron végére. Ha az előtte lévő parancs hibázik, a curl nem fut le, a heartbeat kimarad. Alternatívaként pingelhetsz külön az elején és végén – így külön jelet kapsz az "indult" és "befejeződött" futásokról.

• Mekkora legyen a türelmi idő (grace period)?

  Kb. 2-3x a feladat tipikus futási ideje. Ha a napi backup 30 percet vesz igénybe, állítsd a türelmet 90 percre – így belefér a lassulás, nem kapsz téves riasztást. Változó futási idejű feladatokhoz állíts bőkezűen, majd használd a dashboardot a szélső értékek azonosításához.

• Tudom monitorozni az óránként futó cronokat?

  Igen – állítsd az intervallumot annak megfelelően (pl. 60 perc várható, 15 perc türelem). A monitor legalább 75 percenként vár pinget. Ha gyakrabban fut a feladatod (pl. 5 percenként), a heartbeat URL erre is jó – csak igazítsd az intervallum beállítását.

• Működik a heartbeat monitorozás AWS Lambda / serverless esetén?

  Igen. Adj hozzá egy HTTP kérést a heartbeat URL-re a Lambda függvény végén. A monitor ezt pontosan úgy kezeli mint a cron heartbeat-et – ugyanaz a riasztás, ugyanaz a türelmi idő. Hasznos olyan ütemezett Lambdákhoz, ahol a CloudWatch riasztások nem veszik észre a csendes hibákat.