Votre tâche appelle une URL quand elle a fini. Le silence au-delà de son échéance est une panne — et si vous donnez la ligne de crontab à okokumo, l'échéance suit le vrai planning au lieu d'un intervalle fixe.
Une tâche cron qui plante bruyamment se remarque. Une tâche cron qui cesse d'être planifiée — l'entrée de crontab perdue dans une migration de serveur, le conteneur qui ne démarre plus, le worker tué par l'OOM killer — ne produit aucune erreur, aucun e-mail, aucune ligne de log. Elle ne s'exécute simplement plus, et vous l'apprenez quand quelqu'un demande pourquoi les factures ne sont pas parties.
La supervision par heartbeat inverse la sonde HTTP. Au lieu qu'okokumo interroge votre service, votre tâche appelle une URL de ping unique après chaque exécution réussie. Passé le délai, okokumo donne l'alerte : ici, l'absence de signal est le signal.
La forme simple est une période et un délai de grâce : « attends un ping toutes les heures, tolère dix minutes de retard ». Cela marche jusqu'à ce que le planning ne soit plus uniforme.
0 3 * * 1-5 — 3 h du matin en semaine — c'est 24 heures entre lundi et mardi et
72 heures entre vendredi et lundi. Aucun intervalle fixe ne décrit cela : réglé
sur 24 heures, il vous réveille chaque samedi matin ; réglé sur 72, une tâche
silencieusement arrêtée le mardi passe inaperçue jusqu'au vendredi.
Une sonde cron peut donc prendre l'expression crontab elle-même, plus le fuseau IANA dans lequel la crontab de votre serveur s'exécute. L'échéance devient la prochaine exécution planifiée plus le délai de grâce, recalculée après chaque ping. Une tâche qui ne tourne qu'en semaine reste silencieuse tout le week-end, et un mardi manqué est détecté dans sa propre fenêtre de grâce.
Une crontab se déclenche à l'heure locale de sa machine. Un décalage UTC fixe dérive d'une heure à chaque changement d'heure, et il dérive vers la fausse alerte — 3 h à Paris, c'est 1 h UTC en hiver et 2 h UTC en été. Chaque sonde porte son propre fuseau, pour que des serveurs dans des régions différentes n'aient pas à se mettre d'accord.
Le formulaire liste les prochaines exécutions à mesure que vous tapez, avec le décalage de chacune. Une expression cron est facile à se tromper subtilement — les champs jour-du-mois et jour-de-la-semaine sont combinés par OU, pas par ET, ce qui surprend presque tout le monde une fois — et ici un mauvais planning signifie une alerte manquée, pas un défaut cosmétique.
Comment fonctionne l'ordonnanceur →
Une requête HTTP à la fin de votre tâche, depuis n'importe quoi capable d'en émettre une :
curl en fin de script shell ou de point d'entrée Docker.Pingez après la réussite, pas en haut du script. Une tâche qui démarre, échoue, et ping quand même est une tâche qui se déclare en bonne santé sans rien faire.
L'intervalle minimum de votre formule est vérifié contre l'écart le plus court
que l'expression produit réellement, échantillonné sur ses cinquante
prochaines occurrences plutôt que déduit. Ainsi * * * * * est refusé sur la
formule gratuite exactement comme un intervalle de 60 secondes, et un planning
irrégulier ne demande aucun cas particulier.
E-mail, Telegram, Slack, Discord ou webhook signé ; routage par sonde ou canal par défaut de l'organisation ; un journal de livraison indiquant ce qui a été envoyé et ce qui a été ignoré. Comment fonctionnent les alertes →