Spec-Zone.ru › Django 5.0

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

См. также

  • Как настроить и использовать ведение журнала
  • Обзор ведения журнала в 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: Объект запроса (a 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 4.2:

Добавлена поддержка ведения журнала запросов управления транзакциями (BEGIN, COMMIT, и ROLLBACK).

django.utils.autoreload

Сообщения журнала, связанные с автоматической перезагрузкой кода во время работы сервера разработки Django. Этот логгер генерирует сообщение INFO при обнаружении изменения в файле исходного кода и может генерировать сообщения WARNING во время проверки файловой системы и процессов подписки на события.

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 предоставляет один обработчик журналов дополнительно к those provided by the Python logging module.

class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)

Этот обработчик отправляет электронное письмо на сайт 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)

Отправляет электронные письма администраторам. Чтобы настроить это поведение, можно создать подкласс класса AdminEmailHandler и переопределить этот метод.

Фильтры

Django предоставляет некоторые фильтры логов дополнительно к тем, которые предоставляет модуль Python logging.

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/5.0/ref/logging/

Spec-Zone.ru

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