Project

General

Profile

Développement #96745

ajouter un système d'alerte par mail lors d'une indisponibilité

Added by Thomas Noël about 2 months ago. Updated 16 days ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
12 October 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

A l'instar de ce qu'on a dans les options de journalisation, avoir dans les options de suivi de disponibilité :
  • une textarea pour poser la liste des destinataires à qui envoyer mails en cas d'indispo (et en cas de retour après indispo)
  • une input pour indiquer les plages de dispo prévues, genre 2-23 pour dire de n'envoyer ces infos qu'entre 2h et 23h (dans le cas d'un logiciel qui est rebouté chaque nuit, c'est si typique)

À chaque indisponibilité, on envoie un mail :

Subject: indisponibilité de SSS détectée par passerelle.domaine.fr

Ceci est une alerte émise par https://passerelle.domaine.fr

Le système utilisé par le connecteur « connecteur -- slug » a été détecté comme indisponible à partir de HH:MM:SS le JJ/MM/AAAA.

Pour en avoir plus : https://passerelle/apps/slug/#open:downtimes  <-- on n'envoie pas de trace dans le mail, pour ne diffuser aucune info, on ne sait jamais

Lors du retour aussi, avec un petit recap du genre "le système a été vu comme indisponible entre dateheure et dateheure".


Related issues

Related to Passerelle - Développement #95478: Ne pas remonter les logs "métier" vers le système de logging djangoSolution déployée17 September 2024

Actions

Associated revisions

Revision ca88fc84 (diff)
Added by Gael Pasgrimaud 17 days ago

