Spec-Zone.ru › Django 4.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: Объект запроса, сгенерировавший сообщение журнала.

django.template

Сообщения журнала, связанные с рендерингом шаблонов.

  • Отсутствующие переменные контекста регистрируются как сообщения DEBUG.

django.db.backends

Сообщения, относящиеся к взаимодействию кода с базой данных. Например, каждое SQL-утверждение на уровне приложения, выполненное запросом, регистрируется на уровне DEBUG в этом логгере.

Сообщения в этом логгере имеют дополнительный контекст:

  • duration: Время выполнения SQL-запроса.
  • sql: Выполненный SQL-запрос.
  • params: Параметры, используемые в вызове SQL.
  • alias: Псевдоним базы данных, используемой в вызове SQL.

Из соображений производительности логирование SQL включено только тогда, когда settings.DEBUG установлено в True, независимо от уровня логирования или установленных обработчиков.

Это логирование не включает инициализацию на уровне фреймворка (например, SET TIMEZONE) или запросы управления транзакциями (например, BEGIN, COMMIT и ROLLBACK). Включите логирование запросов в вашей базе данных, если вы хотите просматривать все запросы к базе данных.

Изменено в Django 4.0:

Добавлена база данных alias для регистрации сообщений.

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, можно переопределить соответствующий логгер, следуя этому примеру:

'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, можно переопределить используемый backend для отправки электронной почты, как показано ниже:

'handlers': {
    'mail_admins': {
        'level': 'ERROR',
        'class': 'django.utils.log.AdminEmailHandler',
        'email_backend': 'django.core.mail.backends.filebased.EmailBackend',
    },
},

По умолчанию используется экземпляр почтового backend, указанный в настройке 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

а затем добавите её в вашу конфигурацию логирования:

'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:

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

Spec-Zone.ru

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