Spec-Zone.ru › Django 4.2

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

См. также

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

Модуль ведения журнала Django расширяет встроенный модуль Python logging.

Ведение журнала настраивается как часть общего процесса Django django.setup(), поэтому оно всегда доступно, если не отключено явно.

Стандартная конфигурация ведения журнала Django

По умолчанию Django использует формат logging.config.dictConfig.

Стандартные условия ведения журнала

Полный набор стандартных условий ведения журнала:

Когда 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: Объект запроса, который сгенерировал сообщение журнала.

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.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/4.2/ref/logging/

Spec-Zone.ru

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