Django 的日志模块扩展了 Python 内置的 logging。
日志记录是作为 Django 的通用 django.setup() 函数的一部分进行配置的，因此除非明确禁用，否则始终可用。
默认情况下，Django 使用 Python 的 logging.config.dictConfig 格式。
\n完整的默认日志记录条件如下：
\n当 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 中定义如下：
{\n "version": 1,\n "disable_existing_loggers": False,\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n "require_debug_true": {\n "()": "django.utils.log.RequireDebugTrue",\n },\n },\n "formatters": {\n "django.server": {\n "()": "django.utils.log.ServerFormatter",\n "format": "[{server_time}] {message}",\n "style": "{",\n }\n },\n "handlers": {\n "console": {\n "level": "INFO",\n "filters": ["require_debug_true"],\n "class": "logging.StreamHandler",\n },\n "django.server": {\n "level": "INFO",\n "class": "logging.StreamHandler",\n "formatter": "django.server",\n },\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n "loggers": {\n "django": {\n "handlers": ["console", "mail_admins"],\n "level": "INFO",\n },\n "django.server": {\n "handlers": ["django.server"],\n "level": "INFO",\n "propagate": False,\n },\n },\n}\n请参阅 日志模块的配置 了解如何补充或替换此默认日志配置。
\nDjango 提供了许多工具来处理在 Web 服务器环境中的日志记录特定要求。
\nDjango 提供了几种内置的记录器。
\ndjangoLink to this heading#在 django 命名的日志层次结构 中，用于消息的父日志记录器。Django 不使用这个名称发布消息。而是使用以下其中一个日志记录器。
django.requestLink to this heading#记录与处理请求有关的信息。5XX 的响应以 ERROR 消息的形式出现；4XX 的响应以 WARNING 消息的形式出现。记录在 django.security 记录器中的请求不会记录在 django.request 中。
发送给此记录器的消息有以下额外的上下文：
\nstatus_code：与请求相关的 HTTP 响应代码。
request：产生记录信息的请求对象。
django.serverLink to this heading#记录与处理由 runserver 命令调用的服务器收到的请求有关的消息。HTTP 5XX 响应被记录为 ERROR 消息，4XX 响应被记录为 WARNING 消息，其他所有消息被记录为 INFO。
发送给此记录器的消息有以下额外的上下文：
\nstatus_code：与请求相关的 HTTP 响应代码。
request: The request object (a socket.socket) that generated\nthe logging message.
django.templateLink to this heading#记录与模板渲染相关的消息。
\n缺少的上下文变量会被记录为 DEBUG 消息。
django.db.backendsLink to this heading#与代码与数据库互动有关的信息。例如，请求执行的每一条应用程序级别的 SQL 语句都会以 DEBUG 级别记录到这个记录器。
发送给此记录器的消息有以下额外的上下文：
\nduration：执行 SQL 语句所需时间。
sql：所执行的 SQL 语句。
params：SQL 调用中使用的参数。
alias：SQL 调用中使用的数据库的别名。
出于性能考虑，只有当 settings.DEBUG 设置为 True 时，才会启用 SQL 日志记录，而不考虑日志级别或安装的处理程序。
这个日志记录不包括框架级别的初始化（例如 SET TIMEZONE）。如果希望查看所有数据库查询，请在数据库中启用查询日志记录。
django.utils.autoreloadLink to this heading#与 Django 开发服务器执行期间自动代码重新加载相关的日志消息。此记录器在检测到源代码文件的修改时生成 INFO 消息，并在文件系统检查和事件订阅过程中可能生成 WARNING 消息。
django.contrib.authLink to this heading#Log messages related to django.contrib.auth, particularly ERROR\nmessages are generated when a\nPasswordResetForm is successfully submitted\nbut the password reset email cannot be delivered due to a mail sending\nexception.
django.contrib.gisLink to this heading#Log messages related to GeoDjango at various points: during\nthe loading of external GeoSpatial libraries (GEOS, GDAL, etc.) and when\nreporting errors. Each ERROR log record includes the caught exception and\nrelevant contextual data.
django.dispatchLink to this heading#This logger is used in 信号, specifically within the\nSignal class, to report issues when dispatching a\nsignal to a connected receiver. The ERROR log record includes the caught\nexception as exc_info and adds the following extra context:
receiver：接收器的名称。
err：调用接收器时发生的异常。
django.security.*Link to this heading#The security loggers will receive messages on any occurrence of\nSuspiciousOperation and other security-related\nerrors. There is a sub-logger for each subtype of security error, including all\nSuspiciousOperations. The level of the log event depends on where the\nexception is handled. Most occurrences are logged as a warning, while\nany SuspiciousOperation that reaches the WSGI handler will be logged as an\nerror. For example, when an HTTP Host header is included in a request from\na client that does not match ALLOWED_HOSTS, Django will return a 400\nresponse, and an error message will be logged to the\ndjango.security.DisallowedHost logger.
这些日志事件默认会到达 django 日志器，当 DEBUG=False 时，记录器会将错误事件发送给管理员。由于 SuspiciousOperation 导致 400 响应的请求不会被记录到 django.request 记录器，而只会记录到 django.security 记录器。
要使某一特定类型的 SuspiciousOperation 保持沉默，你可以按照以下示例覆盖该特定的记录器：
LOGGING = {\n # ...\n "handlers": {\n "null": {\n "class": "logging.NullHandler",\n },\n },\n "loggers": {\n "django.security.DisallowedHost": {\n "handlers": ["null"],\n "propagate": False,\n },\n },\n # ...\n}\n其他不基于 SuspiciousOperation 的 django.security 记录器是：
django.security.csrf：用于 CSRF 错误。
django.db.backends.schemaLink to this heading#记录 migrations framework 对数据库进行模式变更时执行的 SQL 查询。请注意，它不会记录 RunPython 执行的查询。给这个记录器的消息在其额外的上下文中有 params 和 sql （但与 django.db.backends 不同，不是 duration）。这些值的含义与 django.db.backends 中的解释相同。
django.contrib.sessionsLink to this heading#与 会话框架 相关的日志消息。
\n使用 django.contrib.sessions.backends.cached_db.SessionStore 引擎时发生的非致命错误会记录为 ERROR 消息，并带有相应的回溯。
除了 Python 日志模块提供的处理程序外，Django 还提供了一个日志处理程序。
\n该处理程序对收到的每条日志消息都会向站点 ADMINS 发送一封邮件。
如果日志记录中包含 request 属性，电子邮件中会包含请求的全部细节。如果客户的 IP 地址在 INTERNAL_IPS 设置中，电子邮件主题将包括“内部 IP”；如果没有，则包括“外部 IP”。
如果日志记录中包含堆栈跟踪信息，该堆栈跟踪信息将包含在电子邮件中。
\nAdminEmailHandler 的 include_html 参数用于控制是否在 traceback 邮件中包含一个 HTML 附件，该附件包含了如果 DEBUG 为 True 时会生成的完整调试网页的内容。要在配置中设置此值，将其包含在 django.utils.log.AdminEmailHandler 的处理程序定义中，如下所示：
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n },\n}\n在使用 AdminEmailHandler 时要注意 日志记录的安全性影响。
Email is sent using the default mailer.\nThis can be overridden by setting the using argument of\nAdminEmailHandler, like this:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "using": "internal",\n },\n}\nIf the specified mailer is not configured in the MAILERS\nsetting, no email will be sent and no additional error will be raised.
By setting the deprecated email_backend argument of\nAdminEmailHandler, the email backend that\nis being used by the handler can be overridden. email_backend is not\nsupported when MAILERS is defined or when the using\nargument is provided.
AdminEmailHandler 的 reporter_class 参数允许提供一个 django.view.debug.ExceptionReporter 子类来自定义邮件正文中发送的回溯文本。你提供一个字符串的导入路径到你想使用的类，像这样：
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n "reporter_class": "somepackage.error_reporter.CustomErrorReporter",\n },\n}\n向管理员用户发送邮件。要自定义这个行为，你可以将 AdminEmailHandler 类子类化，并覆盖这个方法。
除了 Python 日志模块提供的日志过滤器外，Django 还提供了一些日志过滤器。
\n这个过滤器接受一个回调函数（它应该接受一个单一的参数，即要记录的记录），并对每个通过过滤器的记录进行调用。如果回调函数返回 False，则不会对该记录进行处理。
\n例如，要从管理员邮件中过滤掉 UnreadablePostError （当用户取消上传时引发），你可以创建一个过滤函数：
from django.http import UnreadablePostError\n\n\ndef skip_unreadable_post(record):\n if record.exc_info:\n exc_type, exc_value = record.exc_info[:2]\n if isinstance(exc_value, UnreadablePostError):\n return False\n return True\n然后将其添加到你的日志记录配置中：
\nLOGGING = {\n # ...\n "filters": {\n "skip_unreadable_posts": {\n "()": "django.utils.log.CallbackFilter",\n "callback": skip_unreadable_post,\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["skip_unreadable_posts"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\n只有当 settings.DEBUG 为 False 时，该过滤器才会传递记录。
\n该过滤器在默认的 logging 配置中使用如下，以确保 AdminEmailHandler 只在 DEBUG 为 False 时向管理员发送错误邮件：
LOGGING = {\n # ...\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\n该过滤器类似于 RequireDebugFalse，但只有当 DEBUG 为 True 时才会传递记录。