Spec-Zone.ru › Django 6.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: объект запроса (объект 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/

Spec-Zone.ru

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