ロギングLink to this heading
Django's logging module extends Python's builtin logging.
Logging is configured as part of the general Django django.setup()
function, so it's always available unless explicitly disabled.
Django のデフォルトのロギング設定Link to this heading
By default, Django uses Python's logging.config.dictConfig format.
Default logging conditionsLink to this heading
The full set of default logging conditions are:
DEBUG が 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
parents, up to the root django logger. The console and mail_admins
handlers are attached to the root logger to provide the behavior described
above.
Python's own defaults send records of level WARNING and higher
to the console.
Default logging definitionLink to this heading
Django's default logging configuration inherits Python's defaults. It's
available as django.utils.log.DEFAULT_LOGGING and defined in
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,
},
}
}
See ロギングを設定する on how to complement or replace this default logging configuration.
Django logging extensionsLink to this heading
Django provides a number of utilities to handle the particular requirements of logging in a web server environment.
ロガーLink to this heading
Django provides several built-in loggers.
djangoLink to this heading
The parent logger for messages in the django named logger hierarchy. Django does not post messages using this name.
Instead, it uses one of the loggers below.
django.requestLink to this heading
リクエストに関するログをハンドリングします。5XXレスポンスは ERROR メッセージとして送られ、 4XXレスポンスは WARNING メッセージとして送られます。 django.security ロガーに出力されたメッセージは、 django.request ロガーには送られません。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
status_code: リクエストに対するレスポンスのHTTPレスポンスコード。request: ログのメッセージに対応するリクエストのオブジェクト。
django.serverLink to this heading
runserver コマンドによって立ち上がったサーバーが受け取ったリクエストに関するログメッセージ。HTTP の 5XX レスポンスは ERROR メッセージとして送られ、 4XX レスポンスは WARNING メッセージとして送られ、その他は INFO メッセージとして送られます。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
status_code: リクエストに対するレスポンスのHTTPレスポンスコード。request: ログのメッセージに対応するリクエストのオブジェクト。
django.templateLink to this heading
テンプレートのレンダリングに関するログメッセージ。
コンテキストに変数が無い場合は DEBUG メッセージとして送られる。
django.db.backendsLink to this heading
コードとデータベースの間でのやりとりに関するメッセージ。例えば、アプリケーションから実行全ての SQL は DEBUG レベルでメッセージが送られます。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
duration: SQLを実行するのにかかった時間。sql: 実行されたSQL文。params: SQLの呼び出しに使ったパラメータ。alias: The alias of the database used in the SQL call.
パフォーマンスの観点から、 SQL ログは、ログレベルやハンドラに関わらず、 settings.DEBUG に True が設定されているときのみ有効になります。
このログには、フレームワークによる初期化(例: SET TIMEZONE )や、トランザクション管理のクエリ(例: BEGIN, BOMMIT, ROLLBACK)は含まれません。全てのデータベースクエリを見たい場合は、データベースのクエリログを有効にしてください。
django.security.*Link to this heading
The security loggers will receive messages on any occurrence of
SuspiciousOperation and other security-related
errors. There is a sub-logger for each subtype of security error, including all
SuspiciousOperations. The level of the log event depends on where the
exception is handled. Most occurrences are logged as a warning, while
any SuspiciousOperation that reaches the WSGI handler will be logged as an
error. For example, when an HTTP Host header is included in a request from
a client that does not match ALLOWED_HOSTS, Django will return a 400
response, and an error message will be logged to the
django.security.DisallowedHost logger.
These log events will reach the django logger by default, which mails error
events to admins when DEBUG=False. Requests resulting in a 400 response due
to a SuspiciousOperation will not be logged to the django.request
logger, but only to the django.security logger.
To silence a particular type of SuspiciousOperation, you can override that
specific logger following this example:
'handlers': {
'null': {
'class': 'logging.NullHandler',
},
},
'loggers': {
'django.security.DisallowedHost': {
'handlers': ['null'],
'propagate': False,
},
},
Other 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
the migrations framework. Note that it won't log the
queries executed by RunPython.
Messages to this logger have params and sql in their extra context (but
unlike django.db.backends, not duration). The values have the same meaning
as explained in django.db.backends.
ハンドラLink to this heading
Django provides one log handler in addition to those provided by the
Python logging module.
- class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)Link to this definition
This handler sends an email to the site
ADMINSfor each log message it receives.If the log record contains a
requestattribute, the full details of the request will be included in the email. The email subject will include the phrase "internal IP" if the client's IP address is in theINTERNAL_IPSsetting; if not, it will include "EXTERNAL IP".If the log record contains stack trace information, that stack trace will be included in the email.
The
include_htmlargument ofAdminEmailHandleris used to control whether the traceback email includes an HTML attachment containing the full content of the debug web page that would have been produced ifDEBUGwereTrue. To set this value in your configuration, include it in the handler definition fordjango.utils.log.AdminEmailHandler, like this:'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'include_html': True, }, },Be aware of the security implications of logging when using the
AdminEmailHandler.By setting the
email_backendargument ofAdminEmailHandler, the email backend that is being used by the handler can be overridden, like this:'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'email_backend': 'django.core.mail.backends.filebased.EmailBackend', }, },By default, an instance of the email backend specified in
EMAIL_BACKENDwill be used.The
reporter_classargument ofAdminEmailHandlerallows providing andjango.views.debug.ExceptionReportersubclass to customize the traceback text sent in the email body. You provide a string import path to the class you wish to use, like this:'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'include_html': True, 'reporter_class': 'somepackage.error_reporter.CustomErrorReporter', }, },- send_mail(subject, message, *args, **kwargs)Link to this definition
Sends emails to admin users. To customize this behavior, you can subclass the
AdminEmailHandlerclass and override this method.
フィルターLink to this heading
Django provides some log filters in addition to those provided by the Python logging module.
- class CallbackFilter(callback)Link to this definition
This filter accepts a callback function (which should accept a single argument, the record to be logged), and calls it for each record that passes through the filter. Handling of that record will not proceed if the callback returns False.
For instance, to filter out
UnreadablePostError(raised when a user cancels an upload) from the admin emails, you would create a filter function: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 Trueand then add it to your logging config:
'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', }, },
- class RequireDebugFalseLink to this definition
This filter will only pass on records when settings.DEBUG is False.
This filter is used as follows in the default
LOGGINGconfiguration to ensure that theAdminEmailHandleronly sends error emails to admins whenDEBUGisFalse:'filters': { 'require_debug_false': { '()': 'django.utils.log.RequireDebugFalse', }, }, 'handlers': { 'mail_admins': { 'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler', }, },
- class RequireDebugTrueLink to this definition
This filter is similar to
RequireDebugFalse, except that records are passed only whenDEBUGisTrue.