Surveiller les tâches récurrentes

[yaf]

On n'a toujours pas mis en place d'alerting pour les jobs récurrents, ca serait tres rassurant parce que delayed job n'inspire pas confiance

1. reminders
2. file attente
3. plage ouvertures cached

pour 1. je pensais mettre https://www.rdv-solidarites.fr/health_checks/rdv_events_stats.json?min_mails=15&min_sms=40 dans updown.io mais on ne peut pas definir un seul check par jour, la recurrence minimale est toutes les heures. c'est une verification indirecte que le job a tourné car ca verifie seulement que certains mails ont été envoyés, pas specifiquement des reminders.

Il me semble que le plus simple et maintenable serait de faire une seule route commune de health checks pour les jobs recurrents genre /health_checks/recurring_jobs_result.json qui renvoie une 400/500 si certaines conditions ne sont pas remplies.

si on ne stocke rien de plus qu'aujourd'hui il faudrait faire des checks sur les resultats indirects de ces jobs :

1. que des sms/mails de file d'attente aient été envoyés
2. que des sms/mails de reminder aient été envoyés
3. que des plages d'ouvertures aient ete marqués comme expirées.

Il faudrait bien considerer la date d'aujourd'hui ou d'hier en fonction de l'heure courante vs l'heure du job recurrent (updown va demander a 4h du matin si des reminders ont été envoyés, il faut continuer a repondre en fonction des reminders envoyés la veille).

Il faut potentiellement toujours repondre 200 le weekend aussi

On pourrait aussi imaginer de stocker plus de data : que chaque job recurrent stocke son resultat dans une table recurring_jobs_result par ex avec une date et un json de resultats eventuels. c'est peut etre overkill.

[github-actions[bot]]

Stale issue message

[yaf]

Je vais fermer cette issue. Nous avons déjà évoqué le fait de basculer vers Sidekiq, pourquoi garder celle-ci ?

[adipasquale]

arf celle-ci me parait relativement importante et distincte du passage à sidekiq pour l'instant si le job ne se déclenche pas, on ne le saura pas tant que quelqu'un ne nous en alerte pas, ce qui est assez inquiétant :/

[yaf]

On peut la re-ouvrir si tu préfères... J'avais l'impression que c'était un palliatif à sidekiq... Autant mettre sidekiq directement non ?

[adipasquale]

ce n'est pas vraiment lié à la migration à Sidekiq non. Il s'agit de vérifier que les jobs importants ont bien tourné de manière extérieure, indépendante de la taskqueue, peu importe qu'elle soit delayed job ou sidekiq.

Passer à sidekiq me rassurerait un peu sur la fiabilité de la taskqueue mais ça n'enleverait pas le besoin de ce genre de monitoring à mon avis

[yaf]

Est-ce que ce ticket pourrait être le premier pas faire une nouvelle zone super admin ? Ou bien backtech ou je ne sais quel nom lui donner ?

Voir une autre application ? Est-ce qu'on pourrait monitorer les jobs depuis une autre application ?

[n-b]

Il y a en fait plusieurs sujets:

• monitorer les échecs d’envoi de sms ou de mail. Pour netsize, les jobs échouent, pour sendinblue, c’est complètement invisible ici.
• suivre les crash de jobs. A priori, tout ne remonte pas dans sentry.

[n-b]

En ce qui concerne les erreurs sentry qui ne remonte pas, voir https://github.com/getsentry/sentry-ruby/pull/1180: ActiveJob::DeserializationError est ignoré par défaut, jusqu’à la version 4.2.0 de sentry-ruby. (Il faut qu’on bundle-update, dès que #1362 est corrigé.)

[github-actions[bot]]

Stale issue message

[yaf]

Je vais fermer ce ticket... Je pense qu'il est trop gros, trop général... Et n'a rien à faire dans le tableau des priorisations référentes aussi.