Как следует из документации AWS:
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, а второй - нет.
Я не видел никакой разницы, поскольку два фрагмента используют корневой журнал.
Скопировано прямо из верхнего ответа в вопросе @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)
У меня была аналогичная проблема, и я подозреваю, что лямбда-контейнер вызывает logging.basicConfig для добавления обработчиков до того, как импортируется лямбда-код. Это похоже на плохую форму...
Обходной путь состоял в том, чтобы проверить, были ли настроены обработчики корневого регистратора, и если да, удалите их, добавьте мой форматтер и желаемый уровень журнала (используя basicConfig) и восстановите обработчики.
См. статью Запись в Python перед запуском logging.basicConfig?
Наверное, не ссылаясь на тот же журнал, на самом деле.
В первом фрагменте запишите возврат: 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
Причина, по которой ведение журнала не работает, заключается в том, что среда выполнения AWS Lambda Python предварительно настраивает обработчик ведения журнала, который в зависимости от выбранной версии среды выполнения может изменять формат записываемого сообщения, а также добавлять некоторые метаданные к запишите, если доступно. Что предварительно не сконфигурировано, так это уровень журнала. Это означает, что независимо от типа сообщения журнала, которое вы пытаетесь отправить, оно фактически не будет напечатано.
Поскольку в самих документах AWS для правильного использования библиотеки logging в контексте Lambda AWS вам нужно только установить уровень logging журнала для root-logger:
import logging
logging.getLogger().setLevel(logging.INFO)
Если вы хотите, чтобы ваш Python-скрипт был исполняемым как на AWS Lambda, так и с вашим локальным интерпретатором Python, вы можете проверить, настроен ли обработчик или нет, и в basicConfig к basicConfig (который создает обработчик stderr по умолчанию):
if len(logging.getLogger().handlers) > 0:
# The Lambda environment pre-configures a handler logging to stderr. If a handler is already configured,
# '.basicConfig' does not execute. Thus we set the level directly.
logging.getLogger().setLevel(logging.INFO)
else:
logging.basicConfig(level=logging.INFO)
По сути, исправление "обезьяны" при ведении журнала в AWS необходимо обрабатывать очень особым образом, где:
Так как обычно считается хорошей формой не запускать произвольный код при импорте модуля Python, вы обычно должны иметь возможность реструктурировать свой код так, чтобы тяжелая работа происходила только внутри лямбда-функции.
Я боролся с этой точной проблемой. Решение, которое работает как локально, так и в AWS CloudWatch, заключается в том, чтобы настроить ведение журнала следующим образом:
import logging
# Initialize you log configuration using the base class
logging.basicConfig(level = logging.INFO)
# Retrieve the logger instance
logger = logging.getLogger()
# Log your output to the retrieved logger instance
logger.info("Python for the win!")