Странность модуля логирования, неправильное отображение сообщения лога? - PullRequest
0 голосов
/ 28 мая 2019

Вот небольшой пример того, что я нахожу очень странным в модуле logging:

import logging
logging.basicConfig()

#
# making a hierarchy like this:
#     root
#       |- session
#             |-session.foo
#
root_logger = logging.getLogger()
session_logger = logging.getLogger("session")
foo_logger = logging.getLogger("session.foo")
#
# root_logger and session_logger effective log levels
# are set to 30 (= WARNING)
#
foo_logger.debug("WA") #nothing is printed, so far so good
#
# and now enters the problem...
#
foo_logger.setLevel(logging.DEBUG)
foo_logger.debug("HELLO") #HELLO log message is printed!!!

Я не понимаю, почему печатается сообщение журнала "HELLO", насколько я понимаю поскольку к логгеру foo_logger не подключен обработчик, сообщение журнала должно всплывать и эффективно останавливаться регистратором более высокого уровня (session), поскольку его уровень установлен на WARNING (по умолчанию).

Похоже, установка уровня на foo_logger дает ему права на отображение через обработчик, но мне это очень непонятно.

Может кто-нибудь объяснить мне, почему сообщение напечатано? И что мне делать, чтобы иерархия логгеров была такой, как мне хотелось бы?

1 Ответ

1 голос
/ 28 мая 2019

Оба регистратора И обработчики имеют настройку level, а уровень по умолчанию для обработчиков 0.Вам нужно установить уровень родительского обработчика - в вашем случае root_logger.handlers[0] выше logging.DEBUG, чтобы отфильтровать debug() вызовы на foo_logger:

root_logger.handlers[0].level = logging.WARN
foo_logger.debug("peekaboo") # should not be printed

Обратите внимание, что logging.basicConfig()только делает очень упрощенную конфигурацию - в основном это означает, как начать работу с журналированием, для любой серьезной конфигурации, которую вы хотите вместо dictConfig, которая позволяет вам указывать обработчики, форматеры, уровни и т. д. по своему усмотрению.Также обратите внимание, что на самом деле у регистратора есть список обработчиков (не один), и что несколько регистраторов могут использовать один и тот же обработчик, поэтому, кто регистрирует, что (и где) зависит от комбинации уровней регистраторов И обработчиков (и от регистратора *Опция 1012 * тоже).

В качестве практического примера, в моем текущем (django) проекте мы имеем (среди прочего) обработчик «console» (записывает в stdout, который gunicorn перенаправляет в свой собственный файл журнала), чейдля уровня установлено значение INFO, а обработчик «уведомлений» (отправляет уведомления по электронной почте) с уровнем, установленным на WARN, так что некоторые из наших регистраторов (для наиболее чувствительных частей) будут отправлять сообщения INFO и выше в журналы Gunicorn и отправлять сообщения WARN и выше в качестве уведомлений тоже.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...