2016-06-08 4 views
14

Как следует из документации AWS:Использование питона Logging с AWS Lambda

import logging 
logger = logging.getLogger() 
logger.setLevel(logging.INFO) 
def my_logging_handler(event, context): 
    logger.info('got event{}'.format(event)) 
    logger.error('something went wrong') 

Теперь я сделал:

import logging 
logging.basicConfig(level = logging.INFO) 
logging.info("Hello World!") 

Первый фрагмент кода принтами в консоли Cloud Watch, но второй один нет.

Я не видел никакой разницы, поскольку два фрагмента используют корневой регистратор.

+0

Вам не хватает «return» Hello World! » – error2007s

+0

Почему бы не сделать то же самое, что и в первом фрагменте кода? Получите регистратор, который уже создан, и затем используйте указанный регистратор. –

+1

@ HEADLESS_0NE: Я могу использовать первый. Но я хотел бы понять, почему это поведение. –

ответ

2

Возможно, на самом деле не ссылается на тот же регистратор. В первом фрагменте зарегистрируйте возврат: logging.Logger.manager.loggerDict

Он вернет dict из уже инициализированных регистраторов.

Кроме того, из logging документации, важное примечание на logging.basicConfig:

ли базовую конфигурацию системы протоколирования путем создания StreamHandler с Formatter по умолчанию и добавить его в корневой регистратор. Функции debug(), info(), warning(), error() и critical() будут вызывать basicConfig() автоматически, если для корневого регистратора не определены обработчики.

Эта функция ничего не делает, если корневой регистратор уже настроил для него обработчики.

Источник: https://docs.python.org/2/library/logging.html#logging.basicConfig

+0

Отрывки разделены. Таким образом, второй фрагмент не настроен для ведения журнала, поэтому он будет настраивать корневой журнал. И если я вызову logging.info, он будет использовать корневой регистратор. Для меня нет никакого отличия от первого фрагмента. –

+0

@ HEADLESS_0NE находится прямо здесь. Кажется, что в лямбда уже настроен журнал. Если я делаю выше, но устанавливаю уровень в DEBUG, то я вижу больше журналов, чем я делаю (я сам не произвожу): '[DEBUG] \t 2016-10-29T09: 01: 28.376Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t Получение 0 [ОТЛАДКА] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({ 'смещение': 0}) о том, чтобы ждать следующих фьючерсов [] [DEBUG] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({ 'смещение': 0}) сделано в ожидании зависимой futures' –

6

У меня была аналогичная проблема, и я подозреваю, что контейнер лямбда вызова logging.basicConfig добавить обработчики перед кодом лямбда импортируется. Это похоже на плохую форму ...

Обходной путь состоял в том, чтобы определить, были ли обработчики корневого регистратора настроены, и если да, удалите их, добавьте мой форматтер и необходимый уровень журнала (используя basicConfig) и восстановите обработчики.

этой статье Python logging before you run logging.basicConfig?

4

Скопированы прямо из верхнего ответа на вопросе @ ответ ссылки StevenBohrer, чтобы (это сделало трюк для меня, заменив последнюю строку с моей конфигурацией):

root = logging.getLogger() 
if root.handlers: 
    for handler in root.handlers: 
     root.removeHandler(handler) 
logging.basicConfig(format='%(asctime)s %(message)s',level=logging.DEBUG) 
+0

работает как шарм –

0

по существу, AWS каротаж обезьяны патч должен быть обработан в очень определенным образом, где:

  1. уровень ведения журнала устанавливается с верхнего уровня сценария (например, ., Во время импорта)
  2. предложений журналирования интересующие вас вызывается из функции лямбды

Поскольку это обычно считаются хорошей формой, чтобы не запускать произвольный код в Python импорте модуля, вы обычно должны быть в состоянии чтобы перестроить ваш код, чтобы тяжелый подъем произошел только внутри лямбда-функции.

Смежные вопросы