使用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,
        #},
    }
}

如果我取消注释注释注释行并调用一个有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

但是,如果这些行保持注释状态,则不会向控制台打印回溯,只是:

[29/Nov/2013 13:33:23] "POST /comment/******/ HTTP/1.0" 500 27

我认为如果没有配置django.request记录器,它将传播到根记录器,后者会将所有内容打印到控制台.

我没有找到任何关于django.request是特别的信息.

为什么它不起作用呢?

Here我读到:

在Django 1.5之前,日志(log)记录设置总是覆盖默认的Django日志(log)记录配置.从Django 1.5开始,可以将项目的日志(log)配置与Django的默认值合并,因此您可以决定是添加还是替换现有配置.

如果日志(log)记录指令Config中的DISABLE_EXISTING_LOGERS键设置为True(默认值),则默认配置将被完全覆盖.或者,您可以通过将DISABLE_EXISTING_LOGERS设置为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'],
        },
    }
}

因此,默认情况下,django.request的值为propagate = False.但在我的情况下,我有'disable_existing_loggers': True个.

推荐答案

解决方案是防止Django配置日志(log)并自行处理.幸运的是,这很容易.settings.py年:

LOGGING_CONFIG = None
LOGGING = {...}  # whatever you want, as you already have

import logging.config
logging.config.dictConfig(LOGGING)

UPDATE ~March 2015:Django 有clarified分他们的documentation分:

如果设置了日志(log)记录指令Config中的DISABLE_EXISTING_LOGERS键 从默认设置为True,则所有记录器 配置将被禁用.禁用的记录器不同于 已删除;记录器仍将存在,但将以静默方式丢弃 任何记录到其中的内容,甚至不会将条目传播到父级 伐木者.因此,您应该非常小心地使用 ‘DISABLE_EXISTING_LOGGERS’:True;这可能不是您想要的. 相反,您可以将DISABLE_EXISTING_LOGERS设置为FALSE并重新定义 部分或全部默认记录器;或者您可以将LOGGING_CONFIG设置为 无,并自己处理日志(log)记录配置.

For posterity and detail:是怎么解释的?我认为念力的大部分可以归结为Django 糟糕的explanation分(满分为disable_existing_loggers),它说当为真时,"默认配置被完全覆盖".在您自己的答案中,您发现这是不正确的;现在发生的情况是,Django已经配置的现有记录器disabled没有被替换.

Python logging documentation更好地解释了这一点(增加了重点):

DISABLE_EXISTING_LOGERS-如果指定为FALSE,则表示存在的记录器 当这个电话打出go 的时候,他们就不会被打扰了.默认值为True,因为 这以向后兼容的方式启用了旧行为.这 行为是指disable个现有的伐木者,除非他们或他们的 祖先在日志(log)记录配置中显式命名.

基于Django文档,我们认为"用我自己的日志(log)配置覆盖默认值,我没有指定的任何东西都将是bubble up".我也被这个期望绊倒了.我们预计的行为大约是replace_existing_loggers(这不是真的).相反,Django 伐木者是shut up人,而不是bubbled up人.

我们首先需要防止设置这些Django记录器,这里Django docs更有帮助:

如果你根本不想配置日志(log)记录(或者你想手动

注意:将LOGGING_CONFIG设置为None只意味着

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)

Django相关问答推荐

在Django中使用Generil.ListView类时,分页不起作用

Django mods.py我想要一个函数转到一个变量

Django REST序列化程序TO_REATION失败

错误``Forbidden (403) CSRF 验证失败.请求中止.``` 当try 登录管理员时

身份验证有效,但登录无效.一直卡在pending

如何删除django请求中的重复项

组织大型 Django 元素的指南

Django 嵌套事务 - with transaction.atomic()

如何在 PyCharm 中重命名 Django 元素?

Django:通过manage.py使用服务器和gunicorn等其他服务器之间的区别.哪个更好?

Django:将原始html(来自数据库)显示为html,而不是呈现

如何将 Django forms.ChoiceField 呈现为 Twitter Bootstrap 下拉菜单

如何在 Django 中向 ModelForm 添加外键字段?

使用 lambda 作为属性的默认值时,Django 1.7.1 Makemigrations 失败

在 Django 应用程序之间共享模型

Django post_save 在不覆盖模型 save() 的情况下防止递归

响应发送到客户端后在 Django 中执行代码

在 django 中获取空查询集的类名

只使用 Django 的某些部分?

Django ModelForm 覆盖小部件