Spec-Zone.ru › Django 5.1

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

См. также

  • Как настроить и использовать ведение журнала
  • Обзор ведения журнала в 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.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.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.1/ref/logging/

Spec-Zone.ru

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