Intégration
Monitoring Python Django : django-celery-beat
Dans un projet Python Django, la planification vit souvent en base : quelqu’un ajoute une tâche périodique dans l’admin, et personne ne met à jour une liste de surveillance. La bibliothèque SilenceWatch lit les tâches périodiques de django-celery-beat, les déclare avec leur vraie planification, et signale chaque exécution.
Un paquet, une clé
Section intitulée « Un paquet, une clé »pip install "silencewatch[django-celery-beat]"export SILENCEWATCH_API_KEY=sw_...from silencewatch.integrations.celery import instrument
instrument(app)Rien d’autre à écrire. Quand django_celery_beat est dans INSTALLED_APPS, le même instrument(app) que pour Celery lit aussi les tâches périodiques actives de la base, crontab (avec son propre fuseau horaire) et intervalle, à côté du beat_schedule. Redémarrez les workers : chaque tâche apparaît dans SilenceWatch avec sa vraie planification, et envoie un signal autour de chaque exécution, avec sa durée et ses échecs.
Ce qui le distingue
Section intitulée « Ce qui le distingue »- Une modification faite pendant que les workers tournent est prise en compte. Ajoutez, modifiez ou désactivez une tâche périodique dans l’admin Django, ou en code : elle est redéclarée dans la minute, et ses exécutions sont signalées dès lors, sans redémarrage.
- Il lit les vraies planifications, un crontab dans le fuseau horaire qu’il déclare, un intervalle comme sa période.
- Il donne à chaque tâche une identité stable (
celery:shop.tasks.backup, le nom de la tâche) : l’historique survit aux redémarrages, au renommage de l’entrée et aux redéploiements. - Il ne supprime jamais rien. Une tâche supprimée ou désactivée est marquée orpheline ; l’historique est gardé jusqu’à ce que vous le supprimiez.
- C’est l’intégration Celery. Les règles, les réglages et les signaux sont les mêmes : un projet avec un
beat_scheduleet des entrées en base a un seul check par tâche.
Il ne peut pas vous nuire
Section intitulée « Il ne peut pas vous nuire »- il ne fait jamais échouer votre tâche : toute erreur est avalée et journalisée en
WARNING, et votre tâche s’exécute une fois, son résultat et son exception passant sans changement ; - il ne bloque jamais : l’envoi passe par une file bornée et un thread démon, et la seule requête qui guette les changements lit une ligne ;
- il se dégrade en silence : sans clé, sans réseau ou sans serveur, les workers tournent exactement comme sans lui ;
SILENCEWATCH_ENABLED=falsesupprime tout le mécanisme ;- il n’a aucune dépendance propre :
celeryetdjango-celery-beatsont ceux que vous avez déjà.
Tous les réglages et limites sont dans la documentation de la bibliothèque.
Questions fréquentes
Section intitulée « Questions fréquentes »Comment surveiller les tâches django-celery-beat ?
Installez le paquet silencewatch avec l’extra django-celery-beat, définissez une clé d’API et appelez instrument(app) sur votre application Celery. Quand django_celery_beat est une application installée, ses tâches périodiques actives sont déclarées à côté du beat_schedule, sans autre configuration.
Que se passe-t-il si j’ajoute une tâche périodique dans l’admin pendant que les workers tournent ?
Chaque processus worker regarde le marqueur de changement propre à django-celery-beat une fois par minute, et ne redéclare la planification que s’il a bougé. La nouvelle tâche est signalée sans redémarrage.
Quelles tâches périodiques ne sont pas surveillées ?
Les tâches ponctuelles et à date fixe s’exécutent une fois et ne sont pas une planification à surveiller, et les tâches désactivées sont laissées de côté ; si elles avaient été déclarées, elles sont marquées orphelines. Une tâche présente à la fois dans le beat_schedule et en base forme un seul check.
Cela fonctionne-t-il avec Django seul, sans Celery ?
Non : la bibliothèque lit la planification que Celery beat exécute. Une commande de gestion Django lancée par cron peut être surveillée avec l’API de ping.