Monitoring Spring Boot : @Scheduled et Quartz

Dans une application Spring Boot, les tâches planifiées se multiplient et personne ne tient la liste à jour. Le starter SilenceWatch la tient à votre place : il découvre chaque @Scheduled et chaque job Quartz, les déclare avec leur vraie planification, et signale chaque exécution.

Une dépendance, une clé

<dependency>
  <groupId>com.silencewatch</groupId>
  <artifactId>silencewatch-spring-boot-starter</artifactId>
  <version>0.1.0</version>
</dependency>

silencewatch:
  api-key: ${SILENCEWATCH_API_KEY}

Redémarrez l’application. Chaque méthode @Scheduled et chaque job Quartz apparaît dans SilenceWatch avec sa planification réelle, et envoie un signal autour de chaque exécution, avec sa durée et l’éventuelle exception. Aucun check à créer à la main, aucune URL de ping à copier, rien à resynchroniser quand le code change.

Ce qui le distingue

Il lit les planifications résolues. @Scheduled(cron = "${backup.cron}") est déclaré avec l’expression que la propriété contenait réellement, pas avec le texte du placeholder.
Il donne à chaque job une identité stable (com.acme.jobs.BackupJob#run, ou groupe.job pour Quartz) : l’historique survit aux redémarrages, aux redéploiements et aux renommages.
Il ne supprime jamais rien. Un job qui disparaît du code est marqué orphelin ; l’historique est conservé jusqu’à ce que vous décidiez de le supprimer.
Il distingue les environnements : la même application déclarée en préproduction et en production donne deux checks séparés.

Il ne peut pas vous nuire

Un outil de monitoring qui perturbe la production est pire que pas d’outil. Le starter respecte des règles strictes :

il ne fait jamais échouer votre job : toute erreur est avalée et journalisée en WARN, et votre méthode est appelée une fois, son résultat et son exception passent inchangés ;
il ne bloque jamais votre job : l’envoi passe par une file bornée et un thread daemon de basse priorité ;
il se dégrade en silence : sans clé, sans réseau ou sans serveur, l’application tourne exactement comme sans lui ;
silencewatch.enabled: false supprime tout le mécanisme ;
il n’ajoute aucune dépendance lourde : pas de bibliothèque JSON, donc pas de version de Jackson imposée.

Toutes les propriétés et les limites sont dans la documentation du starter.

Si votre job n’est pas Spring

Rien n’oblige à utiliser le starter : n’importe quel job qui peut faire une requête HTTP peut être surveillé avec l’API de ping. Voir le monitoring de cron et les exemples.

Documentation du starter Code du starter

Questions fréquentes

Comment surveiller les tâches @Scheduled de Spring Boot ?

Ajoutez le starter SilenceWatch et une clé d’API. Au démarrage, il découvre les méthodes @Scheduled, les déclare avec leur planification résolue et envoie un signal autour de chaque exécution.

Le starter surveille-t-il aussi Quartz ?

Oui. Si Quartz est présent, le starter parcourt les jobs et lit leurs déclencheurs ; un job avec plusieurs déclencheurs est déclaré d’après celui qui se déclenche le plus souvent.

Le starter peut-il ralentir ou faire planter mon application ?

Non. Les erreurs réseau sont avalées, l’envoi passe par une file bornée traitée en arrière-plan, et sans clé ou sans réseau l’application tourne comme sans le starter. Il peut être désactivé entièrement avec silencewatch.enabled: false.

Que deviennent les tâches planifiées par programme ?

Les tâches enregistrées par SchedulingConfigurer ou par des lambdas n’ont pas d’identité stable et sont ignorées par le starter : déclarez ces checks à la main ou donnez-leur une méthode @Scheduled.