Ведение журнала
Модуль ведения журнала Django расширяет встроенный модуль Python logging.
Ведение журнала настраивается как часть общей функции Django django.setup(), поэтому оно всегда доступно, если его явно не отключить.
Конфигурация ведения журнала Django по умолчанию
По умолчанию Django использует формат logging.config.dictConfig из Python.
Условия ведения журнала по умолчанию
Полный набор условий ведения журнала по умолчанию:
Если 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
Django предоставляет ряд утилит для обработки специфических требований к ведению журнала в среде веб-сервера.
Логгеры
Django предоставляет несколько встроенных логгеров.
django
Родительский логгер для сообщений в иерархии именованных логгеров django. 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: объект запроса (объектsocket.socket), вызвавший появление сообщения в журнале.
django.template
Сообщения журнала, связанные с отображением шаблонов.
- Отсутствующие переменные контекста регистрируются как сообщения
DEBUG.
django.db.backends
Сообщения, связанные с взаимодействием кода с базой данных. Например, каждый SQL-оператор уровня приложения, выполненный в рамках запроса, записывается в этот логгер на уровне DEBUG.
Сообщения этого логгера содержат следующие дополнительные данные:
-
duration: время, затраченное на выполнение SQL-оператора. -
sql: выполненный SQL-оператор. -
params: параметры, использованные при вызове SQL. -
alias: псевдоним базы данных, использованной при вызове SQL.
Из соображений производительности ведение журнала SQL включается только при значении True настройки settings.DEBUG, независимо от уровня ведения журнала и установленных обработчиков.
В этот журнал не попадает инициализация на уровне фреймворка (например, SET TIMEZONE). Чтобы просматривать все запросы к базе данных, включите ведение журнала запросов в самой базе данных.
django.utils.autoreload
Сообщения журнала, связанные с автоматической перезагрузкой кода во время работы сервера разработки Django. Этот логгер создаёт сообщение INFO при обнаружении изменений в файле исходного кода и может создавать сообщения WARNING при сканировании файловой системы и подписке на события.
django.contrib.auth
Сообщения журнала, связанные с django.contrib.auth. В частности, сообщения ERROR создаются, если форма PasswordResetForm успешно отправлена, но письмо для сброса пароля не удалось доставить из-за ошибки отправки почты.
django.contrib.gis
Сообщения журнала, связанные с GeoDjango на разных этапах: при загрузке внешних геопространственных библиотек (GEOS, GDAL и т. д.) и при сообщении об ошибках. Каждая запись журнала уровня ERROR содержит перехваченное исключение и соответствующие контекстные данные.
django.dispatch
Этот логгер используется в сигналах, а именно в классе Signal, чтобы сообщать о проблемах при отправке сигнала подключённому обработчику. Запись журнала уровня ERROR содержит перехваченное исключение в качестве exc_info и следующие дополнительные данные:
-
receiver: имя обработчика. -
err: исключение, возникшее при вызове обработчика.
django.security.*
Логгеры безопасности получают сообщения при любых случаях возникновения SuspiciousOperation и других ошибок, связанных с безопасностью. Для каждого типа ошибки безопасности есть отдельный дочерний логгер, включая все SuspiciousOperation. Уровень события в журнале зависит от места обработки исключения. Большинство таких случаев регистрируется как предупреждение, а любое 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.
django.db.backends.schema
Записывает SQL-запросы, выполняемые при изменении схемы базы данных фреймворком миграций. Обратите внимание: запросы, выполняемые с помощью RunPython, не записываются. Сообщения этого логгера содержат params и sql в дополнительных данных (но, в отличие от django.db.backends, не длительность). Значения имеют тот же смысл, что описан в разделе django.db.backends.
django.contrib.sessions
Сообщения журнала, связанные с фреймворком сессий.
- Нефатальные ошибки, возникающие при использовании движка
django.contrib.sessions.backends.cached_db.SessionStore, регистрируются как сообщенияERRORс соответствующей трассировкой стека.
Обработчики
Помимо those provided by the
Python logging module, модуль ведения журнала Python, Django предоставляет один обработчик журнала.
-
class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)[исходный код] -
Этот обработчик отправляет письмо администраторам сайта, указанным в настройке
ADMINS, для каждого полученного сообщения журнала.Если запись журнала содержит атрибут
request, в письмо будут включены полные сведения о запросе. Если IP-адрес клиента указан в настройкеINTERNAL_IPS, тема письма будет содержать фразу «внутренний IP-адрес»; в противном случае — «ВНЕШНИЙ IP-АДРЕС».Если запись журнала содержит информацию о трассировке стека, она будет включена в письмо.
Аргумент
include_htmlклассаAdminEmailHandlerпозволяет управлять тем, будет ли к письму с трассировкой добавлено HTML-вложение с полным содержимым отладочной веб-страницы, которая была бы создана, если бы настройкаDEBUGимела значениеTrue. Чтобы задать это значение в конфигурации, укажите его в определении обработчикаdjango.utils.log.AdminEmailHandler, например:"handlers": { "mail_admins": { "level": "ERROR", "class": "django.utils.log.AdminEmailHandler", "include_html": True, }, }При использовании
AdminEmailHandlerучитывайте последствия ведения журнала для безопасности.С помощью аргумента
email_backendклассаAdminEmailHandlerможно переопределить почтовый бэкенд, используемый обработчиком, например:"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", }, }-
send_mail(subject, message, *args, **kwargs)[исходный код] -
Отправляет письма администраторам. Чтобы настроить это поведение, можно создать подкласс
AdminEmailHandlerи переопределить этот метод.
-
Фильтры
Помимо фильтров модуля ведения журнала Python, Django предоставляет несколько собственных фильтров журнала.
-
class CallbackFilter(callback)[исходный код] -
Этот фильтр принимает функцию обратного вызова (она должна принимать один аргумент — запись, которую нужно зарегистрировать) и вызывает её для каждой записи, прошедшей через фильтр. Если функция обратного вызова возвращает 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", }, }, # ... }
-
class RequireDebugFalse[исходный код] -
Этот фильтр пропускает записи, только если 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", }, }, # ... }
-
class RequireDebugTrue[исходный код] -
Этот фильтр похож на
RequireDebugFalse, но пропускает записи только тогда, когдаDEBUGимеет значениеTrue.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/6.0/ref/logging/