Project

General

Profile

Development #35380

logger les erreurs connector down au deuxième échec

Added by Benjamin Dauvergne 10 days ago. Updated 2 days ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
12 Aug 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Certains services sont très instables, avoir "connector down" par jour pour un downtime de moins de 5 minutes n'est pas bien utile. Aussi on a pas la raison de l'échec dans le mail alors qu'on l'a dans la fonction qui émet le log.

0001-utils-move-exception_to_text-in-conversion-35380.patch View (2.58 KB) Benjamin Dauvergne, 12 Aug 2019 06:46 PM

0002-log-errors-for-down-connectors-when-it-persists-3538.patch View (7.97 KB) Benjamin Dauvergne, 12 Aug 2019 06:46 PM

downtimes-stats.py View (1.45 KB) Benjamin Dauvergne, 13 Aug 2019 01:43 AM

downtimes-stats.txt View (58.7 KB) Benjamin Dauvergne, 13 Aug 2019 01:43 AM

0001-utils-move-exception_to_text-in-conversion-35380.patch View (2.58 KB) Benjamin Dauvergne, 19 Aug 2019 07:42 PM

0002-log-errors-for-down-connectors-when-it-persists-3538.patch View (8.08 KB) Benjamin Dauvergne, 19 Aug 2019 07:42 PM

0001-utils-move-exception_to_text-in-conversion-35380.patch View (2.58 KB) Benjamin Dauvergne, 20 Aug 2019 05:17 PM

0002-log-errors-for-down-connectors-when-it-persists-3538.patch View (14.9 KB) Benjamin Dauvergne, 20 Aug 2019 05:17 PM

0001-utils-move-exception_to_text-in-conversion-35380.patch View (2.58 KB) Benjamin Dauvergne, 20 Aug 2019 06:41 PM

0002-log-errors-for-down-connectors-when-it-persists-3538.patch View (21.2 KB) Benjamin Dauvergne, 20 Aug 2019 06:41 PM

0001-utils-move-exception_to_text-in-conversion-35380.patch View (2.58 KB) Benjamin Dauvergne, 20 Aug 2019 06:53 PM

0002-log-errors-for-down-connectors-when-it-persists-3538.patch View (22.6 KB) Benjamin Dauvergne, 20 Aug 2019 06:53 PM

History

#1 Updated by Benjamin Dauvergne 10 days ago

Je continue à penser que ne rien logger quand c'est down n'est pas forcément une excellente idée non plus, ici ça me force à ajouter un paramètre force à ProxyLogger._log.

#2 Updated by Thomas Noël 10 days ago

Benjamin Dauvergne a écrit :

Certains services sont très instables

FWIW : de mon "analyse", pas mal de services sont souvent down à une certaine heure de la nuit, systématique, genre entre 22 et 23h, ou 3 ou 4h. L'heure des backups, certainement: on ne pourra pas demander du 24/24. Pour ces cas là, l'idéal serait de pouvoir dire que sur telle instance on ne veut pas de log des erreurs entre telle et telle heure, mais que le reste du temps, on veut tout savoir.

#3 Updated by Benjamin Dauvergne 10 days ago

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

Certains services sont très instables

FWIW : de mon "analyse", pas mal de services sont souvent down à une certaine heure de la nuit, systématique, genre entre 22 et 23h, ou 3 ou 4h. L'heure des backups, certainement: on ne pourra pas demander du 24/24. Pour ces cas là, l'idéal serait de pouvoir dire que sur telle instance on ne veut pas de log des erreurs entre telle et telle heure, mais que le reste du temps, on veut tout savoir.

Ce qui est gênant c'est qu'Arpège fait ses backups en pleine journée à 13h40...

Date: Mon, 12 Aug 2019 13:40:42 +0200
Subject: [passerelle.mesdemarches.saint-lo-agglo.fr] ERROR: connector "arpege" (ArpegeECP) is now down

#4 Updated by Thomas Noël 10 days ago

Benjamin Dauvergne a écrit :

Ce qui est gênant c'est qu'Arpège fait ses backups en pleine journée à 13h40...

J'avais pas vu celui-là, mais justement, recevoir ce genre de log tous les jours à 13h40, faudrait pouvoir éviter ; genre de 13h30 à 14h une détection de panne Arpège à Saint Lo ne doit pas nous alerter. Enfin bon bref, de toute façon j'ai pas d'idée pour réaliser ça joliment, c'était surtout pour partager mes points de vues toujours vraiment très très intéressants quand ils ne sont pas passionnants.

#5 Updated by Frédéric Péters 9 days ago

(tant que c'est rouge…)

De mon côté j'aime bien la partie de rappeler que c'est down après un certain temps (mais je serais plutôt pour des écarts plus humains, genre monter jusque 1440 minutes / 1 jour et s'arrêter là), mais j'aime bien aussi que ça puisse se déclencher dès que le connecteur est down, pas dans le vide donner un répit de 5 minutes (qui serait ok pour un, de toute façon trop court pour un autre, et qui fera une réaction trop lente pour certains).

Plutôt que le count_checked, je me demande si on ne pourrait pas avoir un last_notification_timestamp, qui permettrait à peu près la même chose, et qui pourrait facilement se combiner avec un paramétrage du connecteur ("notifier en cas d'indisponibilité supérieure à xx minutes"). (options qui pourrait être étendue plus tard avec des tranches/jours d'exclusions, etc. pour suivre Thomas).

#6 Updated by Benjamin Dauvergne 9 days ago

J'ai pondu quelques chiffres à partir de la prod, on voit quelques régularités mais pas des masses et vraiment étranges, genre le connecteur au cd80 qui tombe régulièrement à 19h25 ou 18h26, peut-être que ça vient de chez nous aussi, genre mise à jour du firewall (je n'ai pas regardé les messages d'erreur il faudrait fouiller, mais bon j'espère qu'on monitore nos services en matière de connectivité TCP au minimum).

Si rien de tout ça ne vient de nous mon avis vraiment perso c'est qu'on s'en fout un peu en vrai de quand des applis tierces tombent, c'est juste pour se couvrir ensuite en disant, oui c'est tombé de telle heure à telle heure, « ah vous monitorez pas vos applications ? ah ben nous oui. »

#7 Updated by Benjamin Dauvergne 3 days ago

Il faut que j'avance quelques minutes dans le futur pour que ça marche avec sqlite qui va bien trop vite.

#8 Updated by Frédéric Péters 2 days ago

Je répète mon commentaire #35380#note-5.

#9 Updated by Benjamin Dauvergne 2 days ago

J'ai suivi les remarques de Fred, ça marche désormais via un champ last_notification_timestamp, et on a sur AvailabilityParameter un champ notification_delays qui est une liste de durée en minutes. Par défaut c'est '0', c'est le comportement actuel.

Si on met 0,5,100 on sera notifié au premier check down, puis ensuite après 5 minutes, puis 100 minutes, puis toutes les 100 minutes.

Si on met 5,100 c'est pareil sauf qu'on ne sera pas notifié au premier downtime.

Also available in: Atom PDF