Django для входа в консоль
Я пытаюсь настроить регистратор, который будет входить в консоль (я хочу это, потому что я использую Heroku с Papertrails (дополнение для журналирования Heroku), а материал, записанный в консоль, будет отображаться в Papertrails, делая его фильтруемым и все хорошие функции Papertrail.)
В настройках я сначала пробовал следующее:
LOGGING = {
'handlers' = {
'file': {
'level': 'DEBUG',
'class': 'logging.FileHandler',
'filename': 'mysite.log',
'formatter': 'verbose'
},
'console':{
'level': 'DEBUG',
'class': 'logging.StreamHandler',
},
},
(...)
'loggers'={
(...)
'page_processors': {
'handlers': ['console','file'],
'level': 'DEBUG',
}
}
(...)
}
согласно странице регистрации в Django (для тех, кто не использует Mezzanine, page_processors - это то, что Mezzanine запускает всякий раз, когда вы открываете страницу; вы можете думать о них как о представлениях Django, но они выполняют только контекст, а не рендеринг).
На page_processors.py у меня есть
import logging
logger = logging.getLogger(__name__)
@process_for(MyPage):
def myfunc(request, Page):
logger.info('page_processor logging test')
print 'my page_processor print'
(...)
Когда я обновляю страницу, я не вижу регистратор, но вижу печать И журнал в файл:
[02/Mar/2014 23:07:10] INFO [myApp.page_processors:13] page_progessor logging test
и поэтому я знаю, что логика работает. Немного погуглив, я обнаружил эту и эту страницу, которая решает именно эту проблему. Он говорит, что по умолчанию logging.StreamHandler регистрирует в STDERR. Если мы хотим войти в STDOUT, вы должны добавить ключевое слово аргумент "stream" в конструкцию logging.StreamHandler, и таким образом настроить обработчик следующим образом:
'handlers':{
(...)
'console':{
'level': 'DEBUG',
'class': 'logging.StreamHandler',
'stream': sys.stdout
},
}
Оказывается, это все еще не работает, и я не получаю никакой ошибки или чего-то еще, и я все еще вижу печать и журнал файлов. Только не консольный логгер.
Что происходит?
ОБНОВЛЕНИЕ:
Я пробовал это, не имеет значения.
Ответы
Ответ 1
Я, наконец, понял. Вот что происходило.
Когда вы определяете регистратор, используя getLogger, вы даете логину имя, в этом случае
logger = logging.getLogger(__name__)
и тогда вам нужно определить, как ведет журнал регистрации с таким именем в конфигурации LOGGING. В этом случае, поскольку этот файл находится внутри модуля, имя регистратора становится myApp.page_processors, а не page_processors, поэтому регистратор с именем "page_processors" в логике LOGGING никогда не вызывается. Итак, почему журнал работал с файлом? Потому что в (...), который я показываю в коде, есть еще один регистратор с именем 'myApp', который, по-видимому, получает вызов вместо этого, и тот записывает в файл.
Итак, решение этого вопроса состоит в том, чтобы правильно назвать регистратор:
LOGGING = {
# (...)
'loggers': {
# (...)
'myApp.page_processors': {
'handlers': ['console','file'],
'level': 'DEBUG',
}
}
# (...)
}
Ответ 2
Следующий script:
import logging, logging.config
import sys
LOGGING = {
'version': 1,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'stream': sys.stdout,
}
},
'root': {
'handlers': ['console'],
'level': 'INFO'
}
}
logging.config.dictConfig(LOGGING)
logging.info('Hello')
записывает Hello
в sys.stdout
, что можно проверить, передав его вывод в файл. Таким образом, ваша проблема, вероятно, будет где-то в другом месте (или, возможно, sys.stdout не то, что вы ожидаете). Вы можете попробовать с помощью sys.__stdout__
, чтобы узнать, не имеет значения.
Ответ 3
Я пишу это для легкого понимания манекенов, как я.
В settings.py
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
},
},
'loggers': {
'app_api': {
'handlers': ['console'],
'level': 'INFO',
},
},
}
Где-то в вашем приложении просматривает
import logging
logger = logging.getLogger('app_api') #from LOGGING.loggers in settings.py
try:
one = 1/0
except Exception as e:
logger.error(e)