Development #35380
logger les erreurs connector down au deuxième échec
0%
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.
Fichiers
Révisions associées
log errors for down connectors when it persists (#35380)
tests: update for new status check string (#35380)
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
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.
Mis à jour par Thomas Noël il y a plus de 4 ans
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.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
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
Mis à jour par Thomas Noël il y a plus de 4 ans
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.
Mis à jour par Frédéric Péters il y a plus de 4 ans
(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).
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier downtimes-stats.py downtimes-stats.py ajouté
- Fichier downtimes-stats.txt downtimes-stats.txt ajouté
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. »
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
Il faut que j'avance quelques minutes dans le futur pour que ça marche avec sqlite qui va bien trop vite.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
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.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
Voilà avec modifications des vues aussi.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
Et les tests sur les vues backoffice.
Mis à jour par Frédéric Péters il y a plus de 4 ans
Je ferais bien sans le comportement de AvailabilityParametersForm, que ça reste comme ailleurs, en cas d'erreur l'affichage du formulaire en pleine page, avec les erreurs indiquées dedans; on peut se dire qu'il y a mieux à faire mais que ça soit alors considéré de manière globale, pas différent uniquement pour ces options.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
Ok.
Mis à jour par Frédéric Péters il y a plus de 4 ans
Détail, côté langue,
- self.logger.error(u'connector "%s" (%s) is still down %s: %s', + self.logger.error(u'connector "%s" (%s) has been down %s: %s',
Ou "is down since" et la date de début.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Fichier 0001-utils-move-exception_to_text-in-conversion-35380.patch 0001-utils-move-exception_to_text-in-conversion-35380.patch ajouté
- Fichier 0002-log-errors-for-down-connectors-when-it-persists-3538.patch 0002-log-errors-for-down-connectors-when-it-persists-3538.patch ajouté
Ok.
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Go. (et tu peux retirer l'import de parse_notification_delays dans forms.py)
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 3d98363db74c2673f60ff34d3e046a3c0b147900
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Mon Aug 12 18:17:11 2019 +0200
log errors for down connectors when it persists (#35380)
commit 2374fed9d9aa874451bd1e39ed282b1052e14aec
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Mon Aug 12 18:12:10 2019 +0200
utils: move exception_to_text in conversion (#35380)Mis à jour par Frédéric Péters il y a plus de 4 ans
(j'ai poussé modif de chaine dans les tests)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
Mis à jour par Nicolas Roche il y a plus de 4 ans
Il semble manquer la migration du message help_text (#36617)
utils: move exception_to_text in conversion (#35380)