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

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

'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

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

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

Spec-Zone.ru

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