Monitoraggio cron che capisce la tua pianificazione

Il guasto che nessuno nota

Un cron job che va in crash rumorosamente si nota. Un cron job che smette di essere pianificato — la riga di crontab persa in una migrazione del server, il container che non parte più, il worker della coda ucciso dall'OOM killer — non produce errori, né e-mail, né righe di log. Semplicemente non gira mai più, e lo scopri quando qualcuno chiede perché le fatture non sono partite.

Il monitoraggio heartbeat rovescia un controllo HTTP. Invece che okokumo interroghi il tuo servizio, è il tuo job a chiamare un URL di ping univoco dopo ogni esecuzione riuscita. Se la finestra scade, okokumo dà l'allarme — perché l'assenza del segnale è il segnale.

Un periodo, o la riga di crontab stessa

La forma semplice è un periodo più una tolleranza: "aspettati un ping ogni ora, concedi dieci minuti di margine". Funziona finché la pianificazione non è uniforme.

0 3 * * 1-5 — le 3 nei giorni lavorativi — sono 24 ore tra lunedì e martedì e 72 ore tra venerdì e lunedì. Un intervallo fisso non può descriverlo. Impostalo a 24 ore e ti sveglia ogni sabato mattina; impostalo a 72 e un job che si è fermato in silenzio il martedì passa inosservato fino a venerdì.

Per questo un controllo cron può prendere l'espressione crontab stessa, più il fuso orario IANA in cui gira la crontab del tuo server. La scadenza diventa la prossima esecuzione pianificata più la tolleranza, ricalcolata dopo ogni ping. Un job solo infrasettimanale resta silenzioso tutto il weekend, e un'esecuzione saltata il martedì viene colta entro la sua finestra di tolleranza.

Perché il fuso orario è per controllo

Una crontab scatta nell'ora locale del suo host. Un offset UTC fisso slitta di un'ora a ogni cambio dell'ora legale, e slitta verso il falso allarme — le 03:00 a Parigi sono 01:00 UTC in inverno e 02:00 UTC in estate. Ogni controllo porta il proprio fuso, così server in regioni diverse non devono mettersi d'accordo.

Vedi la pianificazione prima di affidarti a essa

Il form elenca le prossime esecuzioni mentre digiti, ciascuna con il suo offset. Un'espressione cron è facile da sbagliare in modo sottile — i campi giorno-del-mese e giorno-della-settimana sono in OR, non in AND, cosa che sorprende quasi tutti una volta — e qui una pianificazione sbagliata significa un avviso mancato, non un difetto estetico.

Come funziona lo scheduler →

Chiamare l'URL di ping

Una richiesta HTTP alla fine del tuo job, da qualunque cosa sia in grado di farne una:

• curl alla fine di uno script di shell o di un entrypoint Docker.
• Un passo finale in una pipeline CI, così un deploy fallito ferma l'heartbeat.
• Una richiesta dal job stesso, dopo che il lavoro è stato salvato e non prima che inizi.

Invia il ping dopo che il lavoro è riuscito, non all'inizio dello script. Un job che parte, fallisce e manda comunque il ping è un job che si dichiara sano mentre non fa nulla.

I limiti del piano valgono per la pianificazione reale

L'intervallo minimo del tuo piano è verificato contro il divario più stretto che l'espressione produce davvero, campionato sulle sue prossime cinquanta occorrenze invece di essere dedotto. Così * * * * * è rifiutato su Free esattamente come un intervallo di 60 secondi, e una pianificazione irregolare non richiede alcun caso speciale.

Le stesse notifiche di tutto il resto

E-mail, Telegram, Slack, Discord o un webhook firmato; instradamento per controllo o predefinito dell'organizzazione; un registro delle consegne che mostra cosa è stato inviato e cosa saltato. Come funzionano le notifiche →