war*_*iuc 33 python django logging
使用Django 1.5.1:
DEBUG = False
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(module)s %(message)s'
},
},
'handlers': {
'console': {
'level': 'DEBUG',
'class': 'logging.StreamHandler',
'formatter': 'verbose',
},
},
'loggers': {
# root logger
'': {
'handlers': ['console'],
},
#'django.request': {
# 'handlers': ['console'],
# 'level': 'DEBUG',
# 'propagate': False,
#},
}
}
Run Code Online (Sandbox Code Playgroud)
如果我取消注释注释行并调用具有的视图1/0,则将回溯打印到控制台:
ERROR 2013-11-29 13:33:23,102 base Internal Server Error: /comment/*******/
Traceback (most recent call last):
...
File "*****/comments/views.py", line 10, in post
1/0
ZeroDivisionError: integer division or modulo by zero
WARNING 2013-11-29 13:33:23,103 csrf Forbidden (CSRF cookie not set.): /comment/******/
[29/Nov/2013 13:33:23] "POST /comment/******/ HTTP/1.0" 500 27
Run Code Online (Sandbox Code Playgroud)
但如果线条保持注释,则不会向控制台打印回溯,只需:
[29/Nov/2013 13:33:23] "POST /comment/******/ HTTP/1.0" 500 27
Run Code Online (Sandbox Code Playgroud)
我想如果django.request没有配置logger,它会传播到根记录器,它会将所有内容打印到控制台.
我没有找到任何django.request特别的信息.
为什么它不起作用?
我在这里读到:
在Django 1.5之前,LOGGING设置总是覆盖默认的Django日志记录配置.从Django 1.5开始,可以将项目的日志记录配置与Django的默认值合并,因此您可以决定是要添加还是替换现有配置.
如果LOGGING dictConfig中的disable_existing_loggers键设置为True(默认值),则完全覆盖默认配置.或者,您可以通过将disable_existing_loggers设置为False来重新定义部分或全部记录器.
在django/utils/log.py:
# Default logging for Django. This sends an email to the site admins on every
# HTTP 500 error. Depending on DEBUG, all other log records are either sent to
# the console (DEBUG=True) or discarded by mean of the NullHandler (DEBUG=False).
DEFAULT_LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse',
},
'require_debug_true': {
'()': 'django.utils.log.RequireDebugTrue',
},
},
'handlers': {
'console':{
'level': 'INFO',
'filters': ['require_debug_true'],
'class': 'logging.StreamHandler',
},
'null': {
'class': 'django.utils.log.NullHandler',
},
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django': {
'handlers': ['console'],
},
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': False,
},
'py.warnings': {
'handlers': ['console'],
},
}
}
Run Code Online (Sandbox Code Playgroud)
所以默认django.request有propagate = False.但就我而言,我有'disable_existing_loggers': True.
JCo*_*ton 74
解决方案是阻止Django配置日志记录并自行处理.幸运的是,这很容易.在settings.py:
LOGGING_CONFIG = None
LOGGING = {...} # whatever you want, as you already have
import logging.config
logging.config.dictConfig(LOGGING)
Run Code Online (Sandbox Code Playgroud)
如果LOGGING dictConfig中的disable_existing_loggers键设置为True,则将禁用默认配置中的所有记录器.已禁用的记录器与已删除的记录器不同; 记录器仍然存在,但会静默地丢弃记录到它的任何内容,甚至不会将条目传播到父记录器.因此,你应该非常小心使用'disable_existing_loggers':True; 它可能不是你想要的.相反,您可以将disable_existing_loggers设置为False并重新定义部分或全部默认记录器; 或者您可以将LOGGING_CONFIG设置为None并自己处理日志配置.
后人和细节:解释?大部分的混乱,我认为归结为Django的差解释的disable_existing_loggers,它说,真时,"默认配置是完全重写".在你自己的回答中,你发现这是不正确的; 发生的事情是Django已经配置的现有记录器被禁用而不被替换.
Python日志文档更好地解释了它(强调添加):
disable_existing_loggers - 如果指定为False,则进行此调用时存在的记录器将保持不变.默认值为True,因为这会以向后兼容的方式启用旧行为.此行为是禁用任何现有记录器,除非在日志记录配置中明确命名它们或它们的祖先.
基于Django文档我们认为,"用我自己的LOGGING配置覆盖默认值,我没有指定的任何内容都会冒出来 ".我也绊倒了这个期望.我们期望的行为与replace_existing_loggers(这不是真实的)一致.相反,Django记录器被关闭而不是冒泡.
我们需要首先阻止这些Django记录器的设置,这里Django 文档更有帮助:
如果您根本不想配置日志记录(或者您希望使用自己的方法手动配置日志记录),则可以将LOGGING_CONFIG设置为None.这将禁用配置过程.
注意:将LOGGING_CONFIG设置为None仅表示配置过程已禁用,而不是自行记录.如果禁用配置过程,Django仍会进行日志记录调用,并回退到定义的任何默认日志记录行为.
Django仍将使用其记录器,但由于配置不处理(然后禁用),这些记录器将按预期冒泡.使用上述设置进行简单测试:
manage.py shell
>>> import logging
>>> logging.warning('root logger')
WARNING 2014-03-11 13:35:08,832 root root logger
>>> l = logging.getLogger('django.request')
>>> l.warning('request logger')
WARNING 2014-03-11 13:38:22,000 django.request request logger
>>> l.propagate, l.disabled
(1, 0)
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
11777 次 |
| 最近记录: |