Django的日志记录模块扩展了Python的内置 logging 。
日志记录被配置为常规Django的一部分 django.setup() 函数,因此除非显式禁用,否则它始终可用。
默认情况下,Django使用Python的 logging.config.dictConfig format 。
完整的默认日志记录条件集包括:
什么时候 DEBUG 是 True :
这个 django 记录器将消息发送到 django 层次结构(除 django.server )) INFO 级别或更高级别到控制台。
什么时候 DEBUG 是 False :
这个 django 记录器将消息发送到 django 层次结构(除 django.server )与 ERROR 或 CRITICAL 标高至 AdminEmailHandler 。
与的价值无关 DEBUG :
这个 django.server 记录器将消息发送到 INFO 级别或更高级别到控制台。
所有伐木者,除 django.server 将日志记录传播到它们的父级,直到根 django 伐木者。这个 console 和 mail_admins 处理程序被附加到根记录器以提供上述行为。
Python自身的默认设置会发送级别记录 WARNING 并更高地连接到控制台。
Django的默认日志记录配置继承了Python的默认配置。它可以通过以下方式获得 django.utils.log.DEFAULT_LOGGING 并在中定义 django/utils/log.py **
{
"version": 1,
"disable_existing_loggers": False,
"filters": {
"require_debug_false": {
"()": "django.utils.log.RequireDebugFalse",
},
"require_debug_true": {
"()": "django.utils.log.RequireDebugTrue",
},
},
"formatters": {
"django.server": {
"()": "django.utils.log.ServerFormatter",
"format": "[{server_time}] {message}",
"style": "{",
}
},
"handlers": {
"console": {
"level": "INFO",
"filters": ["require_debug_true"],
"class": "logging.StreamHandler",
},
"django.server": {
"level": "INFO",
"class": "logging.StreamHandler",
"formatter": "django.server",
},
"mail_admins": {
"level": "ERROR",
"filters": ["require_debug_false"],
"class": "django.utils.log.AdminEmailHandler",
},
},
"loggers": {
"django": {
"handlers": ["console", "mail_admins"],
"level": "INFO",
},
"django.server": {
"handlers": ["django.server"],
"level": "INFO",
"propagate": False,
},
},
}
看见 配置日志记录 有关如何补充或替换此默认日志记录配置的信息。
Django提供了许多实用程序来处理Web服务器环境中的日志记录的特殊要求。
Django提供了几个内置的记录器。
django¶中的消息的父记录器 django named logger hierarchy 。Django不会使用这个名字发布消息。取而代之的是,它使用了下面的一个记录器。
django.request¶记录与请求处理相关的消息。5XX回复被提出为 ERROR 消息;4xx响应引发为 WARNING 留言。记录到 django.security 记录器未登录到 django.request 。
发送到此记录器的消息具有以下额外的上下文:
status_code :与请求关联的HTTP响应代码。
request :生成日志记录消息的请求对象。
django.server¶方法调用的服务器接收到的请求的处理相关的日志消息 runserver 指挥部。HTTP 5XX响应记录为 ERROR 消息,4xx响应记录为 WARNING 消息,其他所有内容都被记录为 INFO 。
发送到此记录器的消息具有以下额外的上下文:
status_code :与请求关联的HTTP响应代码。
request :请求对象(a socket.socket )生成了日志记录消息。
django.template¶记录与模板呈现相关的消息。
缺少的上下文变量记录为 DEBUG 留言。
django.db.backends¶与代码与数据库交互有关的消息。例如,请求执行的每个应用程序级SQL语句都记录在 DEBUG 调平到此记录器。
发送到此记录器的消息具有以下额外的上下文:
duration :执行SQL语句所用的时间。
sql :执行的SQL语句。
params :在SQL调用中使用的参数。
alias :SQL调用中使用的数据库的别名。
出于性能原因,只有在以下情况下才启用SQL日志记录 settings.DEBUG 设置为 True ,而不考虑所安装的日志记录级别或处理程序。
此日志记录不包括框架级别的初始化(例如 SET TIMEZONE )。如果要查看所有数据库查询,请在数据库中打开查询日志记录。
django.utils.autoreload¶Django开发服务器执行期间与自动代码重新加载相关的日志消息。该记录器生成 INFO 在检测到源代码文件中的修改时发送消息,并可能产生 WARNING 文件系统检查和事件订阅过程中的消息。
django.contrib.auth¶记录与以下相关的消息 django.contrib.auth 尤其是 ERROR 当 PasswordResetForm 已成功提交,但由于邮件发送异常,密码重置电子邮件无法发送。
django.contrib.gis¶记录与以下相关的消息 GeoDjango 在各个点:在加载外部GeSpatial库(GEOS、GDAL等)期间以及报告错误时。每个 ERROR 日志记录包括捕获的异常和相关上下文数据。
django.dispatch¶该记录器用于 信号 ,特别是在 Signal 类,用于报告向连接的接收器派遣信号时的问题。的 ERROR 日志记录包括捕获的异常, exc_info 并添加以下额外的上下文:
receiver :接收者的姓名。
err :呼叫接收者时发生的异常。
django.security.*¶安全记录器将收到有关以下任何情况的消息 SuspiciousOperation 以及其他与安全相关的错误。安全错误的每个子类型都有一个子记录器,包括所有 SuspiciousOperation S。日志事件的级别取决于异常处理的位置。大多数事件都被记录为警告,而任何 SuspiciousOperation 到达WSGI处理程序的消息将被记录为错误。例如,当一个HTTP Host 标头包含在来自不匹配的客户端的请求中 ALLOWED_HOSTS ,Django将返回400响应,并将错误消息记录到 django.security.DisallowedHost 伐木者。
这些日志事件将到达 django 记录器默认情况下,它在以下情况下将错误事件通过邮件发送给管理员 DEBUG=False 。请求导致400响应,原因是 SuspiciousOperation 将不会记录到 django.request 记录器,但仅限于 django.security 伐木者。
让特定类型的人安静下来 SuspiciousOperation ,您可以按照以下示例覆盖该特定的记录器::
LOGGING = {
# ...
"handlers": {
"null": {
"class": "logging.NullHandler",
},
},
"loggers": {
"django.security.DisallowedHost": {
"handlers": ["null"],
"propagate": False,
},
},
# ...
}
其他 django.security 记录器不是基于 SuspiciousOperation 包括:
django.security.csrf :适用于 CSRF failures 。
django.db.backends.schema¶对象在数据库架构更改期间执行的SQL查询 migrations framework 。请注意,它不会记录由执行的查询 RunPython 。发送给此记录器的消息具有 params 和 sql 在他们的额外环境中(但不同于 django.db.backends ,而不是持续时间)。这些值的含义与中解释的相同 django.db.backends 。
django.contrib.sessions¶记录与 session framework 。
使用时发生的非致命错误 django.contrib.sessions.backends.cached_db.SessionStore 发动机记录为 ERROR 具有相应追溯的消息。
Django除了提供一个日志处理程序之外 those provided by the Python logging module 。
此处理程序向站点发送电子邮件 ADMINS 对于它收到的每条日志消息。
如果日志记录包含 request 属性,则请求的完整详细信息将包含在电子邮件中。电子邮件主题将包括短语“内部IP”,如果客户的IP地址在 INTERNAL_IPS 设置;如果不是,则包括“外部IP”。
如果日志记录包含堆栈跟踪信息,则该堆栈跟踪将包含在电子邮件中。
这个 include_html 的论点 AdminEmailHandler 用于控制跟踪电子邮件是否包括包含调试网页的完整内容的HTML附件,如果 DEBUG 是 True 。要在配置中设置此值,请将其包含在的处理程序定义中 django.utils.log.AdminEmailHandler ,如下所示:
"handlers": {
"mail_admins": {
"level": "ERROR",
"class": "django.utils.log.AdminEmailHandler",
"include_html": True,
},
}
请注意 security implications of logging 在使用 AdminEmailHandler 。
通过设置 email_backend 的论点 AdminEmailHandler vt.的. email backend 可以重写处理程序正在使用的,如下所示::
"handlers": {
"mail_admins": {
"level": "ERROR",
"class": "django.utils.log.AdminEmailHandler",
"email_backend": "django.core.mail.backends.filebased.EmailBackend",
},
}
默认情况下,电子邮件后端的实例在 EMAIL_BACKEND 将会被使用。
这个 reporter_class 的论点 AdminEmailHandler 允许提供一个 django.views.debug.ExceptionReporter 子类来自定义在电子邮件正文中发送的回溯文本。您可以提供要使用的类的字符串导入路径,如下所示:
"handlers": {
"mail_admins": {
"level": "ERROR",
"class": "django.utils.log.AdminEmailHandler",
"include_html": True,
"reporter_class": "somepackage.error_reporter.CustomErrorReporter",
},
}
向管理员用户发送电子邮件。若要自定义此行为,可以将 AdminEmailHandler 类并重写此方法。
除了由Python日志记录模块提供的那些过滤器之外,Django还提供了一些日志过滤器。
此筛选器接受回调函数(它应接受单个参数,即要记录的记录),并为通过筛选器的每个记录调用它。如果回调返回FALSE,则不会继续处理该记录。
例如,要过滤掉 UnreadablePostError (在用户取消上载时引发),您可以从管理员电子邮件创建一个筛选函数::
from django.http import UnreadablePostError
def skip_unreadable_post(record):
if record.exc_info:
exc_type, exc_value = record.exc_info[:2]
if isinstance(exc_value, UnreadablePostError):
return False
return True
然后将其添加到您的日志记录配置::
LOGGING = {
# ...
"filters": {
"skip_unreadable_posts": {
"()": "django.utils.log.CallbackFilter",
"callback": skip_unreadable_post,
},
},
"handlers": {
"mail_admins": {
"level": "ERROR",
"filters": ["skip_unreadable_posts"],
"class": "django.utils.log.AdminEmailHandler",
},
},
# ...
}
此筛选器仅在settings.DEBUG为FALSE时传递记录。
此筛选器在默认情况下的用法如下 LOGGING 配置以确保 AdminEmailHandler 仅在以下情况下向管理员发送错误电子邮件 DEBUG 是 False **
LOGGING = {
# ...
"filters": {
"require_debug_false": {
"()": "django.utils.log.RequireDebugFalse",
},
},
"handlers": {
"mail_admins": {
"level": "ERROR",
"filters": ["require_debug_false"],
"class": "django.utils.log.AdminEmailHandler",
},
},
# ...
}
此筛选器类似于 RequireDebugFalse ,只是只有在以下情况下才会传递记录 DEBUG 是 True 。
5月 28, 2025