Project

General

Profile

Bug #31398

logger même si le connecteur est down

Added by Benjamin Dauvergne 6 months ago. Updated 5 months ago.

Status:
Rejeté
Priority:
Normal
Target version:
-
Start date:
13 Mar 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

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 View (1016 Bytes) Benjamin Dauvergne, 13 Mar 2019 06:43 PM

History

#1 Updated by Benjamin Dauvergne 6 months ago

  • Assignee set to Benjamin Dauvergne

#2 Updated by Benjamin Dauvergne 6 months ago

#3 Updated by Frédéric Péters 6 months ago

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 Updated by Benjamin Dauvergne 6 months ago

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 Updated by Frédéric Péters 6 months ago

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 Updated by Frédéric Péters 6 months ago

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 Updated by Frédéric Péters 6 months ago

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 Updated by Benjamin Dauvergne 6 months ago

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 Updated by Frédéric Péters 6 months ago

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.

#10 Updated by Benjamin Dauvergne 5 months ago

  • Status changed from Solution proposée to Rejeté

On est pas arrivé à un consensus et j'ai juste retiré mon check_status() sur mdph13; si quelqu'un est embêté par ce comportement il ré-ouvrira un ticket.

Also available in: Atom PDF