Perché i tuoi cron job falliscono silenziosamente (e come accorgertene)

Il problema con cron

Cron è affidabile in un senso: eseguirà il tuo comando secondo la pianificazione. Non è affidabile in un altro senso, più importante: non ti dice quando il tuo comando fallisce.

Il tuo server è in esecuzione. Il demone cron funziona. La pianificazione si attiva in orario. Ma lo script a cui l’hai indirizzato termina con uno stato diverso da zero, va in timeout o esaurisce la memoria. Nessuno lo sa. Il compito di cron è avviare il processo, non verificare che abbia avuto successo.

Non è un bug di cron. È così che cron è stato progettato. Cron precede il web. È stato costruito in un’epoca in cui i task scrivevano su file di log e un umano li controllava periodicamente. Quel modello non scala nell’infrastruttura moderna dove uno sviluppatore gestisce decine di attività pianificate su più server.

Quanto ti costano i fallimenti silenziosi di cron

Un fallimento silenzioso del backup significa che lo scopri quando hai bisogno del backup. Forse tre settimane dopo, dopo un incidente di corruzione del database. Il divario tra quando il backup ha smesso di funzionare e quando ne avevi bisogno sono dati che non puoi recuperare.

Un fallimento silenzioso della coda email significa che i clienti smettono di ricevere notifiche. Reimpostazioni password, conferme d’ordine, ricevute di fatturazione. All’inizio nessuno si lamenta perché nessuno sa cosa manca. Quando te ne accorgi, hai migliaia di email non consegnate e utenti confusi.

Un fallimento silenzioso dell’esportazione dati significa che le tue analisi sono sbagliate. Le tue dashboard mostrano tendenze basate su dati obsoleti. Prendi decisioni su informazioni incomplete. L’errore si aggrava più a lungo rimane inosservato.

Perché il monitoraggio dell’uptime non lo rileva

Il tuo monitor dell’uptime dice che il tuo server è attivo. La tua API restituisce 200. La tua dashboard si carica. Secondo il tuo pannello di monitoraggio, tutto va bene.

Ma nessuno di questi controlli ti dice se il backup di ieri notte è stato completato. Non sanno se la tua riconciliazione di fatturazione è stata eseguita. Non sanno se la pipeline di dati che popola le tue analisi ha terminato.

Il monitoraggio dell’uptime risponde alla domanda: «Posso raggiungere questo endpoint?». Il monitoraggio heartbeat risponde a: «Questa attività è stata eseguita?». Sono domande complementari. Hai bisogno di entrambe.

Come funziona il monitoraggio heartbeat

Il monitoraggio heartbeat è semplice. Ogni attività pianificata riceve un URL univoco con un token segreto. Alla fine della tua attività, aggiungi una singola riga che invia un ping a quell’URL:

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Se il ping arriva entro la finestra prevista, il controllo heartbeat viene superato. Se la finestra si chiude senza ping, il monitor attiva un avviso.

Tu configuri l’intervallo previsto. Se il tuo backup viene eseguito ogni 6 ore, imposta l’intervallo a 6 ore. Aggiungi un periodo di tolleranza se la durata dell’attività varia. Un periodo di tolleranza di 10 minuti significa che il monitor non avvisa a meno che il ping non sia in ritardo di 10 minuti.

Questa è l’intera configurazione. Un URL. Un comando curl. Zero file di configurazione.

Configurarlo nella pratica

Ecco una voce cron per un backup notturno del database:

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Il && è importante. Significa: «Esegui curl solo se lo script di backup termina con stato 0 (successo)». Se il backup fallisce, curl non viene mai eseguito. Nessun ping arriva. Ricevi un avviso.

Se vuoi monitorare che lo script sia stato eseguito (anche in caso di fallimento), usa ; invece di && e aggiungi la gestione degli errori all’interno dello script per segnalare lo stato. Ma per la maggior parte dei casi d’uso, && è ciò che desideri. Ti interessa il successo, non solo l’esecuzione.

Cosa monitorare con gli heartbeat

Inizia con i lavori che farebbero più male se fallissero silenziosamente:

Backup del database: Questo è il caso d’uso più comune e quello con il costo di fallimento più elevato. Un backup di cui non sai la mancanza è peggio di nessun backup.

Code di consegna email: Se le tue email transazionali o di marketing smettono di essere inviate, vuoi saperlo in pochi minuti, non in ore.

Fatturazione e generazione fatture: Una fatturazione fallita significa ricavi persi. Un heartbeat sul tuo lavoro di fatturazione lo rileva prima della fine del mese.

Sincronizzazioni ed esportazioni dati: Se la tua pipeline di analisi o la sincronizzazione del data warehouse fallisce, i tuoi report sono sbagliati. Un heartbeat ti avvisa entro l’intervallo previsto.

Rinnovo dei certificati: Se usi certbot o strumenti simili con rinnovo automatico, aggiungi un heartbeat. La scadenza dei certificati è una delle cause più prevenibili di downtime.

Rotazione e pulizia dei log: Se la rotazione dei log fallisce, il tuo disco si riempie. Il tuo server va giù. Un heartbeat rileva il fallimento della rotazione prima che il disco sia pieno.

Monitoraggio heartbeat vs. servizi di monitoraggio cron

Strumenti come Healthchecks.io e Cronitor si concentrano esclusivamente sul monitoraggio di cron e attività pianificate. Lo fanno bene. Alcuni aggiungono funzionalità come il tracciamento della durata dei lavori e le tendenze delle prestazioni.

PingWatchdog include il monitoraggio heartbeat insieme al monitoraggio dell’uptime e al monitoraggio SSL in un’unica piattaforma. Non hai bisogno di uno strumento separato per i cron job. Monitori i tuoi siti web, API, certificati SSL e attività pianificate da un’unica dashboard con un’unica pipeline di avvisi.

Questo è importante perché lo stesso team che monitora l’uptime di solito gestisce i cron job. Consolidare gli strumenti significa meno dashboard da controllare, meno canali di avviso da configurare e meno abbonamenti da gestire.

Confronta PingWatchdog con Healthchecks.io per vedere come il nostro monitoraggio heartbeat si posiziona rispetto al monitoraggio dell’uptime e alle pagine di stato.

Monitoraggio cron in container e Kubernetes

Se esegui cron job all’interno di container Docker o CronJob Kubernetes, lo stesso schema heartbeat funziona. Aggiungi un comando curl alla fine dell’entrypoint del tuo container o del comando del tuo CronJob.

Per Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

Lo stesso principio si applica agli eventi pianificati AWS Lambda, Google Cloud Scheduler, ai timer systemd o a qualsiasi altro scheduler. Se la tua attività può fare una richiesta HTTP, può inviare un heartbeat.

Inizia ora

PingWatchdog include il monitoraggio heartbeat in ogni piano. Il piano gratuito ti dà 3 monitor heartbeat. I piani a pagamento arrivano fino a 25.

Scopri di più sulle funzionalità di monitoraggio heartbeat o configura il tuo primo monitor.