Project

General

Profile

Development #28637

Logguer quand même en DB lorsqu'un connecteur est 'down'

Added by Emmanuel Cazenave 10 months ago. Updated 8 months ago.

Status:
Rejeté
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
05 Dec 2018
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No

Description

De #25611 :

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

Hésitation entre ne rien logguer, ou quand même logguer dans la db. Option ici de ne rien logguer quand down.

Je trouve ça peu pratique à l'usage : un connector est down, je voudrais savoir pourquoi, que renvoie l'application sur les check_status.
Aussi le cas d'un connecteur 'down' par que le cron n'a pas tourné mais qui est en fait 'up' et sur lequel on a pas les logs d'activités.

Ces diagnostiques sont rendus difficiles par l'absence de log en DB.


Related issues

Related to Passerelle - Development #29965: Débrayer la vérification de disponibilité d'un connecteur Fermé 22 Jan 2019

History

#1 Updated by Frédéric Péters 10 months ago

Je trouve ça peu pratique à l'usage : un connector est down, je voudrais savoir pourquoi, que renvoie l'application sur les check_status.

Le premier check_status en erreur est normalement loggué, ça fait qu'aller voir les logs d'un connecteur down direct on a l'erreur.

Aussi le cas d'un connecteur 'down' par que le cron n'a pas tourné mais qui est en fait 'up' et sur lequel on a pas les logs d'activités.

Une fenêtre de cinq minutes.

Pour des applications qui sont down de manière trop intermittentes, il vaut sans doute mieux ne pas avoir de suivi de la disponibilité, ou plus fin (genre attendre qu'il y ait succession d'erreurs avant d'enclencher le mode "down").

Je ne suis pas enthousiaste à l'idée de bourriner, et bourrer la db et l'affichage de lignes inutiles, il y a d'autres idées pour être plus fin ?

#2 Updated by Benjamin Dauvergne 10 months ago

On pourrait simplement limiter à un certain nombre de logs par jours une fois que c'est down1; mais je lis aussi dans ce que dit Emmanuel le cas où la raison de l'échec change (genre on passe d'un ConnectionError à une 500 avec une trace), dans ce cas il faudrait peut-être conserver une empreinte de la dernière erreur et comparer2.

1 en pseudocode:

if echec:
    if not already_down:
        log echec
    else:
        if rate('echec', connector, slug) < ratelimit:
            logechec
else:
    if already_down:
        log retour

2


fingerprint = exc.__class__.__name__
if isinstance(exc, HttpError):
    fingerprint += str(exc.response.status_code)
fingerprint = hashlib.md5(force_bytes(fingerprint))

#3 Updated by Emmanuel Cazenave 10 months ago

J'imagine un truc qui dépasse un peu le cadre.

Pourvoir déclencher un test de disponibilité depuis la page d'un connecteur, et pour ce test logguer en dB.
Et tant qu'à rendre disponible cette action, afficher à proximité le statut du connecteur.

#4 Updated by Benjamin Dauvergne 10 months ago

Emmanuel Cazenave a écrit :

J'imagine un truc qui dépasse un peu le cadre.

Pourvoir déclencher un test de disponibilité depuis la page d'un connecteur, et pour ce test logguer en dB.
Et tant qu'à rendre disponible cette action, afficher à proximité le statut du connecteur.

Si on savait faire la différence entre une erreur métier et une erreur technique, je dirai qu'on devrait systématiquement mettre le connecteur en down sur une erreur technique et le remettre up quand une requête passe.

En attendant ton idée ne me parait pas déconnante mais c'est un autre ticket pour moi, vu que ça n'a pas d'impact sur l'implémentation de celui-ci il me semble.

#5 Updated by Emmanuel Cazenave 9 months ago

  • Related to Development #29965: Débrayer la vérification de disponibilité d'un connecteur added

#6 Updated by Emmanuel Cazenave 8 months ago

  • Status changed from Nouveau to Rejeté

Le besoin de base se trouve rempli par #29965 : débrayer le suivi de dispo permet d'obtenir des logs.

Also available in: Atom PDF