base: only send email when a resource is down (#96745)

Revision 1e8f9f2f (diff)
Added by Gael Pasgrimaud 17 days ago

base: no longer use noreply@ as trace_emails (#96745)

Revision f3e3c459 (diff)
Added by Gael Pasgrimaud 17 days ago

base: ProxyLogger no longer send traces to ADMINS (#96745)

History

#1

Updated by Frédéric Péters about 2 months ago

Cela remplacerait l'alerte par email qui existe déjà,

Subject: [passerelle.etc.] ERROR: connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
To: ...

connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

Report connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

(...)

i.e. dans passerelle/base/models.py set_availability_status remplacer les appels au système de logging par des emails explicites.

une input pour indiquer les plages de dispo prévues, genre 2-23 pour dire de n'envoyer ces infos qu'entre 2h et 23h (dans le cas d'un logiciel qui est rebouté chaque nuit, c'est si typique)

Dans le système actuel il y a également possibilité de configurations de délais (pour par exemple s'éviter les notifications pour les "micro-coupures") et de répétitions (notification_delays).

#2

Updated by Frédéric Péters about 2 months ago

  • Related to Développement #95478: Ne pas remonter les logs "métier" vers le système de logging django added
#3

Updated by Gael Pasgrimaud about 2 months ago

  • Assignee set to Gael Pasgrimaud
#4

Updated by Robot Gitea about 2 months ago

  • Status changed from Nouveau to En cours

Gael Pasgrimaud (gpasgrimaud) a ouvert une pull request sur Gitea concernant cette demande :

#5

Updated by Gael Pasgrimaud about 2 months ago

J'ai un début de proposition mais aussi quelques doutes.

En fait la configuration des délais fonctionne ainsi. Quand un connecteur devient "down":

- soit on a "0", valeur par défaut, et la notification est envoyée une fois immédiatement puis plus jamais

- soit on a une valeur autre type "10" ou "0,5,10" et la notification est envoyée régulièrement (la suite de la liste est calculée en fonction du dernier delai: "10,20,30,40..." / "0,5,10,20,30,40...")

Je trouve le cas particulier 0 un peu surprenant. A la place je proposerai bien que:

- soit on a un unique délai indiqué "5" / "10" et une notification est envoyée une unique fois après ce délai. Voir peut-être mettre 5 par défaut, qui est l'intervalle entre deux cron et éviterai les notif en cas de "micro" coupure.

- soit on a une liste de valeurs et le comportement reste celui actuelle

Aussi, j'ai considéré que maintenant qu'on a un affichage des donwtimes dans l'UI on a plus besoin d'ajouter des ResourceLog qui indique seulement "c'est down depuis {duration}". C'est discutable et je suis preneur d'éventuelles contradictions.

#6

Updated by Benjamin Dauvergne about 2 months ago

Gael Pasgrimaud a écrit :

- soit on a un unique délai indiqué "5" / "10" et une notification est envoyée une unique fois après ce délai. Voir peut-être mettre 5 par défaut, qui est l'intervalle entre deux cron et éviterai les notif en cas de "micro" coupure.

Ça ne me dérangerait pas qu'on aille vers ça avec un délai par défaut de 1 minute, le cron tournant moins vite que on aura par défaut une alerte si deux check d'affilé échouent, et pour adapter les configurations actuelles prendre la dernière valeur ?

Aussi, j'ai considéré que maintenant qu'on a un affichage des donwtimes dans l'UI on a plus besoin d'ajouter des ResourceLog qui indique seulement "c'est down depuis {duration}".

D'accord avec ça.

#7

Updated by Gael Pasgrimaud about 2 months ago

Benjamin Dauvergne a écrit :

et pour adapter les configurations actuelles prendre la dernière valeur ?

Je ne vois pas ce que tu veux dire. Pour moi il n'y a rien à adapter. Si la configuration est à "0", ça marche. Si c'est problématique, ça se change à la main. Si c'est autre chose que 0, c'est très bien aussi.

Je zappe un truc ?

#8

Updated by Gael Pasgrimaud about 1 month ago

J'ai fini par comprendre ce que tu voulais dire (si on a 5, générer 5,10,..). Mais je serai pour ne pas le faire.

De ce que je vois il n'y a que deux connecteurs qui utilise une seule valeur différente de 0 en prod:

- sur passerelle_eservices_toulouse_metropole_fr un délai est à 60

- sur passerelle_mesdemarches_labaule_fr un délai est à 1. Du coup ils (ou on) se prennent un paquet de notif ?

Il suffirait de changer ces deux valeurs (rajouter ,XX) pour que ça reste conforme au fonctionnement actuel

Et je continue de penser que de permettre de n'avoir qu'une notif quand on le désir, c'est pas mal. La majorité des cas semble être à 0 (voir ne pas envoyer de notifs du tout)

Aussi, en faisant cette recherche, j'ai repéré un tenant qui ne semble pas avoir la table. Je trouve ça louche: ERROR: relation "passerelle_mesdemarches_departement06_fr.base_availabilityparameters" does not exist

#9

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée
#11

Updated by Benjamin Dauvergne 23 days ago

Gael Pasgrimaud a écrit :

Aussi, en faisant cette recherche, j'ai repéré un tenant qui ne semble pas avoir la table. Je trouve ça louche: ERROR: relation "passerelle_mesdemarches_departement06_fr.base_availabilityparameters" does not exist

C'est une instance obsolète, l'instance est maintenant sur le SaaS HDS et s'appelle passerelle_mesdemarches06_fr.

#13

Updated by Robot Gitea 23 days ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#14

Updated by Robot Gitea 19 days ago

  • Status changed from Solution validée to En cours

Gael Pasgrimaud (gpasgrimaud) a commencé à travailler sur une pull request sur Gitea concernant cette demande :

#15

Updated by Robot Gitea 19 days ago

  • Status changed from En cours to Solution proposée
#16

Updated by Robot Gitea 17 days ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#17

Updated by Robot Gitea 17 days ago

  • Status changed from Solution validée to Résolu (à déployer)

Gael Pasgrimaud (gpasgrimaud) a mergé une pull request sur Gitea concernant cette demande :

#18

Updated by Transition automatique 16 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF