Monitoring de jobs : alerte quand un job s’arrête

Vos jobs ne vous préviennent pas quand ils s’arrêtent. Le monitoring de jobs répond à une question simple : mon job a-t-il tourné quand il devait, et s’est-il bien terminé ? SilenceWatch y répond pour tout job capable d’envoyer une requête HTTP.

Qu’est-ce que le monitoring de jobs ?

Un job est une tâche qui s’exécute sans que personne la lance : une sauvegarde, un export, un traitement de facturation, un import, une purge, un batch, un worker périodique. On parle aussi de tâche planifiée, de batch ou de cron — le cron n’est qu’une façon de planifier un job parmi d’autres, d’où le monitoring de cron comme cas particulier. Le monitoring de jobs (on dit aussi supervision ou surveillance de jobs) vérifie que chacun s’exécute à l’heure prévue, dans un temps normal et avec succès, et alerte sinon.

Ce qu’on surveille vraiment dans un job

Trois choses, et chacune échoue différemment :

• La présence. Le job a-t-il démarré à l’heure prévue ? C’est la panne la plus sournoise, parce qu’elle ne produit aucune erreur : un ordonnanceur arrêté, une planification supprimée, un conteneur qui ne se lance plus.
• Le résultat. S’est-il terminé avec succès ? Un job qui part mais plante doit pouvoir le dire tout de suite, avec son code de sortie.
• La durée. Prend-il le temps habituel ? Un traitement qui double de durée annonce souvent un problème avant qu’il ne s’arrête.

Pourquoi les autres surveillances ne suffisent pas

Ce que vous avez	Ce qu’il voit	Ce qu’il rate
Alertes sur les journaux	Les erreurs écrites	Un job qui ne s’exécute pas n’écrit rien
Supervision de disponibilité (uptime)	Qu’un service répond	Qu’un job planifié tourne
APM / traces	Le comportement d’un code qui s’exécute	L’absence d’exécution
Heartbeat (SilenceWatch)	L’arrivée, ou l’absence, d’un signal à l’heure prévue	Le contenu du travail (il faut un signal d’échec explicite)

Ces outils sont complémentaires. Le heartbeat comble ce qu’aucun des autres ne voit : l’absence.

Comment SilenceWatch surveille un job

Chaque job appelle une URL de ping, à la fin de son exécution et, si vous le souhaitez, au début (pour mesurer la durée) et en cas d’échec :

GET|POST /p/<clé>          l’exécution a réussi
GET|POST /p/<clé>/start    l’exécution commence
GET|POST /p/<clé>/fail     l’exécution a échoué
GET|POST /p/<clé>/<code>   code de sortie (0 réussit)

Vous déclarez la fréquence attendue (intervalle ou expression cron, avec fuseau horaire) et un délai de grâce. Passé l’échéance, le check est en retard ; une fois le délai de grâce écoulé, il est en panne, un incident s’ouvre et vos canaux sont alertés (e-mail, webhook, Slack, Microsoft Teams, Discord). Le détail est dans les états d’un check.

Quels jobs surveiller

• Les sauvegardes de bases de données et de fichiers.
• Les imports et exports de données, les traitements ETL, les synchronisations.
• Les traitements de facturation, les relances, les envois en masse.
• Les purges, les rotations, les renouvellements de certificats.
• Les tâches @Scheduled et les jobs Quartz d’une application Spring Boot, découverts automatiquement.
• Les crons d’un serveur, d’un conteneur ou d’un CronJob Kubernetes.

Pour des files de messages ou des traitements à la demande, un heartbeat périodique ne convient pas : SilenceWatch surveille des jobs qui doivent tourner à intervalle régulier.

Choisir un outil de monitoring de jobs

Quelques questions utiles, quel que soit l’outil :

1. Détecte-t-il l’absence ? C’est le cœur du sujet : un outil qui ne regarde que les erreurs ne voit pas un job qui ne se lance plus.
2. Comprend-il vos planifications ? Expressions cron, fuseaux horaires, changements d’heure, délai de grâce.
3. Mesure-t-il la durée et distingue-t-il l’échec du retard ?
4. Alerte-t-il là où vous êtes, et peut-on tester un canal avant l’incident ?
5. S’intègre-t-il sans effort ? Une requête HTTP pour un script ; une dépendance pour une application Java.
6. Où tournent vos données ? Un service hébergé, ou un outil auto-hébergeable sans version bridée.

Surveiller mes jobsVoir l’API de ping

Questions fréquentes

Qu’est-ce que le monitoring de jobs ?

C’est la surveillance de l’exécution de vos jobs et tâches planifiées : on vérifie que chacun s’exécute à l’heure prévue, dans un temps normal et avec succès, et on alerte sinon. Les crons en font partie.

Comment surveiller un job qui ne plante pas mais ne se lance plus ?

Avec un heartbeat : le job envoie un signal à chaque exécution, et SilenceWatch vous alerte si le signal n’arrive pas dans le délai prévu. C’est le seul moyen de détecter une absence, puisqu’un job qui ne tourne pas ne produit aucune erreur.

Quelle différence entre monitoring de jobs et monitoring de logs ?

Le monitoring de logs détecte les erreurs écrites. Le monitoring de jobs par heartbeat détecte qu’un job ne s’est pas exécuté du tout, ce qu’un journal ne peut pas montrer puisqu’un job absent n’écrit rien.

Peut-on mesurer la durée d’un job ?

Oui. Le job appelle /start au début puis l’URL de résultat à la fin ; SilenceWatch mesure l’intervalle, ou vous pouvez transmettre vous-même une durée avec le paramètre duration_ms.

Comment être alerté quand un job échoue sans attendre l’échéance ?

Faites appeler /fail, ou l’URL avec un code de sortie non nul, quand le job échoue : le check passe en panne tout de suite, sans attendre la fin du délai de grâce.

SilenceWatch convient-il aux jobs Java ?

Oui, avec un starter Spring Boot qui découvre automatiquement les tâches @Scheduled et les jobs Quartz et envoie les signaux à votre place.

Voir aussi

• Monitoring de cron
• Monitoring Spring Boot
• Surveiller une sauvegarde
• Surveiller un CronJob Kubernetes
• Dead man’s switch
• Auto-hébergement