Development #28637

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

Ajouté par Emmanuel Cazenave il y a 8 jours. Mis à jour il y a 6 jours.

Statut:NouveauDébut:05 déc. 2018
Priorité:NormalEchéance:
Assigné à:-% réalisé:

0%

Catégorie:-
Version cible:-
Patch proposed:Non

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.

Historique

#1 Mis à jour par Frédéric Péters il y a 8 jours

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 Mis à jour par Benjamin Dauvergne il y a 8 jours

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 Mis à jour par Emmanuel Cazenave il y a 6 jours

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 Mis à jour par Benjamin Dauvergne il y a 6 jours

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.

Formats disponibles : Atom PDF