Что такое celery.utils.log.ProcessAwareLoggerobject, выполняющий в logging.Logger.manager.loggerDict

Я проверяю logging.Logger.manager.loggerDict, делая:

import logging logging.Logger.manager.loggerDict 

и дикт выглядит следующим образом:

 { 'nose.case': <celery.utils.log.ProcessAwareLoggerobjectat0x112c8dcd0>, 'apps.friends': <logging.PlaceHolderobjectat0x1147720d0>, 'oauthlib.oauth2.rfc6749.grant_types.client_credentials': <celery.utils.log.ProcessAwareLoggerobjectat0x115c48710>, 'apps.adapter.views': <celery.utils.log.ProcessAwareLoggerobjectat0x116a847d0>, 'apps.accounts.views': <celery.utils.log.ProcessAwareLoggerobjectat0x116976990>, } There are more but I truncated it 

Мои вопросы:

  1. Почему сельдерей участвует в регистрации различных других приложений, не связанных с сельдереем? Это потому, что ведение журнала выполняется в асинхронном режиме, и каким-то образом фреймворк регистрации обнаруживает наличие сельдерея и использует его?
  2. Для двух моих собственных файлов, которые регистрируются с помощью logger = logging.getLogger(__name__) , я вижу, что это PlaceHolderObject, а два других – объект celery.utils.log.ProcessAwareLogger – хотя эти последние два вызываются во взглядах, а не в сельдерее процессы. Как это стало таким образом, тогда

благодаря

    Сам сельдерей заменяет (глобальный) класс регистратора, используя метод logging.setLoggerClass , с классом ProcessAwareLogger который выполняет пару действий: не пытайтесь выполнить регистрацию в обработчике сигнала и добавьте имя процесса в журналы. Это происходит, как только система регистрации сельдерея настроена. Вы видите этот класс даже на своих собственных регистраторах из-за глобального характера setLoggerClass .

    Что касается того, почему именно сельдерей спроектирован таким образом, я думаю, вам нужно будет спросить у разработчика Celery, но эффективно это позволяет Celery обеспечить, чтобы безопасность обработчика сигнала и имя процесса были учтены, даже если вы используете свои собственные регистраторы в вашем приложении.

    Документы logging python отмечают:

    Если вы используете асинхронные обработчики сигналов с использованием сигнального модуля, вы не сможете использовать запись из таких обработчиков. Это связано с тем, что реализации блокировки в модуле потоковой передачи не всегда возвращаются и поэтому не могут быть вызваны из таких обработчиков сигналов.

    Сельдерей использует signal поэтому это может быть причиной того, что он хочет глобально обеспечить соблюдение своего класса журнала.