Monitorizare joburi cron

Problemă cu sarcinile programate

O trăsătură crudă a cron-urilor este că, atunci când se opresc, nimeni nu te va anunța. Aplicația web servește în continuare cereri, pagina principală pare OK, monitorizarea e pe verde – dar undeva pe server, backup-ul de noapte nu a mai pornit de două săptămâni. Worker-ul de coadă s-a blocat după deploy și job-urile restante se tot adună. Sincronizarea orară pierde liniștit rânduri din cauza unei probleme de permisiuni. Afli abia atunci când ceva din lanțul de procese cedează – de obicei chiar atunci când ai cea mai mare nevoie de acel lucru. Echipa de date vrea un export, support-ul așteaptă coadă de mailuri, operaționalul backup-ul. Atunci e deja prea târziu.

Monitorizarea standard de uptime nu va detecta asta, pentru că nu are ce să pinguiască. Cron-ul nu oferă un endpoint HTTP, nu deschide port, nu pornește server. Se pornește, rulează, se termină. Dacă încetează să funcționeze – nu există niciun semnal al absenței sale până nu începi să cauți.

Pattern inversat: monitorizare heartbeat

Monitorizarea heartbeat (numită și „dead man's switch” sau „monitorizarea cron-urilor”) inversează direcția. În loc să verificăm noi serviciul tău, serviciul tău ne anunță pe noi. Adaugi o singură linie la cron – curl către un URL unic generat de noi – iar acest URL salvează un timestamp la fiecare batere. Noi monitorizăm absența acestor ping-uri. Dacă URL-ul nu este accesat în intervalul așteptat (plus marja), tratăm asta ca pe o execuție ratată și trimitem o alertă.

Modelul este simplu, fiabil și independent de limbaj. Orice poate face un request HTTP – se integrează. Bash prin curl, Python prin requests, Node prin fetch, PHP prin curl_init, Task Scheduler pe Windows cu Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, evenimente programate Lambda – orice. Fără SDK, fără agent, fără daemon de instalat.

Cum să configurezi

În DiagnoSEO Uptime Monitoring, dă click pe „Adaugă monitor”, selectează tipul „Heartbeat / cron”. Instrumentul generează un URL unic cu token – ceva de genul https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Setezi intervalul așteptat (cât de des trebuie să ruleze job-ul, în minute) și marja (cu cât este acceptabil să întârzie execuția înainte să alarmăm). Salvezi.

Acum modifică cron-ul astfel încât să trimită ping la URL după fiecare execuție reușită. Trei stiluri în funcție de mediul de rulare:

# Bash cron – ping doar după succes
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Sau dacă este ok și un succes parțial
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

De acum înainte, fiecare execuție cu succes ne va trimite un ping, iar noi vom salva timestamp-ul. Dacă nu vedem un ping în interval + marjă minute, se deschide un incident și notificările ajung automat pe toate canalele activate: Email, Telegram, Slack, Discord, SMS.

Selectarea intervalului și a marjei

Intervalul trebuie să coincidă exact cu programarea job-ului. Backup-ul de noapte la 3:00 – interval 1440 minute (24h). Sincronizare orară – 60. Worker care rulează la fiecare 5 minute – 5.

Marja absoarbe jitter-ul natural. Cron-urile nu rulează chiar la nanosecundă – sunt puse în coadă, așteaptă finalizarea execuției precedente, fac back-off la erori temporare. Un job de 24 de ore cu marjă de 1 oră oferă un buffer confortabil fără să întârzie alertele. Un worker cu interval de 5 minute și marjă de 2 minute detectează rapid defecte reale, fără false pozitive generate de întârzieri minore de 30 de secunde. În general: setează marja la 10-50% din interval în funcție de cât de mult „variază” job-ul tău.

Pattern-uri pe care le recomandăm

• Ping doar după succes. Folosește && în bash – o execuție eșuată nu trimite ping. Noi detectăm lipsa ping-ului și alertăm.
• Ping după fiecare iterație a buclei. Pentru workeri care rulează mult timp, trimite ping în interiorul buclei după fiecare task finalizat cu succes, nu la sfârșit. Astfel, un worker blocat este detectat chiar în timpul rulării.
• Un singur heartbeat pe job logic, nu pe fiecare script. Dacă trei scripturi împreună formează o singură pipelină de noapte, trimite ping o singură dată la sfârșitul lanțului. Vei avea semnal clar „pipeline-ul este funcțional”.
• Combină cu loguri. Heartbeat confirmă că job-ul a pornit. Logurile aplicației spun ce a făcut. Împreună, oferă imaginea completă.

Ce se întâmplă dacă heartbeat-ul lipsește

Incidentul se deschide imediat ce deadline-ul a fost depășit. Dashboard-ul afișează monitorul pe roșu cu eroarea „Nu există heartbeat de X minute”. Notificările sunt trimise pe toate canalele active. Când vine un nou heartbeat, monitorul revine automat pe up – este marcat ca up, incidentul se închide, iar (dacă ai active recuperarea alertelor) primești notificarea „back online”.

Toate acestea au același tratament ca orice alt monitor – heatmap, procent uptime, istoric, tag-uri, căutare, export. Din perspectiva dashboard-ului, monitorul heartbeat este doar un alt rând care poate fi sortat și filtrat alături de HTTP, ping, port și API.

Listă de verificare

Adaugă monitor → tip Heartbeat → copiază URL-ul generat → adaugă-l în cron / worker / scheduler → setează intervalul și marja → salvează → gata. De acum vei ști instant când o sarcină programată se oprește – ceea ce, pe termen lung, este una dintre cele mai importante decizii de monitorizare pe care le poți lua.

Întrebări frecvente

• Ce este monitorizarea heartbeat / cron-job?

  Monitorizare inversată — sarcina ta programată face ping la URL-ul nostru atunci când pornește cu succes. Dacă nu primim semnal de la ea în intervalul așteptat, trimitem alertă. Rezolvă problema defecțiunilor silențioase: un cron job stricat nu produce eroare și nu declanșează o alertă clasică de uptime.

• Cum integrez URL-ul heartbeat cu cron-ul meu?

  Adaugă curl -fsS <heartbeat_url> la finalul comenzii cronului. Dacă comanda dinainte eșuează, curl nu se va executa și heartbeat-ul va fi omis. Alternativ, trimite ping atât la început, cât și la sfârșit, pe căi diferite – vei avea semnale separate de „started” și „completed”.

• Ce grace period ar trebui să setez?

  Aprox. de 2-3x durata tipică de execuție a task-ului. Dacă backup-ul tău zilnic durează 30 de minute, setează grace la 90 de minute – astfel acoperi întârzierile fără alerte false. Pentru task-uri cu durate variabile, setează generos și folosește dashboard-ul pentru a identifica outlier-ii.

• Pot monitoriza cron job-uri care rulează la fiecare oră?

  Da — setează intervalul potrivit (ex. 60 minute așteptate cu 15 minute grace). Monitorul va aștepta să primească ping cel puțin la fiecare 75 de minute. Dacă task-ul tău rulează mai frecvent (la fiecare 5 minute), URL-ul heartbeat suportă și asta – doar adaptează intervalul.

• Funcționează monitorizarea heartbeat și pentru AWS Lambda / serverless?

  Da. Adaugă un request HTTP către URL-ul heartbeat la finalul funcției Lambda. Monitorul tratează asta identic cu un cron heartbeat – aceleași alerte, aceeași perioadă de grație. Foarte util pentru Lambdas programate unde alertele CloudWatch nu detectează execuțiile eșuate silențios.