Project

General

Profile

Development #29149

Revoir le fonctionnement des logs de debug

Added by Frédéric Péters 11 months ago. Updated about 2 months ago.

Status:
Solution proposée
Priority:
Normal
Category:
-
Target version:
-
Start date:
17 Dec 2018
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Parce que ça s'adresse au développeur qui devrait lire ça sur son terminal, pas à un fichier de log qui va se remplir sans lecteur.

(peut-être à réaffecter à hobo pour modifier la configuration exposée dans le packaging)

PS: ancien nom "ne pas logguer de manière persistante le niveau "debug""

0001-set-syslog-handlers-to-level-INFO-29149.patch View (1.04 KB) Emmanuel Cazenave, 18 Dec 2018 10:36 AM

0001-matomo-adapt-translations-32940.patch View (3.56 KB) Benjamin Dauvergne, 16 May 2019 05:46 PM

0002-agent-adapt-to-authentic2-spring-cleaning-33120.patch View (1.86 KB) Benjamin Dauvergne, 16 May 2019 05:46 PM

0001-debian-add-debug-log-in-var-log-app-debug-29149.patch View (5.56 KB) Benjamin Dauvergne, 24 May 2019 11:07 AM

0002-debian-add-InternalIpMiddleware-29149.patch View (2.48 KB) Benjamin Dauvergne, 24 May 2019 11:07 AM

0001-debian-add-debug-log-in-var-log-app-debug-29149.patch View (6.29 KB) Benjamin Dauvergne, 19 Jun 2019 09:56 AM

0002-debian-add-InternalIpMiddleware-29149.patch View (2.48 KB) Benjamin Dauvergne, 19 Jun 2019 09:56 AM

0001-debian-add-debug-log-in-var-log-app-debug-29149.patch View (6.29 KB) Benjamin Dauvergne, 19 Sep 2019 06:08 PM

0002-debian-add-InternalIpMiddleware-29149.patch View (2.48 KB) Benjamin Dauvergne, 19 Sep 2019 06:08 PM


Related issues

Related to Publik - Autre #29234: variables non définies utilisées dans les templates django ? Solution déployée 20 Dec 2018
Related to Hobo - Development #29240: Avoir un écran pour gérer le paramétrage de debug Solution déployée 20 Dec 2018

History

#2 Updated by Emmanuel Cazenave 11 months ago

Pas sur que ça suffise, compliqué à tester chez moi, mais à mon sens ça peut pas faire de mal.

#3 Updated by Emmanuel Cazenave 11 months ago

J'ai été un peu vite, ça viendrait contrarier ce qui a été mis en place dans #7906.

#4 Updated by Benjamin Dauvergne 11 months ago

On pourrait très bien remplacer tout ce que j'ai fait dans #7906 par le filtre django.utils.log.RequireDebugTrue sur un handler spécial "debug".

#5 Updated by Frédéric Péters 11 months ago

  • Related to Autre #29234: variables non définies utilisées dans les templates django ? added

#6 Updated by Thomas Noël 11 months ago

Juste pour clarifier ce qui est attendu, du moins par moi: actuellement quand on a DEBUG=True, on se retrouve avec les log de niveau debug, mais ça ne devrait pas être lié. DEBUG=True devrait rester uniquement dans son rôle d'afficher des traces à l'écran (et autres messages par ci par là), mais les log devraient rester en mode INFO par défaut. On aurait à trouver un autre settings (genre settings.LOG_LEVEL ?) pour permettre de forcer le niveau de log sur un tenant particulier, via son settings.json, pendant une phase de diagnostic.

#7 Updated by Benjamin Dauvergne 11 months ago

Thomas Noël a écrit :

Juste pour clarifier ce qui est attendu, du moins par moi: actuellement quand on a DEBUG=True, on se retrouve avec les log de niveau debug, mais ça ne devrait pas être lié. DEBUG=True devrait rester uniquement dans son rôle d'afficher des traces à l'écran (et autres messages par ci par là), mais les log devraient rester en mode INFO par défaut. On aurait à trouver un autre settings (genre settings.LOG_LEVEL ?) pour permettre de forcer le niveau de log sur un tenant particulier, via son settings.json, pendant une phase de diagnostic.

