Flask+uWSGI 的 Logging 支持

文章目录


我在 部署Flask + uWSGI + Nginx 一文中详细讲解了如何部署一个 Flask 应用。但这篇文章忽略了生产环境的一个重要的功能: Logging 。

本文基于 Flask 0.12.2 。

当 Flask App 被部署到生产环境时,我们会选择关闭 DEBUG 配置。在这种情况下,Flask 中使用 flask.current_app.logger.info() 打印的 LOG 仿佛消失了一样。它们去了哪里呢?

默认的 Handler

下面的源码位于 [flask.logging][loggin] 中。从源码可以看出,Flash 自动创建了 logger 并加入了一个 DEBUG 级别的 Handler 和一个 ERROR 级别的 Handler。根据 DEBUG 变量的值,DEBUG Handler 在生产环境下是不生效的。因此我们就只能看到来自于 ProductHandler 的 ERROR 级别 Log 信息。

 1def create_logger(app):
 2    """Creates a logger for the given application.  This logger works
 3    similar to a regular Python logger but changes the effective logging
 4    level based on the application's debug flag.  Furthermore this
 5    function also removes all attached handlers in case there was a
 6    logger with the log name before.
 7    """
 8    Logger = getLoggerClass()
 9
10    class DebugLogger(Logger):
11        def getEffectiveLevel(self):
12            if self.level == 0 and app.debug:
13                return DEBUG
14            return Logger.getEffectiveLevel(self)
15
16    class DebugHandler(StreamHandler):
17        def emit(self, record):
18            if app.debug and _should_log_for(app, 'debug'):
19                StreamHandler.emit(self, record)
20
21    class ProductionHandler(StreamHandler):
22        def emit(self, record):
23            if not app.debug and _should_log_for(app, 'production'):
24                StreamHandler.emit(self, record)
25
26    debug_handler = DebugHandler()
27    debug_handler.setLevel(DEBUG)
28    debug_handler.setFormatter(Formatter(DEBUG_LOG_FORMAT))
29
30    prod_handler = ProductionHandler(_proxy_stream)
31    prod_handler.setLevel(ERROR)
32    prod_handler.setFormatter(Formatter(PROD_LOG_FORMAT))
33
34    logger = getLogger(app.logger_name)
35    # just in case that was not a new logger, get rid of all the handlers
36    # already attached to it.
37    del logger.handlers[:]
38    logger.__class__ = DebugLogger
39    logger.addHandler(debug_handler)
40    logger.addHandler(prod_handler)
41
42    # Disable propagation by default
43    logger.propagate = False
44
45    return logger

要解决这个问题,我们需要创建自己的 Handler 。

创建自己的 Handler

在创建了 Flask app 之后,调用下面的 _set_logger 方法将 app 实例传入即可。详细的介绍见代码中的注释。

 1def _set_logger(flaskapp):
 2    """
 3    设置 Flask app 的logger
 4    """
 5    # 删除 Flask 的默认 Handler
 6    del flaskapp.logger.handlers[:]
 7    if flaskapp.config.get('DEBUG'):
 8        # 在 DEBUG 模式下,使用 StreamHandler,并使用 DEBUG 级别,这样可以将所有的信息都输出到控制台
 9        hdr = logging.StreamHandler()
10        hdr.setLevel(logging.DEBUG)
11        flask.logger.setLevel(DEBUG)
12    else:
13        # 不使用 StreamHandler 的原因,是 uwsgi 可能会在标准输出中加入它自己的 Log,为了避免Log被弄乱,单独使用一个 FileHandler
14        hdr = logging.FileHandler(config.getdir('logs', 'app.log'), encoding='utf8')
15        hdr.setLevel(logging.INFO)
16        flask.logger.setLevel(INFO)
17
18    # 加入足够详细的信息
19    LOG_FORMAT = """
20[%(asctime)s] %(levelname)s in %(module)s.%(funcName)s [%(pathname)s:%(lineno)d]:
21%(message)s"""
22    hdr.setFormatter(logging.Formatter(LOG_FORMAT))
23
24    # 如果存在 sqlalchemy 的 Log 对象,也为其加入这个 Handler
25    for log in (flaskapp.logger, logging.getLogger('sqlalchemy')):
26        if log:
27            log.addHandler(hdr)

我们还可以重写 Flask 对象的 log_exception 方法,自动将所有的异常记录下来,并提供一些更详细的信息:

 1class MYFlask(Flask):
 2    def log_exception(self, exc_info):
 3        """...description omitted..."""
 4        self.logger.error(
 5            """
 6Request:   {method} {path}
 7IP:        {ip}
 8Agent:     {agent_platform} | {agent_browser} {agent_browser_version}
 9Raw Agent: {agent}
10            """.format(
11                method=request.method,
12                path=request.path,
13                ip=request.remote_addr,
14                agent_platform=request.user_agent.platform,
15                agent_browser=request.user_agent.browser,
16                agent_browser_version=request.user_agent.version,
17                agent=request.user_agent.string,
18            ), exc_info=exc_info
19        )

