Обычно я использую стандартную библиотеку протоколирования или structlog. Недавно, когда я пытался добавить тест к функции, я увидел, что она использует current_app.logger — это означает, что этой функции нужен контекст приложения. В противном случае ему не нужен контекст приложения.
Есть ли преимущество использования current_app.logger вместо logger = logging.getLogger(__name__)? Возможно, есть данные, которых нет в стандартном регистраторе?
import logging
from flask import Flask, current_app
app = Flask(__name__)
# Normal Python logging
logger = logging.getLogger(__name__)
ch = logging.StreamHandler()
logger.addHandler(ch)
logger.setLevel(logging.DEBUG)
# Flasks app logger
app.logger.setLevel(logging.DEBUG)
@app.route("/")
def index():
current_app.logger.info("flask-app logger info-msg")
logger.info("base-logger infomsg")
return "foo"
if __name__ == "__main__":
app.run()
Параметр logger = logging.getLogger(__name__) настраивает ваш регистратор root по умолчанию, что вам может не понадобиться в производственной среде. Например, когда вы определяете logger для каждого файла/модуля, вы можете попасть в ловушку , подобную описанной здесь . Итак, как объяснил и прокомментировал @noslenkwah.
Наличие внутреннего регистратора не является уникальным для Flask, это стандартный способ использования журналирования в Python. Каждый модуль определяет свой собственный регистратор, но конфигурация ведения журнала обрабатывается только последним звеном в цепочке: вашим проектом.
Моя точка зрения - если у вас небольшое приложение, вы, очевидно, можете придерживаться регистратора по умолчанию. Для большего контроля над приложением и настройки более чем одного регистратора вы можете проверить Комплексное ведение журнала Python с использованием конфигурации YAML и вариант использования, который я пытался построить из этого YAML файла, чтобы интегрировать его. в одном из моих хобби-проектов.
Извините, я не совсем понимаю этот ответ. Видео, на которое вы ссылаетесь, кажется, защищает logging.getLogger(__name__)?
В основном это вопрос конфигурации. Из исходного кода Flask при регистрации :
def create_logger(app):
"""Get the Flask app's logger and configure it if needed.
The logger name will be the same as
:attr:`app.import_name <flask.Flask.name>`.
When :attr:`~flask.Flask.debug` is enabled, set the logger level to
:data:`logging.DEBUG` if it is not set.
If there is no handler for the logger's effective level, add a
:class:`~logging.StreamHandler` for
:func:`~flask.logging.wsgi_errors_stream` with a basic format.
"""
Таким образом, если вы используете объект логгера Flask, вы получаете один настроенный уровень ведения журнала, уже установленный на основе других настроек Flask, вместе с обработчиком.
Обратите внимание, что в исходном коде Flask используется регистратор:
def log_exception(self, exc_info):
"""Logs an exception. This is called by :meth:`handle_exception`
if debugging is disabled and right before the handler is called.
The default implementation logs the exception as error on the
:attr:`logger`.
.. versionadded:: 0.8
"""
self.logger.error(
f"Exception on {request.path} [{request.method}]", exc_info=exc_info
)
Таким образом, учитывая, что Flask и предположительно приложения, написанные с использованием Flask, используют журнал current_app.logger, в целом было бы разумно следовать этому шаблону, поскольку любая дополнительная конфигурация также будет распространяться. Однако, если бы у вас была веская причина, вы, безусловно, могли бы использовать свой собственный регистратор.