Je pense qu'on peut tout faire avec un filtre comme dit plus haut, on peut imaginer un filtre DebugLog gérait par un setting DEBUG_LOG:
  • DEBUG_LOG=False : le filtre bloque tout ce qui est au niveau DEBUG ou moins
  • DEBUG_LOG=True : le filtre laisse passer tout ce qui est au niveau DEBUG ou moins
  • DEBUG_LOG="authentic2" : le filtre laisse passer tous ce qui est au niveau DEBUG ou moins pour les domaines "authentic2.*"
  • DEBUG_LOG="authentic2,django" : le filtre laisse passer tous ce qui est au niveau DEBUG ou moins pour les domaines "authentic2*" ou "django.*"

Pour reprendre des remarques récentes de Fred ça pourrait utilement être géré depuis hobo via un écran dédié.

#8 Updated by Benjamin Dauvergne 11 months ago

Quand à DEBUG=True, je serai assez pour avoir un setting DEBUG_IP="<ip1> <ip2>", idem géré par hobo (je clique sur activate debug et ça ajoute mon ip cliente dans le truc), et avoir un middleware qui quand il voit l'IP pose DEBUG=True pour la durée de la requête.

Bon je vais faire des tickets au lieu de tout polluer.

Pour revenir au ticket, Emmanuel ce que tu modifies n'a pas d'effet sur le code de #7906, juste qu'il ne servira à rien si il n'y a plus aucun handler de niveau DEBUG, alors go si tu veux (mais les gens vous ne verrez plus les logs de debug pendant un moment).

#9 Updated by Benjamin Dauvergne 9 months ago

  • Assignee set to Benjamin Dauvergne
  • Status changed from Solution proposée to En cours
  • Description updated (diff)
  • Subject changed from ne pas logguer de manière persistante le niveau "debug" to Revois le fonctionnement des logs de debug

#10 Updated by Benjamin Dauvergne 9 months ago

  • Subject changed from Revois le fonctionnement des logs de debug to Revoir le fonctionnement des logs de debug
Nouveau plan :
  • effectivement remonter le niveau à INFO sur syslog,journal,etc...
  • supprimer toutes les bidouilles de loglevel, créer un OnlyDebug qui se base sur DEBUG_LOG
  • coté front hobo avoir une checkbox pour activer DEBUG_LOG
  • middleware pour avoir un DEBUG_IP
  • coté front hobo avoir un champ pour activer DEBUG_IP
  • pour chaque brique logger dans /var/log/brique/debug avec un TimedRotatingFileHandler utilisant le filtre OnlyDebug avec une rotation journalière sur 7 jours (je me dis que ça évitera de prévoir cela au niveau logrotate), ça pas super multiprocess proof mais si on perd une ligne de debug de temps en temps je ne pense pas que ce soit trop grave

#11 Updated by Benjamin Dauvergne 9 months ago

Renommage de DEBUG_IP en INTERNAL_IPS ce qui nous donne le supporte de django-debug-toolbar au passage.

#12 Updated by Benjamin Dauvergne 7 months ago

  • Related to Development #29240: Avoir un écran pour gérer le paramétrage de debug added

#13 Updated by Benjamin Dauvergne 6 months ago

Première implémentation.

Reste à faire des tests pour InternalIPMiddleware.

Cela va de de paire avec les écrans de #29240, le cas DEBUG_LOG='app1,app2' n'est pas gérable via ces écrans.

#14 Updated by Benjamin Dauvergne 6 months ago

Mauvais commits dans mon dernier commentaire. Branche basé sur #29240.

0001: les logs de debug ne partent plus vers syslog/journald mais vers /var/log/<app>/debug, c'est activé via DEBUG_LOG = True ou DEBUG_LOG=app1,app2
0002: INTERNAL_IPS = (ip1, ip2), active DEBUG = True pour les IPs indiquées

#16 Updated by Benjamin Dauvergne about 2 months ago

Rebasé suite au push de #29240, j'ai juste un doute sur InternalIPMiddleware, j'ai un peu peur que DEBUG reste à True en cas d'exception; je ne vois pas vraiment comment faire mieux sans les middleware moderne de Django 1.11 basés sur une fonction recevant un get_response() en paramètre.

#17 Updated by Benjamin Dauvergne about 2 months ago

Benjamin Dauvergne a écrit :

Rebasé suite au push de #29240, j'ai juste un doute sur InternalIPMiddleware, j'ai un peu peur que DEBUG reste à True en cas d'exception; je ne vois pas vraiment comment faire mieux sans les middleware moderne de Django 1.11 basés sur une fonction recevant un get_response() en paramètre.

Non en fait ça devrait aller process_response() est toujours appelé.

Also available in: Atom PDF