Django's logging module extends Python's builtin logging.
Logging is configured as part of the general Django django.setup()\nfunction, so it's always available unless explicitly disabled.
By default, Django uses Python's logging.config.dictConfig format.
\nThe full set of default logging conditions are:
\nDEBUG が True のとき:
django ロガーは、django ヒエラルキー (django.server を除く) において、INFO レベル以上のメッセージをコンソールに送信します。
DEBUG が False のとき:
django ロガーは、django ヒエラルキー (django.server を除く) において、ERROR ないし CRITICAL レベルを AdminEmailHandler に送信します。
Independently of the value of DEBUG:
django.server ロガーは INFO レベル以上のメッセージをコンソールに送信します。
All loggers except django.server propagate logging to their\nparents, up to the root django logger. The console and mail_admins\nhandlers are attached to the root logger to provide the behavior described\nabove.
Python's own defaults send records of level WARNING and higher\nto the console.
Django's default logging configuration inherits Python's defaults. It's\navailable as django.utils.log.DEFAULT_LOGGING and defined in\ndjango/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}\nSee ロギングを設定する on how to complement or replace this default\nlogging configuration.
\nDjango provides a number of utilities to handle the particular requirements of\nlogging in a web server environment.
\nDjango provides several built-in loggers.
\ndjangoLink to this heading#The parent logger for messages in the django named logger hierarchy. Django does not post messages using this name.\nInstead, it uses one of the loggers below.
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 the logging message.
django.templateLink to this heading#テンプレートのレンダリングに関するログメッセージ。
\nコンテキストに変数が無い場合は DEBUG メッセージとして送られる。
django.db.backendsLink to this heading#コードとデータベースの間でのやりとりに関するメッセージ。例えば、アプリケーションから実行全ての SQL は DEBUG レベルでメッセージが送られます。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
\nduration: SQLを実行するのにかかった時間。
sql: 実行されたSQL文。
params: SQLの呼び出しに使ったパラメータ。
alias: The alias of the database used in the SQL call.
パフォーマンスの観点から、 SQL ログは、ログレベルやハンドラに関わらず、 settings.DEBUG に True が設定されているときのみ有効になります。
This logging does not include framework-level initialization (e.g.\nSET TIMEZONE). Turn on query logging in your database if you wish to view\nall database queries.
django.contrib.authLink to this heading#Log messages related to django.contrib.auth, particularly ERROR messages\nare generated when a PasswordResetForm is\nsuccessfully submitted but the password reset email cannot be delivered due to\na mail sending exception.
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.
These log events will reach the django logger by default, which mails error\nevents to admins when DEBUG=False. Requests resulting in a 400 response due\nto a SuspiciousOperation will not be logged to the django.request\nlogger, but only to the django.security logger.
To silence a particular type of SuspiciousOperation, you can override that\nspecific logger following this example:
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}\nOther django.security loggers not based on SuspiciousOperation are:
django.security.csrf: For CSRF failures.
django.db.backends.schemaLink to this heading#Logs the SQL queries that are executed during schema changes to the database by\nthe migrations framework. Note that it won't log the\nqueries executed by RunPython.\nMessages to this logger have params and sql in their extra context (but\nunlike django.db.backends, not duration). The values have the same meaning\nas explained in django.db.backends.
Django provides one log handler in addition to those provided by the\nPython logging module.
This handler sends an email to the site ADMINS for each log\nmessage it receives.
If the log record contains a request attribute, the full details\nof the request will be included in the email. The email subject will\ninclude the phrase "internal IP" if the client's IP address is in the\nINTERNAL_IPS setting; if not, it will include "EXTERNAL IP".
If the log record contains stack trace information, that stack\ntrace will be included in the email.
\nThe include_html argument of AdminEmailHandler is used to\ncontrol whether the traceback email includes an HTML attachment\ncontaining the full content of the debug web page that would have been\nproduced if DEBUG were True. To set this value in your\nconfiguration, include it in the handler definition for\ndjango.utils.log.AdminEmailHandler, like this:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n },\n}\nBe aware of the security implications of logging when using the AdminEmailHandler.
By setting the email_backend argument of AdminEmailHandler, the\nemail backend that is being used by the\nhandler can be overridden, like this:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "email_backend": "django.core.mail.backends.filebased.EmailBackend",\n },\n}\nBy default, an instance of the email backend specified in\nEMAIL_BACKEND will be used.
The reporter_class argument of AdminEmailHandler allows providing\nan django.views.debug.ExceptionReporter subclass to customize the\ntraceback text sent in the email body. You provide a string import path to\nthe class you wish to use, like this:
"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}\nSends emails to admin users. To customize this behavior, you can\nsubclass the AdminEmailHandler class and\noverride this method.
Django provides some log filters in addition to those provided by the Python\nlogging module.
\nThis filter accepts a callback function (which should accept a single\nargument, the record to be logged), and calls it for each record that\npasses through the filter. Handling of that record will not proceed if the\ncallback returns False.
\nFor instance, to filter out UnreadablePostError\n(raised when a user cancels an upload) from the admin emails, you would\ncreate a filter function:
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\nand then add it to your logging config:
\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}\nThis filter will only pass on records when settings.DEBUG is False.
\nThis filter is used as follows in the default LOGGING\nconfiguration to ensure that the AdminEmailHandler only sends\nerror emails to admins when DEBUG is 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}\nThis filter is similar to RequireDebugFalse, except that records are\npassed only when DEBUG is True.