Django логирование ошибок в файл
Django использует встроенный модуль Python logging для системного логгирования. Подробности об использовании этого модуля описаны в документации модуля. Но для тех, кто никогда не использовал этот модуль (да и для тех кто использовал), мы приводим небольшой пример.
Действующие лица¶
Конфигурация логгирования в Python состоит из четырех частей:
Loggers(Логгеры)¶
DEBUG : Низкий уровень логгирования системной информации для последующего использования в отладке
INFO : Общая системная информация
WARNING : Информация о мелких проблемах возникших при работе приложения
ERROR : Информация об ошибках возникших при работе приложения
CRITICAL : Информация о критических ошибках
Handlers(Обработчики)¶
Filters(Фильтры)¶
Фильтр могут быть добавлены к логгеру или обработчику, можно использовать несколько фильтров.
Formatters(Форматер)¶
Использование логгирования¶
После настройки логгеров, обработчиков, фильтров и форматеров, добавим логгирование в наш код. Использовать логгирование очень просто. Вот небольшой пример:
Именование логгеров¶
Вызов logging.getLogger() возвращает (создает при необходимости) экземпляр логгера. Экземпляру логгера может назначить имя. Это имя используется при настройке логгирования.
Точки в названии логгера позволяют определять иерархию. Логгер project.interesting считается родительским по отношению к логгеру project.interesting.stuff ; логгер project родительским по отношению к project.interesting .
Функции логгирования¶
Логгер предоставляет методы для каждого уровня логгирования:
- logger.debug()
- logger.info()
- logger.warning()
- logger.error()
- logger.critical()
Также есть два дополнительных метода:
Настройка логгирования¶
Для настройки логгирования используется настройка LOGGING . Эта настройка описывает логгеры, обработчики, фильтры и форматеры а также их параметры.
По умолчанию, параметр конфигурации LOGGING совмещается с стандартной конфигурацией журналирования Django с помощью следующей схемы.
Если ключ disable_existing_loggers в параметре конфигурации LOGGING установлен в True (по умолчанию это так), тогда все логгеры стандартной конфигурации отключаются. Отключенные логгеры отличаются от удалённых; логгер продолжает существовать, но тихо игнорирует всё, что ему передаётся, не пытаясь передавать записи в родительский логгер. Следовательно, вам надо быть аккуратным, используя 'disable_existing_loggers': True ; скорее всего вам не нужно такое поведение. Вместо этого, вы можете установить disable_existing_loggers в False и переопределить некоторые или все стандартные логгер; также вы можете установить LOGGING_CONFIG в None и самостоятельно обработать конфигурацию журналирования .
Настройка логгирования происходит в момент инициализации Django функцией setup() . Поэтому можно быть увереннем, что логгирование всегда доступно в коде вашего проекта.
Примеры¶
Официальная документация формата dictConfig лучше всего описывает формат словаря конфигурации журналирования. Однако, чтобы показать вам её возможности, мы приведем несколько примеров.
При использовании этого примера убедитесь, что пользователь, от которого запускается Django приложение, имеет права на запись файла, указанного в 'filename' .
Были изменены настройки журналирования по умолчанию. Смотрите список изменений .
Наконец, здесь показан пример достаточно сложной конфигурации журналирования:
Эта конфигурация выполняет следующее:
Определяет два форматера:
Строка format является обычной строкой форматирования Python, описывающая детали, которые будут присутствовать в каждой строке журнала. Полный список переменных для форматирования вы можете найти в документации.
Определяет два фильтра:
project.logging.SpecialFilter с названием special . Если конструктор фильтра требует наличия дополнительных аргументов, вы можете указать их в словаре настройки фильтра. В этом случае будет передан аргумент foo со значением bar при создании экземпляра SpecialFilter .
Определяет два обработчика:
Настраивает три логгера:
Собственная конфигурация логгирования¶
Если вы не хотите использовать формат dictConfig для настройки логгирования, вы можете определить собственный формат.
Параметр конфигурации LOGGING_CONFIG определяет функцию, которая настраивает логгирование в Django. По умолчанию, параметр указывает на logging.dictConfig() . Однако, если вы хотите переопределить настройку логгирования, укажите функцию, которая принимает один аргумент. Содержимое LOGGING будет передано в функцию при настройке логгирования.
Отключение настройки логгирования¶
Если вы вообще не желаете настраивать журналирование (или требуется самостоятельно настроить журналирование, используя собственный механизм2), вы можете установить LOGGING_CONFIG в None . Это отключит процесс настройки журналирования для случая по умолчанию . Здесь приведён пример отключения конфигурации журналирования Django и затем ручной её настройки:
Установка LOGGING_CONFIG в None только означает, что процесс автоматической настройки отключен, это не влияет на само журналирование. Если вы отключите процесс конфигурации, Django все равно будет вызывать методы журналирования, используя поведение логгеров, настроенное по умолчанию.
Расширения для логгирования в Django¶
Django предоставляет набор утилит для решения стандартных задач логгирования в Web-приложениях.
Loggers(Логгеры)¶
Django предоставляет несколько встроенных логгеров.
django ¶
django.request ¶
django.template ¶
Записывает логи связанные с рендерингом шаблонов.
django.db.backends ¶
duration : Время выполнения SQL запроса.
sql : SQL запрос.
params : Параметры используемые при выполнении SQL запроса.
Для повышения производительности логгирование SQL запросов включено только при settings.DEBUG равном True , независимо от уровня логгирования и назначенных обработчиков.
Это логгирование не включает запросы, выполняемые при инициализации приложения (например, SET TIMEZONE ), или запросы управления транзакциями (такие как BEGIN , COMMIT и ROLLBACK ). Используйте логгирование на уровне базы данных, если вы хотите записывать все запросы.
django.security.* ¶
Чтобы игнорировать определенные типы SuspiciousOperation , вы можете переопределить логгер следующим образом:
django.db.backends.schema ¶
Логгирует SQL запросы, которые выполняют при миграции базы данных. Запросы, выполняемые в RunPython , не будут записаны.
Handlers(Обработчики)¶
Django предоставляет один дополнительный обработчик.
class AdminEmailHandler (include_html=False, email_backend=None)¶
Параметр include_html в AdminEmailHandler указывает будет ли e-mail содержать HTML содержимое debug-страницы, которая была бы создана при DEBUG равном True . Чтобы установить этот параметр, укажите его в словаре конфигурации django.utils.log.AdminEmailHandler , например так:
Через параметр email_backend класса AdminEmailHandler , можно переопределить бекенд отправки email :
По умолчанию используется экземпляр класса, указанного в EMAIL_BACKEND .
Filters(Фильтры)¶
Django предоставляет два дополнительных фильтра.
class CallbackFilter (callback)¶
Например, для исключения из писем информации об исключении UnreadablePostError (выбрасывается, когда пользователь прерывает загрузку файла), вы можете создать функцию фильтрации:
и затем добавить её в свою конфигурацию логгирования:
Этот фильтр работает только если настройка DEBUG равна False.
Этот фильтр используется в конфигурации LOGGING по-умолчанию, чтобы предотвратить отсылку писем обработчиком AdminEmailHandler если настройка DEBUG не равна False :
Этот фильтр аналогичен RequireDebugFalse за исключением того, что он пропускает записи только в случае когда параметр конфигурации DEBUG равен True .
Стандартная конфигурация логгирования¶
По умолчанию, Django настраивает следующую конфигурацию журналирования:
Если DEBUG равна True :
Если DEBUG установлен в False :
Были изменены настройки журналирования по умолчанию. Смотрите список изменений .
Также см. настройку логгирования , чтобы разобраться как вы можете дополнить или заменить стандартную конфигурацию логгирования.
В этой статье мы создадим небольшое тестовое приложение которое поможет мне рассказать о том как настраивать логгирование в Django. Мы сделаем следующее:
Создание виртуальной среды
Поскольку в этой статье мы будем использовать Python 3, перед созданием виртуальной среды Python проверьте, что вы используете версию Python не ниже 3.6.1:
Затем создайте каталог, чтобы сохранить наш проект:
Отлично. Прежде чем перейти к следующему разделу, давайте создадим и активируем нашу новую виртуальную среду:
Теперь все хорошо, перейдем к установке Django.
Установка Django
В виртуальной среде установим Django:
Проверим как установилась Django выводом версии:
Теперь перейдем к созданию простого приложения loggers.
Создание простого приложение
Команда django-admin создаст для нас начальный скелет приложения:
в вашем каталоге test вы увидите новую папку приложения:
В качестве последнего шага, чтобы убедиться, что все работает, перейдем в каталог test и запустим встроенный веб-сервер Django:
Добавление нового модуля Django
Теперь, когда у нас есть главный каркас приложения, давайте создадим модуль с именем hello:
Эта команда создаст новую папку с именем hello вместе с несколькими дополнительными файлами Python. Замените содержимое hello/views.py следующим:
Это создает наше первоначальное представление (view), но нам все еще нужно сообщить об этом Django. Создайте новый файл в hello/urls.py и добавьте в него следующее:
Это связывает наше представление с базовым URL. Теперь все, что нам нужно сделать, это подключить его к файлу loggers/urls.py, чтобы Django знал, как все маршрутизировать. Откройте loggers/urls.py и замените его содержимое следующим:
Затем запустите веб-сервер, как мы делали раньше:
Теперь, когда у нас есть простое приложение, давайте посмотрим, как включить логгирование в Django.
Первые шаги с логгированием
Самое простое для включения логирования, которое мы можем сделать, это просто импортировать модуль Python logging и начать регистрацию. Начните с обновления файла app/views.py следующим кодом:
Настройка логгирования в Django
Мы можем изменить настройки логирование непосредственно в представление (view), сразу после импоритирования. По умолчанию Django использует формат dictConfig для настройки handlers, loggers, filters и formatters. Эти настройки задаются с помощью словаря LOGGING, который объединяется с конфигурацией ведения журнала Django по умолчанию. Выглядеть это будет следующим образом:
Или что бы настройки логгирования применились для всего проекта лучше всего это сделать в файле настроек loggers/settings.py. Просто добавив в конец файла следующие строки:
Рассмотрим это настройки более подробно.
version
Схема dictConfig не требует версии, но ее установка обеспечивает обратную совместимость. В настоящее время единственным допустимым значением здесь является 1.
disable_existing_loggers
formatters (форматы)
Этот раздел определяет, как будут выглядеть строки в логгах. Мы не будем рассматривать все возможные варианты форматирования. В этой статье описывается все, что поддерживается. Давайте посмотрим на формат журнала консоли:
Вот что здесь используется:
handlers (обработчики)
loggers (логгеры)
В нашем примере мы не использовали один параметр который необходимо упомянуть здесь это filters
filters (фильтры)
Фильтр могут быть добавлены к логгеру или обработчику, можно использовать несколько фильтров.
Давайте сейчас обновим конфигурацию и посмотрим что получилось.
Тестирование новой конфигурации
Этого достаточно, чтобы включить логгирование в любом проекте Django. Сейчас вы можете самостоятельно поиграться с настройками обработчиков и логгеров в созданном тестовом приложение.
Далее, рассмотрим более подробно стандартные логгеры (logging) для ведения логов, которые предоставляет Django.
Стандартные логгеры
В среде веб-сервера у нас часто есть рутинная информация, которую мы должны регистрировать. Django предоставляет несколько стандартных логгеров (loggers) для ведения логов.
django
django.request
django.server
django.template
Независимо от того, как часто я работал с шаблонами Django, я никогда не собирал их без ошибок с первого раза. Логгер django.template обрабатывает ошибки, связанные с отображением шаблонов.
django.db.backends
django.security.*
django.security.csrf
Этот логгер не наследуется от SuspiciousOperation. Он обрабатывает любые исключения, которые происходят из-за атак Cross-Site Request Forgery (CSRF).
Так же для каждого модуля в вашем приложение вы можете описать свой логгер (например для ведение отдельных файлов). Это делается следующим образом:
что бы он работал нужно добавить настройки отправки почты также в файл settings.py (в нашем примере мы будет использовать сервер yandex, но можно использовать любой другой, с соотвествующими настройками)
Имена используемых параметров сами говорят за себя их предназначение. Очень важно понимать что бы все заработало сервер на котором запускается Django должен уметь отправлять почту (на нем должна быть настроена отправка почты по SMTP). Настройка отправки почты на сервере выходит за рамки данной статьи. Что бы немного облегчить поиск проблем связанных с настройкой отправки почты на сервере можно имитировать отправку почты Django. То есть вместо реальной отправки писем записывать их в локальный файл. Для этого нужно указать соотвествующий почтовой бекенд email_backend и файл для записи в настройках.
Так же можно добавить фильтр django.utils.log.RequireDebugFalse, который сделает так что бы письма отправлялись только когда отключен режим DEBUG то есть установлен DEBUG=False
Если по каким то причинам почта не отправляется, можно поискать причины отправив тестовое письмо вручную, через следующую функцию:
Еще один пример конфигурации логгирования
В заключение хочу привести еще одну конфигурацию указанную в официальной документации и описать ее.
Эта конфигурация выполняет следующее:
Определяет два formatters (форматера):
Определяет один filters (фильтр) – project.logging.SpecialFilter с названием special. Если конструктор фильтра требует наличия дополнительных аргументов, вы можете указать их в словаре настройки фильтра. В этом случае будет передан аргумент foo со значением bar при создании экземпляра SpecialFilter.
Определяет три handlers (обработчика):
Настраивает три loggers (логгера):
а затем настройте handlers консоли на использование rich.logging.RichHandler вместо logging.StreamHandler
Ваша жизнь после этого станет намного ярче 🙂
Заключение
В этой статье мы рассмотрели основы ведения логов с помощью Django. Логирование очень важно для поиска ошибок во время создания приложения, а так же может облегчить задачу поиска тех или иных прошедших события во время эксплуатации любого приложения. Надеюсь эта статья была вам полезна.
Краткое руководство по ведению журнала ¶
Django использует встроенный logging модуль Python для ведения системного журнала. Использование этого модуля подробно обсуждается в собственной документации Python. Однако, если вы никогда не использовали фреймворк ведения журналов Python (или даже если использовали), вот краткое руководство.
Состав игроков ¶
Конфигурация ведения журнала Python состоит из четырех частей:
Логгеры ¶
- DEBUG : Системная информация низкого уровня для отладки.
- INFO : Общая информация о системе
- WARNING : Информация, описывающая возникшую незначительную проблему.
- ERROR : Информация, описывающая возникшую серьезную проблему.
- CRITICAL : Информация, описывающая возникшую критическую проблему.
Обработчики ¶
Фильтры ¶
Фильтр используется для обеспечения дополнительного контроля над тем, какие записи журнала передаются от регистратора к обработчику.
Фильтры также можно использовать для изменения записи журнала перед отправкой. Например, вы можете написать фильтр, который понижает рейтинг ERROR записей журнала до WARNING записей, если выполняется определенный набор критериев.
Фильтры могут быть установлены на регистраторах или на обработчиках; несколько фильтров можно использовать в цепочке для выполнения нескольких действий фильтрации.
Форматировщики ¶
В конечном итоге запись журнала должна быть отображена в виде текста. Средства форматирования описывают точный формат этого текста. Средство форматирования обычно состоит из строки форматирования Python, содержащей атрибуты LogRecord ; однако вы также можете написать собственные средства форматирования для реализации определенного поведения форматирования.
Использование журнала ¶
После того, как вы настроили свои регистраторы, обработчики, фильтры и средства форматирования, вам необходимо поместить вызовы регистрации в свой код. Использование фреймворка ведения журнала работает следующим образом:
Вот и все! Каждый раз, когда bad_mojo условие активируется, будет записываться запись в журнал ошибок.
Именование логгеров ¶
Вызов для logging.getLogger() получения (создания, если необходимо) экземпляра регистратора. Экземпляр регистратора идентифицируется по имени. Это имя используется для идентификации регистратора в целях настройки.
Пунктирные пути имен регистраторов определяют иерархию. project.interesting Регистратор считается родителем project.interesting.stuff регистратора; project регистратор является родителем project.interesting регистратора.
Это распространение можно контролировать для каждого регистратора. Если вы не хотите, чтобы конкретный регистратор передавался своим родителям, вы можете отключить это поведение.
Выполнение журнала вызовов ¶
Экземпляр регистратора содержит метод записи для каждого из уровней журнала по умолчанию:
- logger.debug()
- logger.info()
- logger.warning()
- logger.error()
- logger.critical()
Доступны два других вызова журнала:
Настройка логирования ¶
Недостаточно просто поместить в код вызовы логирования. Вам также необходимо настроить средства ведения журнала, обработчики, фильтры и средства форматирования, чтобы обеспечить возможность использования вывода журнала.
Библиотека ведения журнала Python предоставляет несколько методов настройки ведения журнала, от программного интерфейса до файлов конфигурации. По умолчанию Django использует формат dictConfig .
Чтобы настроить ведение журнала, вы используете LOGGING словарь настроек ведения журнала. Эти параметры описывают средства ведения журнала, обработчики, фильтры и средства форматирования, которые вы хотите использовать в настройках ведения журнала, а также уровни журналов и другие свойства, которые должны иметь эти компоненты.
По умолчанию этот LOGGING параметр объединяется с конфигурацией ведения журнала Django по умолчанию, используя следующую схему.
Ведение журнала настраивается как часть общей setup() функции Django . Таким образом, вы можете быть уверены, что регистраторы всегда готовы к использованию в коде вашего проекта.
Примеры ¶
Полная документация по формату dictConfig - лучший источник информации о словарях конфигурации журналирования. Однако, чтобы дать вам представление о том, что возможно, вот несколько примеров.
Вам не нужно входить в консоль. Вот конфигурация, которая записывает все журналы из django с именем logger в локальный файл:
Если вы используете этот пример, обязательно измените 'filename' путь на место, доступное для записи пользователю, запускающему приложение Django.
Наконец, вот пример довольно сложной настройки ведения журнала:
Эта конфигурация ведения журнала выполняет следующие функции:
Определяет конфигурацию как имеющуюся в формате «dictConfig версии 1». В настоящее время это единственная версия формата dictConfig.
Определяет два средства форматирования:
format Строка является нормальным Python форматирования строки описания деталей , которые будут выводиться на каждой лесозаготовительной линии. Полный список деталей, которые можно вывести, можно найти в Объектах средства форматирования .
Определяет два фильтра:
- project.logging.SpecialFilter , используя псевдоним special . Если для этого фильтра требуются дополнительные аргументы, их можно указать в качестве дополнительных ключей в словаре конфигурации фильтра. В этом случае при foo создании bar экземпляра аргументу будет присвоено значение SpecialFilter .
- django.utils.log.RequireDebugTrue , который передает записи, когда DEBUG есть True .
Определяет два обработчика:
Настраивает три регистратора:
Пользовательская конфигурация ведения журнала ¶
Если вы не хотите использовать формат Python dictConfig для настройки вашего регистратора, вы можете указать свою собственную схему конфигурации.
Этот LOGGING_CONFIG параметр определяет вызываемый объект, который будет использоваться для настройки регистраторов Django. По умолчанию он указывает на logging.config.dictConfig() функцию Python . Однако, если вы хотите использовать другой процесс настройки, вы можете использовать любой другой вызываемый объект, который принимает единственный аргумент. Содержимое LOGGING будет предоставлено как значение этого аргумента при настройке ведения журнала.
Отключение конфигурации ведения журнала ¶
Если вы вообще не хотите настраивать ведение журнала (или хотите настроить ведение журнала вручную, используя собственный подход), вы можете установить LOGGING_CONFIG значение None . Это отключит процесс настройки журнала Django по умолчанию .
Установка LOGGING_CONFIG для None только означает , что автоматический процесс конфигурации отключен, не войдя себя. Если вы отключите процесс настройки, Django по-прежнему будет выполнять вызовы журналирования, возвращаясь к любому определенному поведению журналирования по умолчанию.
Вот пример, который отключает конфигурацию ведения журнала Django, а затем вручную настраивает ведение журнала:
Обратите внимание, что процесс конфигурации по умолчанию вызывается только LOGGING_CONFIG после полной загрузки параметров. Напротив, ручная настройка ведения журнала в файле настроек немедленно загрузит конфигурацию ведения журнала. Таким образом, ваша конфигурация ведения журнала должна отображаться после любых настроек, от которых она зависит.
Расширения журналирования Django ¶
Django предоставляет ряд утилит для удовлетворения уникальных требований ведения журнала в среде веб-сервера.
Логгеры ¶
Django предоставляет несколько встроенных регистраторов.
django ¶
django.request ¶
django.server ¶
django.template ¶
django.db.backends ¶
- duration : Время, затраченное на выполнение оператора SQL.
- sql : Выполняемый оператор SQL.
- params : Параметры, которые использовались в вызове SQL.
По соображениям производительности ведение журнала SQL включается, только если для settings.DEBUG него установлено значение True , независимо от уровня ведения журнала или установленных обработчиков.
Эта регистрация не включает в себя инициализацию рамки уровня (например ) или запросы управления транзакциями (например , , и ). Включите ведение журнала запросов в своей базе данных, если вы хотите просмотреть все запросы к базе данных. SET TIMEZONE BEGIN COMMIT ROLLBACK
django.security.* ¶
Чтобы отключить определенный тип SuspiciousOperation , вы можете переопределить этот конкретный регистратор, следуя этому примеру:
Другие django.security регистраторы, не основанные на SuspiciousOperation :
django.db.backends.schema ¶
Обработчики ¶
Django предоставляет один обработчик журналов в дополнение к тем, которые предоставляются модулем ведения журналов Python.
class AdminEmailHandler ( include_html = False , email_backend = None , reporter_class = None ) ¶
Если запись журнала содержит request атрибут, полная информация о запросе будет включена в электронное письмо. Тема электронного письма будет включать фразу «внутренний IP-адрес», если в INTERNAL_IPS настройках указан IP-адрес клиента ; в противном случае он будет включать «ВНЕШНИЙ IP-адрес».
Если запись журнала содержит информацию о трассировке стека, эта трассировка стека будет включена в электронное письмо.
include_html Аргумент AdminEmailHandler используется для управления , включает ли отслеживающий электронной почты вложения HTML , содержащий полное содержимое веб - страницы отладки , который был бы выработан , если бы DEBUG были True . Чтобы установить это значение в вашей конфигурации, включите его в определение обработчика django.utils.log.AdminEmailHandler , например:
Обратите внимание, что эта HTML-версия электронного письма содержит полную трассировку с именами и значениями локальных переменных на каждом уровне стека, а также значениями ваших настроек Django. Эта информация потенциально очень конфиденциальна, и вы можете не захотеть пересылать ее по электронной почте. Подумайте об использовании чего-то вроде Sentry, чтобы получить лучшее из обоих миров - богатую информацию о полных трассировках плюс безопасность, чтобы не отправлять информацию по электронной почте. Вы также можете явно указать определенную конфиденциальную информацию, которая будет отфильтрована из отчетов об ошибках - подробнее о фильтрации отчетов об ошибках .
Установив email_backend аргумент AdminEmailHandler , сервер электронной почты , который используется обработчиком, может быть переопределен, например:
По умолчанию будет использоваться экземпляр серверной части электронной почты, указанный в EMAIL_BACKEND .
Отправляет электронные письма администраторам. Чтобы настроить это поведение, вы можете создать подкласс AdminEmailHandler класса и переопределить этот метод.
Фильтры ¶
Django предоставляет некоторые фильтры журналов в дополнение к тем, которые предоставляются модулем ведения журналов Python.
класс CallbackFilter ( обратный вызов ) ¶
Этот фильтр принимает функцию обратного вызова (которая должна принимать единственный аргумент - запись, которая должна быть записана в журнал) и вызывает ее для каждой записи, проходящей через фильтр. Обработка этой записи не будет продолжена, если обратный вызов вернет False.
Например, чтобы отфильтровать UnreadablePostError (вызывается, когда пользователь отменяет загрузку) из электронных писем администратора, вы должны создать функцию фильтра:
а затем добавьте его в конфигурацию ведения журнала:
Этот фильтр будет передавать записи, только если settings.DEBUG имеет значение False.
Этот фильтр похож на RequireDebugFalse , за исключением того, что записи передаются только тогда, когда DEBUG есть True .
Правильное ведение логирования играет решающее значение для процесса отладки и устранения неполадок. Оно не только полезно для локального девелопменга, но и для продашен. При просмотре журналов в поиске проблемы, редко кто-то говорит: "Наше приложение слишком много логирует." Но чаще можно услышать иное. Итак, принимая это во внимание, давайте начнем.
Введение в логирование на Python
В верхней части каждого файла должно быть что-то подобное:
Переменная __name__ будет заменена точечным путём до Python модуля, например, скрипт myproject/myapp/views.py, то будет использоваться myproject.myapp.views. Теперь можно применять logger по всему файлу:
Перепишите свой код с помощью операторов логирования. Краткие рекомендации для выбора уровней журналирования:
- debug. Информация не нужна для повседневной работы, но полезна в разработке.
- info: Информация, которая полезна во время обычной работы.
- warning: Информация, которая может быть проблематичной, но не является срочной.
- error: Информация, которая важна и, вероятно, требует срочного внимания.
- critical: на практике используется редко, но если вам нужно больше, чем ошибка, то это то что нужно.
Куда логировать
Единственное, что нужно вашему приложению – это формат журналов. Обычно это всего лишь строка с соответствующими данными, но если ваш сервер уже добавляет отметку времени в журнал, то вероятно, нужно будет исключить ее из своего собственного форматирования. Аналогично, если ваш агрегатор журналов может принимать JSON, возможно, более подходящим является форматирование, такое как python-json-logger.
Конфигурирование логирования. Настройка Sentry
Служба отчетов об ошибках играют решающее значение для любого нетривиального сайта. По умолчанию они хранят необработанные исключения, уведомляя о проблеме (только один раз за инцидент) и предоставляют удобный интерфейс для просмотра состояния приложения, когда возникло исключение. Примером такого сервиса может быть Sentry.
Логирование из приложения
Как правило требуется сведения о предупреждениях и ошибках о сторонних зависимостей, но, как правило, требуется гораздо глубокое понимание кода приложения. В идеале, код целиком живет в одном пространстве имён, чтобы его можно было охватить одним логером. Предположим, что проект использует пространство имен myproject, основываясь на коде выше.
Как быть, если нудно исследовать что-то в своем приложении глубже, чем debug уровень журналированя? Коммит нового кода и его развертывая ощущается излишним. Лучшим вариантом в этом случае воспользоваться переменной окружения среды. Модифицируем предыдущий код, приведя к такому виду:
Теперь ведение журнала по умолчанию будет info, но может быть легко временно изменено, установив переменную среды LOGLEVEL = debug. В качестве альтернативы, если хранилище журналов не является проблемой, учитывайте возможность ведения журнала на уровне debug. Их достаточно легко отфильтровать с помощью простого grep или с помощью инструмента визуализации журнала, например, Kibana.
Отфильтровывание шума
После того, как установлено и запущено логирование, может появляться информация о некоторых модулях, которые не являются важными, продуцирующими дополнительный шум в журнальные файлы. Для таких модулей можно добавить еще один регистратор в настройки. Первый вариант заключается в том, чтобы вывести их на консоль, но не распространять их на корневой журнал, который отправит их в Sentry:
Если обнаружится, что они слишком шумные, даже для консоли, можно полностью отказаться от них логирования:
Логирование локальный запросов
По умолчанию в Django будет выполняться журналирование запросов с runserver. Переопределяя конфигурацию Django происходит потеря этой возможности. Но её достаточно легко добавить:
Читайте также: