Monitoraggio dei processi cron

Problema con i task programmati

Una caratteristica crudele dei cron è che, quando smettono di funzionare, nessuno te lo dice. L'applicazione web continua a servire le richieste, la homepage appare normale, il monitoring è tutto verde – ma da qualche parte sul server il backup notturno non è partito da due settimane. Il queue worker si è fermato dopo il deploy e i job arretrati si accumulano. La sincronizzazione oraria silenziosamente perde righe per un problema di permessi. Te ne accorgi solo quando qualcosa a valle finalmente si rompe – di solito proprio quando quella cosa ti serve di più. Il data team vuole un export, il support ha una coda di email, gli ops vogliono il backup. A quel punto è troppo tardi.

Il monitoring di uptime standard non lo rileva, perché non c’è nulla da pingare. Il cron non espone un endpoint HTTP, non apre una porta, non avvia un server. Parte, finisce, fine. Se smette di funzionare – nessun segnale della sua assenza finché non vai a cercarlo.

Pattern inverso: monitoring heartbeat

Il monitoring heartbeat (chiamato anche "dead man's switch" o "monitoraggio dei cron") inverte la direzione. Invece di noi che controlliamo il tuo servizio, il tuo servizio si registra da noi. Aggiungi una linea al cron – un curl a un URL unico che generiamo noi – e quell’URL salva il timestamp ad ogni chiamata. Noi monitoriamo l’assenza di questi ping. Se l’URL non viene chiamato nell’intervallo previsto (più margine), lo consideriamo come una corsa mancata e mandiamo un alert.

Il modello è semplice, affidabile e indipendente dal linguaggio. Qualsiasi cosa possa fare una richiesta HTTP – si integra. Bash tramite curl, Python tramite requests, Node tramite fetch, PHP tramite curl_init, Task Scheduler su Windows tramite Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – qualsiasi cosa. Senza SDK, senza agent, senza demone da installare.

Come configurare

Su DiagnoSEO Uptime Monitoring clicca "Aggiungi monitor", scegli il tipo "Heartbeat / cron". Lo strumento genera un URL unico con token – qualcosa come https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Imposta l’intervallo atteso (ogni quanto deve girare il job, in minuti) e il margine (quanto ritardo è OK, prima di farci preoccupare). Salva.

Ora modifica il cron per pingare l’URL dopo ogni esecuzione riuscita. Tre stili a seconda dell’ambiente:

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

# O quando anche il successo parziale va bene
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

Da quel momento ogni corsa eseguita con successo ci pingerà, e noi salveremo il timestamp. Se non vediamo un ping entro intervallo + margine minuti, viene aperto un incidente e partono le notifiche su tutti i canali attivi: Email, Telegram, Slack, Discord, SMS.

Scelta di intervallo e margine

L’intervallo deve corrispondere esattamente alla schedulazione del job. Backup notturno alle 3:00 – intervallo 1440 minuti (24h). Sincronizzazione oraria – 60. Worker che fa polling ogni 5 minuti – 5.

Il margine assorbe il jitter naturale. I cron non partono letteralmente al nanosecondo – vengono messi in coda, aspettano la fine del job precedente, fanno back-off su errori temporanei. Un job giornaliero con 1h di margine dà un comodo buffer senza ritardare gli alert. Un worker ogni 5 minuti con margine di 2 minuti intercetta i reali malfunzionamenti rapidamente, senza falsi positivi per interruzioni di 30 secondi. In media: imposta il margine al 10-50% dell’intervallo, a seconda di quanto il job “oscilla”.

Pattern che consigliamo

• Ping solo su successo. Usa && in bash – il job che fallisce non pingerà. Noi rileveremo l’assenza di ping e ti allertiamo.
• Ping dopo ogni iterazione di loop. Per worker che durano a lungo, pingare all’interno del loop dopo ogni unità completata di lavoro – non solo alla fine. Così un worker bloccato viene rilevato durante l’esecuzione.
• Un heartbeat per ogni job logico, non per ogni script. Se tre script insieme compongono un pipeline notturno, ping una volta sola alla fine della catena. Così hai un segnale chiaro “il pipeline è vivo”.
• Combina con i log. L’heartbeat dice che il job è partito. I log dell’app dicono cosa ha fatto. Insieme danno il quadro completo.

Cosa succede se l’heartbeat sparisce

L’incidente viene aperto al superamento della deadline. La dashboard mostra il monitor rosso con l’errore "Nessun heartbeat da X minuti". Le notifiche partono su tutti i canali configurati. Quando arriva di nuovo un heartbeat recente, il monitor torna up – viene marcato come up, l’incidente viene chiuso, e (se hai attivate le notifiche di recovery) ricevi l’avviso "back online".

Tutto questo ha lo stesso trattamento degli altri monitor – heatmap, percentuale uptime, storico, tag, ricerca, esportazione. Dal punto di vista della dashboard, il monitor heartbeat è solo un’altra riga, ordinabile e filtrabile accanto a HTTP, ping, porta e API.

Checklist

Aggiungi monitor → tipo Heartbeat → copia l’URL generato → aggiungi a cron / worker / scheduler → imposta intervallo e margine → salva → fatto. Ora saprai in un secondo se un task programmato smette di funzionare – che a lungo termine è una delle decisioni più critiche di monitoraggio che puoi prendere.

Domande frequenti

• Cos’è il monitoring heartbeat / cron-job?

  Monitoring inverso — il tuo task programmato pinga il nostro URL quando viene lanciato correttamente. Se non lo sentiamo nell’intervallo atteso, ti avvisiamo. Risolve il problema dei guasti silenziosi: un cron-job rotto non genera errori e non fa scattare un alert di uptime tradizionale.

• Come integro l’URL heartbeat nel mio cron?

  Aggiungi curl -fsS <heartbeat_url> alla fine del comando cron. Se il comando prima fallisce, curl non verrà eseguito e l’heartbeat sarà omesso. In alternativa puoi pingare sia all’inizio che alla fine con percorsi diversi — così ottieni separatamente i segnali "started" e "completed".

• Quale grace period dovrei impostare?

  Circa 2-3 volte il tempo di esecuzione tipico del task. Se il tuo backup giornaliero dura 30 minuti, imposta il grace a 90 minuti — così puoi tollerare rallentamenti senza falsi allarmi. Per task dal tempo variabile, imposta uno scarto generoso e usa la dashboard per identificare eventuali outlier.

• Posso monitorare cron job che girano ogni ora?

  Sì — imposta l’intervallo di conseguenza (es. 60 minuti attesi con 15 minuti di grace). Il monitor si aspetta un ping almeno ogni 75 minuti. Se il tuo task è più frequente (ogni 5 minuti), anche l’URL heartbeat lo gestisce — ti basta adeguare l’impostazione dell’intervallo.

• Il monitoring heartbeat funziona per AWS Lambda / serverless?

  Sì. Aggiungi una chiamata HTTP verso l’URL heartbeat alla fine della funzione Lambda. Il monitor lo tratta proprio come un cron heartbeat — stesso alert, stesso grace period. Utile per le Lambda schedulate dove gli allarmi CloudWatch non rilevano failure silenziose dell’esecuzione.