Странность модуля регистрации, неправильное отображение сообщения журнала?
Вот небольшой пример того, что я нахожу очень странным в модуле 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 дает права на отображение
через обработчик но мне это очень непонятно.
Может кто-нибудь объяснить мне, почему сообщение печатается? И что мне сделать, чтобы иерархия логгеров была такой, как мне бы хотелось?
@DaduKhan извините, но это не помогает, поскольку предоставленная вами ссылка не связана с ведением журнала Python. Моя проблема не с печатью, а с тем, что я не могу понять, как применяются иерархия логгеров и правила отображать или не отображать сообщения.
foo_logger унаследовал свой уровень ведения журнала от своего родителя, то вы переопределяете этот уровень.
@Eqomatic, можешь уточнить? foo_logger не имеет обработчика. .propagate установлен на True, поэтому я ожидал, что сообщение журнала всплывет на session logger. И сообщение не отображается...
foo_logger также унаследовал обработчик от своего родителя, так как .propogate установлен на True.
Ответы 1
И регистраторы, и обработчики имеют параметр 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, которая позволяет вам указать обработчики, форматировщики, уровни и т. д. по своему усмотрению. Также обратите внимание, что у логгера на самом деле есть список обработчиков (а не один) и что несколько логгеров могут использовать один и тот же обработчик, поэтому кто что записывает (и где) зависит от комбинации логгеров И уровней обработчиков (и от propagate регистратора). тоже вариант).
В качестве практического примера, в моем текущем (django) проекте у нас есть (среди прочего) «консольный» обработчик (журналы в стандартный вывод, который gunicorn перенаправляет в свой собственный файл журнала), уровень которого установлен на INFO и обработчик «уведомления» ( отправляет уведомления по электронной почте) с уровнем, установленным на WARN, так что некоторые из наших регистраторов (те, которые предназначены для наиболее чувствительных частей) будут отправлять сообщения INFO и выше в журналы пушки а также также отправлять сообщения WARN и выше в качестве уведомлений по электронной почте.
это может быть полезно stackoverflow.com/questions/8391411/…