Ведение журнала
Модуль ведения журнала 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 включено только тогда, когда settings.DEBUG установлено в значение True, независимо от уровня логирования или установленных обработчиков.
Это логирование не включает инициализацию на уровне фреймворка (например, 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сообщения с соответствующим трассировкой.
Обработчики
Django предоставляет один обработчик журналов в дополнение к those provided by the
Python logging module.
-
class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)[source] -
Этот обработчик отправляет электронное письмо на сайт
ADMINSдля каждого сообщения журнала.Если запись журнала содержит атрибут
request, полные детали запроса будут включены в электронное письмо. В теме письма будет указано «внутренний IP», если IP-адрес клиента находится в настройкеINTERNAL_IPS; в противном случае будет указано «ВНЕШНИЙ 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)[source] -
Отправляет электронные письма администраторам. Для настройки этого поведения можно создать подкласс класса
AdminEmailHandlerи переопределить этот метод.
-
Фильтры
Django предоставляет некоторые фильтры журналов в дополнение к фильтрам, предоставляемым модулем Python logging.
-
class CallbackFilter(callback)[source] -
Этот фильтр принимает функцию обратного вызова (которая должна принимать один аргумент, запись, подлежащую регистрации), и вызывает её для каждой записи, проходящей через фильтр. Обработка этой записи не будет продолжена, если функция обратного вызова вернёт 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[source] -
Этот фильтр пропускает записи только в том случае, если 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[source] -
Этот фильтр аналогичен фильтру
RequireDebugFalse, за исключением того, что записи пропускаются только при значенииDEBUGравноTrue.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/5.2/ref/logging/