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:
\nWhen DEBUG is True:
The django logger sends messages in the django hierarchy (except\ndjango.server) at the INFO level or higher to the console.
When DEBUG is False:
The django logger sends messages in the django hierarchy (except\ndjango.server) with ERROR or CRITICAL level to\nAdminEmailHandler.
Independently of the value of DEBUG:
The django.server logger sends messages at the INFO level\nor higher to the console.
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 Configuring logging 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#Log messages related to the handling of requests. 5XX responses are\nraised as ERROR messages; 4XX responses are raised as WARNING\nmessages. Requests that are logged to the django.security logger aren’t\nlogged to django.request.
Messages to this logger have the following extra context:
\nstatus_code: The HTTP response code associated with the request.
request: The request object that generated the logging message.
django.serverLink to this heading#Log messages related to the handling of requests received by the server invoked\nby the runserver command. HTTP 5XX responses are logged as ERROR\nmessages, 4XX responses are logged as WARNING messages, and everything else\nis logged as INFO.
Messages to this logger have the following extra context:
\nstatus_code: The HTTP response code associated with the request.
request: The request object (a socket.socket) that generated the logging message.
django.templateLink to this heading#Log messages related to the rendering of templates.
\nMissing context variables are logged as DEBUG messages.
django.db.backendsLink to this heading#Messages relating to the interaction of code with the database. For example,\nevery application-level SQL statement executed by a request is logged at the\nDEBUG level to this logger.
Messages to this logger have the following extra context:
\nduration: The time taken to execute the SQL statement.
sql: The SQL statement that was executed.
params: The parameters that were used in the SQL call.
alias: The alias of the database used in the SQL call.
For performance reasons, SQL logging is only enabled when\nsettings.DEBUG is set to True, regardless of the logging\nlevel or handlers that are installed.
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.utils.autoreloadLink to this heading#Log messages related to automatic code reloading during the execution of the\nDjango development server. This logger generates an INFO message upon\ndetecting a modification in a source code file and may produce WARNING\nmessages during filesystem inspection and event subscription processes.
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.contrib.gisLink to this heading#Log messages related to GeoDjango at various points: during the\nloading of external GeoSpatial libraries (GEOS, GDAL, etc.) and when reporting\nerrors. Each ERROR log record includes the caught exception and relevant\ncontextual data.
django.dispatchLink to this heading#This logger is used in Signals, 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: The name of the receiver.
err: The exception that occurred when calling the receiver.
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.contrib.sessionsLink to this heading#Log messages related to the session framework.
\nNon-fatal errors occurring when using the\ndjango.contrib.sessions.backends.cached_db.SessionStore engine are\nlogged as ERROR messages with the corresponding traceback.
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.