Surveillance des tâches cron

Problème avec les tâches programmées

La caractéristique cruelle des crons, c’est que lorsqu’ils tombent en panne, personne ne te le dit. L’application web continue de servir les requêtes, la page d’accueil semble normale, la surveillance indique que tout va bien – mais quelque part sur le serveur, la sauvegarde nocturne n’a pas démarré depuis deux semaines. Le worker de la queue s’est arrêté après le déploiement et les jobs en attente s’accumulent. La synchronisation horaire perd silencieusement des lignes à cause d’un problème de droits. Tu ne t’en rends compte que lorsque quelque chose en aval finit par tomber – en général au moment où tu en as le plus besoin. L’équipe data veut une exportation, le support une file d’emails, les ops une sauvegarde. À ce moment-là, il est déjà trop tard.

La surveillance de disponibilité standard ne détectera pas cela, parce qu’il n’y a rien à « pinguer ». Un cron n’expose pas d’endpoint HTTP, n’ouvre pas de port, n’active pas de serveur. Il s’exécute, il termine, point. S’il cesse de fonctionner – aucune trace de son absence jusqu’à ce que tu commences à enquêter.

Anti-pattern : la surveillance heartbeat

La surveillance heartbeat (aussi appelée « dead man’s switch » ou « surveillance de cron ») renverse la logique. Au lieu que nous vérifions ton service, c’est ton service qui s’annonce chez nous. Ajoute une ligne dans ton cron – un curl vers un URL unique que nous générons – et cet URL enregistre un timestamp à chaque appel. Nous veillons à l’absence de ces pings. Si l’URL n’est pas appelée dans l’intervalle attendu (plus marge), nous considérons cela comme un cycle loupé et nous envoyons une alerte.

Le modèle est simple, fiable, indépendant du langage. Tout ce qui sait faire une requête HTTP – peut s’intégrer. Bash via curl, Python via requests, Node via fetch, PHP via curl_init, Task Scheduler sur Windows via Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, événements planifiés Lambda – n’importe quoi. Pas de SDK, pas d’agent, pas de démon à installer.

Comment configurer

Dans DiagnoSEO Uptime Monitoring, clique sur « Ajouter un monitor », puis choisis le type « Heartbeat / cron ». L’outil va générer une URL unique avec un jeton – du style https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Définis l’intervalle attendu (la fréquence du job, en minutes) et la marge (à partir de combien de minutes de retard tu veux être alerté). Sauvegarde.

Maintenant, modifie ton cron afin qu’il « ping » l’URL après chaque exécution réussie. Trois styles, selon l’environnement :

# Bash cron - ping seulement en cas de succès
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Ou lorsque le succès partiel est acceptable
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

Dès lors, chaque cycle réussi nous envoie un ping, et nous enregistrons le timestamp. Si nous ne recevons pas de ping dans intervalle + marge minutes, un incident est ouvert et des notifications partent sur tous les canaux activés : Email, Telegram, Slack, Discord, SMS.

Choix de l’intervalle et de la marge

L’intervalle doit correspondre précisément à la planification du job. Sauvegarde nocturne à 3h00 – intervalle 1440 minutes (24 h). Synchronisation horaire – 60. Worker de polling chaque 5 min – 5.

La marge absorbe le jitter naturel. Les crons ne se déclenchent pas à la nanoseconde près – ils sont mis en file, attendent la fin du job précédent, temporisent en cas d’erreur temporaire. Un job de 24 h avec 1 h de marge offre un buffet confortable sans retarder les alertes. Un worker toutes les 5 minutes avec 2 minutes de marge détectera les vraies pannes rapidement, sans faux positifs pour un micro-délai de 30 secondes. En gros : règle la marge à 10 à 50 % de l’intervalle selon le niveau de fluctuation de ton job.

Bonnes pratiques recommandées

• Ping seulement en cas de succès. Utilise && dans bash – un cycle échoué ne pingue pas. Nous détecterons l’absence de ping et enverrons une alerte.
• Ping à chaque itération de boucle. Pour les workers de longue durée, pingue à l’intérieur de la boucle après chaque unité de travail réussie, pas seulement à la fin. Ainsi, un worker suspendu est détecté en cours de job.
• Un heartbeat par job logique, pas par script. Si trois scripts constituent un pipeline nocturne, pingue une fois à la fin de la chaîne. Cela donne un signal propre « le pipeline vit-il ».
• Combine avec les logs. Le heartbeat prouve que le job a démarré. Les logs applicatifs racontent ce qu’il a fait. Ensemble, tu as la vision complète.

Que se passe-t-il si le heartbeat disparaît ?

Un incident est ouvert à l’expiration du délai. Le tableau de bord affiche le monitor en rouge avec l’erreur « Aucun heartbeat reçu depuis X minutes ». Les notifications partent sur tous les canaux que tu as activés. Quand un nouveau heartbeat arrive, le monitor repasse automatiquement en up – il est marqué comme actif, l’incident se ferme, et (si tu as activé les alertes de rétablissement) tu reçois une notification « de retour en ligne ».

Tout cela est traité de la même manière que les autres monitors – heatmap, pourcentage de disponibilité, historique, tags, recherche, export. Du point de vue du tableau de bord, un monitor heartbeat est juste une ligne de plus, triable et filtrable à côté de HTTP, ping, port ou API.

Checklist

Ajouter un monitor → type Heartbeat → copier l’URL générée → ajouter au cron / worker / scheduler → définir intervalle et marge → sauvegarder → c’est prêt. À partir de maintenant, tu sauras en une seconde lorsqu’une tâche planifiée cessera de fonctionner – ce qui, à long terme, est l’une des décisions de surveillance les plus cruciales que tu puisses prendre.

Foire aux questions

• Qu’est-ce que la surveillance heartbeat / cron-job ?

  Surveillance inversée — ta tâche programmée pingue notre URL lorsqu’elle démarre avec succès. Si nous n’en recevons pas dans la fenêtre attendue, nous déclenchons une alerte. Solution au problème des pannes silencieuses : un cron job défaillant ne génère pas d’erreur et ne déclenche pas une alerte de disponibilité classique.

• Comment intégrer une URL heartbeat à mon cron ?

  Ajoute curl -fsS <heartbeat_url> à la fin de la commande cron. Si la commande précédente échoue, curl ne s’exécutera pas et le heartbeat sera omis. Sinon, pingue au début ET à la fin avec des chemins différents — cela donne les signaux « started » et « completed » séparément.

• Quel délai de grâce dois-je configurer ?

  Environ 2 à 3 fois le temps d’exécution moyen de ta tâche. Si ta sauvegarde quotidienne dure 30 minutes, configure la grâce à 90 minutes — cela couvre les ralentissements sans fausses alertes. Pour les tâches au temps d’exécution variable, sois généreux et utilise le dashboard pour repérer les exceptions.

• Puis-je surveiller des cron jobs qui tournent chaque heure ?

  Oui — règle l’intervalle en conséquence (ex. : 60 minutes attendues, 15 minutes de grâce). Le monitor attend un ping au moins tous les 75 minutes. Si ta tâche est plus fréquente (toutes les 5 minutes), l’URL heartbeat le gère aussi — il suffit d’adapter l’intervalle.

• La surveillance heartbeat fonctionne-t-elle avec AWS Lambda / serverless ?

  Oui. Ajoute un appel HTTP sortant vers l’URL heartbeat à la fin de la fonction Lambda. Le monitor traite cela exactement comme un heartbeat de cron : même alerting, même délai de grâce. Utile pour les Lambdas programmées où les alarmes CloudWatch ne captent pas les échecs silencieux.