Come monitorare i cron job: 5 pattern con check heartbeat

Cron è eccellente nell'avviare le cose secondo un programma e disastroso nel dirti quando non lo fa. Un backup che smette di girare raramente lancia un errore che vedrai. Semplicemente non fa nulla in silenzio e lo scopri settimane dopo, quando il backup ti serve e non c'è. È il problema del guasto silenzioso ed è esattamente per questo che ogni attività pianificata che conta ha bisogno di un check heartbeat.

Un heartbeat (o "dead man's switch") ribalta la logica. Invece di avvisare quando qualcosa va storto, la tua attività fa un ping a un endpoint di monitoraggio quando tutto è a posto. Se il ping atteso non arriva in tempo, il monitor avvisa. Nessun ping, nessuna notizia, grosso problema.

Qui sotto trovi cinque pattern, dal più semplice al più robusto. Tutti presuppongono che tu abbia un URL heartbeat dal tuo strumento di monitoraggio.

Pattern 1: il classico dead man's switch

La configurazione più semplice possibile. Al termine, la tua attività chiama l'URL. Se il monitor non riceve notizie nella finestra attesa, avvisa.

# Backup giornaliero alle 02:30, ping al termine
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://tuo-monitor/ping/abc123

Il && conta: curl viene eseguito solo se backup.sh termina con codice 0 (successo). Se il backup fallisce, nessun ping viene inviato e il monitor lo intercetta. Le opzioni -fsS fanno sì che curl fallisca in silenzio sugli errori HTTP, mostrando comunque i problemi reali.

Punto debole: conferma solo che lo script è girato ed è terminato con zero. Se lo script inghiotte i propri errori e termina comunque con zero, ricevi un falso "tutto a posto".

Pattern 2: ping solo al successo reale

Rendi esplicito il segnale di successo invece di affidarti al concatenamento dei codici di uscita nella shell. Negli script a più passi è più chiaro.

#!/bin/bash
set -euo pipefail   # a qualsiasi errore, fermati con clamore
run_the_backup
verify_the_backup    # verifica davvero che l'output esista e abbia senso
curl -fsS https://tuo-monitor/ping/abc123   # raggiunto solo se tutto sopra è passato

set -euo pipefail significa che qualsiasi comando fallito interrompe lo script prima del ping. Aggiungere un vero passo di verifica (il file di backup esiste, è più grande di zero byte) chiude il buco "terminato con zero ma non ha fatto nulla" del Pattern 1.

Pattern 3: il wrapper dell'exit code

Quando non puoi modificare l'attività stessa (un binario di terze parti, uno script del fornitore), avvolgila. Il wrapper segnala l'avvio, esegue l'attività e riporta il codice di uscita.

#!/bin/bash
URL=https://tuo-monitor/ping/abc123
curl -fsS "$URL/start"                  # segnale "sono partito"
/opt/vendor/report-generator            # attività che non controlli
EXIT=$?
curl -fsS "$URL/$EXIT"                   # riporta il codice di uscita

Segnalare l'avvio permette al monitor anche di misurare la durata dell'esecuzione e scoprire un'attività che è partita ma non è mai terminata (si è bloccata). Riportare il codice di uscita gli permette di distinguere "girato bene" da "girato e fallito".

Pattern 4: ping condizionato (fai il ping solo quando il lavoro ha avuto senso)

Alcune attività girano secondo programma ma fanno lavoro reale solo a volte (un processore di coda che spesso la trova vuota). Non vuoi un avviso di "heartbeat mancante" quando l'attività non ha legittimamente fatto nulla. Fai il ping solo quando il lavoro reale è avvenuto e amplia di conseguenza il programma.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://tuo-monitor/ping/abc123?count=$PROCESSED"
fi

Imposta il periodo atteso del monitor sull'intervallo reale più lungo tra esecuzioni effettive. Il prezzo è la sensibilità: una finestra più lunga significa una rilevazione più lenta, quindi usalo solo quando il lavoro irregolare è davvero previsto.

Pattern 5: jitter e grace window

I programmi reali derivano. Un'attività impostata per le 02:00 può partire alle 02:00:04 a causa del carico e la durata di un'attività giornaliera oscilla. Se il monitor si aspetta il ping esattamente all'intervallo, un normale jitter ti farà scattare inutilmente.

La soluzione è una grace period: di' al monitor di aspettare ancora un certo margine dopo l'orario atteso prima di avvisare. Un backup giornaliero che di solito dura 8 minuti può usare una grace window di 20 minuti. Vuoi anche un po' di jitter nella pianificazione stessa, quando hai molte attività, perché non carichino la stessa risorsa nello stesso secondo:

# Aggiungi un piccolo ritardo casuale (0-59s) per distribuire le attività delle 02:00
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://tuo-monitor/ping/abc123

Le grace window sono la differenza tra un monitor di cui ti fidi e uno che silenzi dopo il terzo falso allarme. Imposta la grace in modo che superi comodamente il tempo di esecuzione peggiore reale dell'attività, non la sua media.

Riepilogo rapido

Come metterlo in pratica

Inizia oggi stesso con il Pattern 1 sull'attività più importante (backup, ciclo di fatturazione, sincronizzazione dati). Aggiungi la verifica (Pattern 2) e la grace window (Pattern 5) prima di iniziare a farci affidamento. Per una guida più dettagliata alla configurazione dell'heartbeat consulta il nostro tutorial su monitorare i cron job con gli heartbeat.

Se la tua attività comunica con un servizio su una porta specifica, verifica prima la raggiungibilità con il port checker gratuito. E quando sarai pronto a monitorare le attività pianificate insieme a siti e API in un unico posto, guarda come funziona il monitoraggio uptime di ePulz.io - la prova di 7 giorni è gratuita, senza carta.