Surveillance des tâches Cron avec signaux de vie : un tutoriel pratique

Les tâches Cron qui s'exécutent avec succès sont faciles. Les tâches Cron qui échouent bruyamment sont aussi faciles : l'e-mail d'erreur arrive dans votre boîte de réception. Les difficiles sont les tâches Cron qui s'arrêtent complètement. Le serveur redémarre, le conteneur est supprimé, le compte utilisateur est désactivé, la minuterie systemd a été masquée par un changement de configuration. La tâche ne s'exécute jamais, aucune erreur n'est produite, et vous le découvrez trois semaines plus tard quand les sauvegardes que vous pensiez se faire ont disparu. La surveillance par signal de vie capture exactement ce mode de défaillance.

Comment fonctionne la surveillance par signal de vie

Un moniteur de signal de vie inverse la relation de sonde normale. Au lieu qu'une sonde externe appelle votre service, votre tâche appelle le moniteur. Vous définissez une fenêtre de grâce (par ex. « cette tâche devrait faire un ping chaque heure, accordez-lui cinq minutes de marge »). Quand le moniteur cesse d'entendre des pings, il ouvre un événement de temps d'arrêt et vous alerte.

Le résultat est un système d'arrêt automatique en absence de signal (dead-man's-switch). Tant que la tâche s'exécute et signale le succès, le moniteur reste silencieux. Au moment où elle échoue à faire un ping (parce qu'elle s'est écrasée, parce que le serveur est éteint, parce que quelqu'un a désactivé la minuterie), l'alerte se déclenche. Trois semaines d'échec silencieux de sauvegarde deviennent un incident de cinq minutes.

Quand utiliser les signaux de vie versus les vérifications régulières

Les signaux de vie ne sont pas un remplacement pour la surveillance HTTP. Ils couvrent une classe différente de tâche : tout ce qui s'exécute en arrière-plan selon un calendrier.

• Tâches de sauvegarde : vidages nocturnes, synchronisation S3, rsync hors site.
• Exécutions de pipeline de données : tâches ETL, génération de rapports quotidiens, réconciliation de facturation.
• E-mails marketing selon un calendrier : lettre d'information hebdomadaire, campagnes progressives.
• Tâches de renouvellement SSL : certbot, acme.sh.
• Tout ce qui s'exécute dans cron, les minuteries systemd, les calendriers GitHub Actions, les crons Cloudflare Workers ou AWS EventBridge.

Comment ajouter un signal de vie à une tâche Cron avec bash

Le motif le plus simple est un seul appel curl à la fin de votre script. L'URL du signal de vie est unique au moniteur ; ne la mettez pas dans le contrôle de version.

Un motif qui gère les défaillances gracieusement : `do_the_work && curl -fsS --retry 3 https://your-monitor.example/heartbeat`. Le && active le heartbeat uniquement si le travail réel a réussi. Le --retry 3 gère les problèmes réseau transitoires. Le -fsS rend curl silencieux en cas de succès et bruyant en cas d'échec, ce que cron souhaite.

Heartbeats depuis Python et Node

Le même motif dans deux langages courants. Les deux enveloppent le travail dans un try/except, et ne signalent la réussite que sur une exécution correcte.

• Python : `try: do_the_work(); requests.post('https://your-monitor.example/heartbeat', timeout=10); except Exception: logger.exception('job failed')`
• Node : `try { await doTheWork(); await fetch('https://your-monitor.example/heartbeat', { method: 'POST' }); } catch (err) { console.error('job failed', err); }`
• Important : n'envoyez pas le heartbeat dans un bloc finally. Finally s'exécute à la fois en cas de succès et d'échec. Vous voulez que le heartbeat soit un signal positif, pas un signal d'exécution.

Configuration de la fenêtre de grâce

La fenêtre de grâce est le réglage le plus souvent mal configuré. Trop courte et vous obtenez de fausses alertes quand le travail s'exécute quelques secondes en retard. Trop longue et une défaillance réelle passe inaperçue pendant des heures.

Une bonne règle de base est 2x la durée normale du travail plus 5 minutes. Une sauvegarde nocturne qui prend normalement 8 minutes veut une fenêtre de grâce de 8 * 2 + 5 = 21 minutes. Un travail hebdomadaire qui prend 2 heures veut une fenêtre de grâce de 2 * 2 + 0.5 = 4.5 heures. La fenêtre de grâce vous protège des variations inoffensives, pas des défaillances réelles.

Motifs heartbeat courants à configurer en premier

Si vous partez de zéro, trois heartbeats capturent la plupart des défaillances silencieuses qui pourraient vous affecter. Un moniteur de sauvegarde nocturne avec une fenêtre de grâce de 6 heures. Un moniteur de renouvellement SSL sur la tâche cron qui exécute certbot ou acme.sh, avec une fenêtre de grâce d'une semaine. Un moniteur de rapport quotidien ou de réconciliation de facturation avec une fenêtre de grâce de 90 minutes. Ensemble, ces trois moniteurs capturent les modes de défaillance qui ont les exécutions les plus longues et les conséquences les plus graves. Une fois que ceux-ci sont en place, ajoutez un heartbeat à chaque autre travail programmé au fil du temps.