Projet

Général

Profil

Bug #31398

logger même si le connecteur est down

Ajouté par Benjamin Dauvergne il y a 12 jours. Mis à jour il y a 12 jours.

Statut:
Solution proposée
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
13 mar. 2019
Echéance:
% réalisé:

0%

Patch proposed:
Oui

Description

Ne pas envoyer de mail d'erreur je trouve ça bien, ne rien logger c'est peut être un peu trop.

0001-do-not-log-errors-if-the-connector-is-known-to-be-do.patch Voir (1016 octets) Benjamin Dauvergne, 13 mar. 2019 18:43

Historique

#1 Mis à jour par Benjamin Dauvergne il y a 12 jours

  • Assigné à mis à Benjamin Dauvergne

#2 Mis à jour par Benjamin Dauvergne il y a 12 jours

#3 Mis à jour par Frédéric Péters il y a 12 jours

Pas fan de faire ça en modifiant ainsi la priorité parce qu'il me semble que ça va rendre visuellement tout identique, qu'on ne pourra plus distinguer d'un coup d'œil la ligne correspondant à une erreur.

#4 Mis à jour par Benjamin Dauvergne il y a 12 jours

Frédéric Péters a écrit :

Pas fan de faire ça en modifiant ainsi la priorité parce qu'il me semble que ça va rendre visuellement tout identique, qu'on ne pourra plus distinguer d'un coup d'œil la ligne correspondant à une erreur.

Actuellement rien n'est loggé du tout, niveau voir visuellement une erreur ce n'est pas top non plus. Ce que je peux faire c'est les passes en warning et prévoir un code couleur pour les warning, ou bien alors il faut trouver un moyen de désactiver les mails dans ce cas là (mais je n'avais pas envie de retourner au niveau de la configuration des logs python).

#5 Mis à jour par Frédéric Péters il y a 12 jours

Actuellement rien n'est loggé du tout

L'erreur qui a provoqué le passage en down, est logguée, et se trouve tout en haut, facilement visible.

#6 Mis à jour par Frédéric Péters il y a 12 jours

mais je n'avais pas envie de retourner au niveau de la configuration des logs python

Si plus personne ne veut aller à ce niveau, peut-être qu'on devrait juste arrêter et simplement ajouter le code d'envoi d'une trace dans passerelle ?

Mais sans aller jusque-là, ni aller jusqu'à la configuration des logs, je me dis que ce code pourrait peut-être permettre de supprimer l'envoi d'email sans toucher au reste :

--- a/passerelle/base/models.py
+++ b/passerelle/base/models.py
@@ -692,6 +692,8 @@ class ProxyLogger(object):
         logging_parameters = self.connector.logging_parameters
         if logging_parameters.trace_emails:
             admins = [('', x) for x in logging_parameters.trace_emails.splitlines()]
+        if "connector is down":
+            admins = []
         with override_settings(ADMINS=admins):
             getattr(self._logger, levelname.lower())(message, *args, **kwargs)

#7 Mis à jour par Frédéric Péters il y a 12 jours

Mais pour remonter à l'idée même, le déroulé sur lequel on était arrivé était de ne pas flooder les logs de messages quand le connecteur est down mais quand on se décidait à regarder, avoir la possibilité de débrancher le suivi de la disponibilité pour, attentif à ce moment, recevoir des logs, faire le debug.

Si on revient là-dessus j'ai l'impression qu'on peut totalement retirer le code en question (#29965).

#8 Mis à jour par Benjamin Dauvergne il y a 12 jours

Frédéric Péters a écrit :

Mais pour remonter à l'idée même, le déroulé sur lequel on était arrivé était de ne pas flooder les logs de messages quand le connecteur est down mais quand on se décidait à regarder, avoir la possibilité de débrancher le suivi de la disponibilité pour, attentif à ce moment, recevoir des logs, faire le debug.

Si on revient là-dessus j'ai l'impression qu'on peut totalement retirer le code en question (#29965).

Deux choses :
  • mon vrai problème c'est que je n'ai pas vraiment une méthode check_status() qui fonctionne sur mdph13, le truc est trop instable et ne fournit pas une méthode ping qui ferait une vrai validation de fonctionnement de leur coté, j'en suis restreint à choisir un lien et au hasard (le dernier créé) et voir si ça marche; mais je pense pas que ce soit le seul connecteur où check_status est approximatif (il y a tellement de cas d'erreurs possibles qu'on peut avoir un truc down qui répond quand même sur les autres endpoints)
  • je ne savais pas que le choix était ne rien logger pendant un évènement "down" pour obliger à venir plus tard pour débrayer et ainsi avoir des logs ; ça n'est vraiment pas ma pratique où je vais plutôt vouloir voir tout de suite ce qui a pu se passer depuis si ça remarche tout ça; et pour moi ça a surtout été fait pour limiter les mails pas les lignes dans les logs en base (je peux me tromper il faut que je relise les discussions des tickets concernés)

Et donc je vois qu'on a déjà discuté de ça, #28637, mais vraiment je ne suis pas ok avec la conclusion, je préfère un truc qui marche tout seul et fait ce qu'on veut sans intervention.

#9 Mis à jour par Frédéric Péters il y a 12 jours

mon vrai problème c'est que je n'ai pas vraiment une méthode check_status() qui fonctionne sur mdph13,

Je suggérerais alors de retirer le check_status.

Formats disponibles : Atom PDF