Spec-Zone.ru › Django 5.2

Ведение журнала

См. также

  • Как настроить и использовать ведение журнала
  • Обзор ведения журнала Django

Модуль ведения журнала 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 4.2.16.

Сообщения, связанные с 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/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API