uWSGI 的 Logging 配置

我使用 INI 格式的配置文件,文件名一般为 uwsgi.ini。其中关于 Logging 的配置,我常用这样几个:

 1; 将写入 log 的工作委托给 master 进程
 2log-master = true
 3
 4; 单独开一个线程进行 log 写入工作,这样有更好的性能
 5threaded-log = true
 6
 7; 所有 log 都会写入这个文件
 8; 若希望所有 log 放在一起,设置了此选项后,不要设置 req-logger  logger 选项
 9; %d 代表 uwsgi.ini 所在文件夹(包含结尾的/), %n 代表 uwsgi.ini 的主文件名
10; 魔术变量: http://uwsgi-docs-zh.readthedocs.io/zh_CN/latest/Configuration.html#magicvars
11daemonize = %dlogs/%n.log
12
13;  uWSGI 请求 log 写入单独的 log 文件,这样做可以让log更加分离,便于查错
14; 设置了此选项后,daemonize 设置的输出文件就得不到请求相关的日志输出了
15req-logger = file:%dlogs/req.log
16
17;  uWSGI stdout/stderr log 写入单独的 log 文件
18; 因为设定了 req-logger ,必须同时设定 logger ,此时 daemonize 不会有 stderr/stdout 之外的日志输出
19logger = file:%dlogs/%n.log

自定义 uWSGI 的请求 log

uWSGI 会在 log 中自动写入请求 log,默认的格式如下:

[pid: 22740|app: 0|req: 162/324] 127.0.0.1 () {36 vars in 608 bytes} [Wed Nov 29 11:42:08 2017] GET /login/?code=001SkzFb1ppEDu0lTzHb1WPCFb1SkzF0 => generated 181 bytes in 69 msecs (HTTP/1.1 200) 5 headers in 209 bytes (2 switches on core 1)

关于其中信息如何解释,文档中并没有详细进行介绍,只能通过阅读 源码 logging.c 理解。

我在 uWSGI 的邮件列表中找到一封邮件 Default Log Format Explained? 介绍了 log 中每个项的详细作用。

pid -> the pid of the worker managing the request app -> the id (it is a integer, starting from 0) of the app, it makes sense when multiple apps are hosted in the same instance. It is -1 when no app managed the request (like when serving static files) or when the 'app' concept does not apply (like with php or cgi's) req: N/M -> N is the number of managed requests by the current worker for the specific app, M is the grand total (sum of all requests of all workers)

then you have REMOTE_ADDR followd by the (optional) REMOTE_USER (very similar to apache)

vars are the number of CGI vars in the request, and their size (from the uwsgi protocol point of view). The size is never higher than the --buffer-size (higher requests are discarded)

The time of the request follows

Then you have REQUEST_METHOD + REQUEST_URI

Then the response size and the time required for generating it

"via" is the techology used to send the response, currently can be sendfile, routing or offloading.

The response status follows, as well as the number of response headers.

"core" is the low-level concept for uWSGI concurrency context in a process (can be a thread or a greenlet or a fiber or a goroutine and so on...) while switches count is incremented whenever an app "yield" its status (this has various meanings based on the lower concurrency model used)

根据上面找到的资料和 格式化uWSGI请求日志 文档,通过设置 log-format 选项,我们可以模仿出默认的请求 log:

1log-format = [pid: %(pid)] %(addr) (%(user)) {%(vars) vars in %(pktsize) bytes} [%(ctime)] %(method) %(uri) => generated %(rsize) bytes in %(msecs) msecs (%(proto) %(status)) %(headers) headers in %(hsize) bytes (%(switches) switches on core %(core))

除了 app:req: 没有提供对应变量,其它的值都可以显示出来。

其它

日志编码器 也是一个重要的选项,若有需要可以添加该设置。

uWSGI 还可以使用 touch-logrotatetouch-logreopen 来实现 logging rotate,但为了让系统更加简单的独立,我建议使用 logrotate 来实现 logging rotate,并已经在 uWSGI+rsyslog 实现 rotating logging 一文中介绍过具体做法。

需要注意的是,我在 uWSGI+rsyslog 实现 rotating logging 一文的 单独使用 logrotate 小节中提到的使用 copytruncate 选项替换 create 选项,是因为没有通知 uWSGI 重新打开 log 文件。要做到这一点非常简单,除了使用刚才提到的 touch-logreopen 之外,还可以使用 Master FIFO 中的 l 命令。

相关阅读

全文完