关于 uWSGI 的 log,我已经写过好几篇文章了。本篇是一个总结,希望把我这几年使用 uWSGI 中积累的关于 log 选项的经验做一个汇总介绍。

有兴趣可以先读一读这几篇文章,更多细节在这里:

1. 混乱的 uWSGI 文档

uWSGI 的功能强大,参数众多。要了解它的全部功能,看文档是最有效的办法。但 uWSGI 的文档一直广被诟病。文档中描述不清或者过时的地方很多。

例如,文档中提到了支持 ZeroMQ logger,但官方的 PyPI 版本中却并没有提供这个功能。

要弄清楚要使用的功能,在文档记录错误的时候,可以去查看源码或者翻找 StackOverflow。

uWSGI 的 Logging 文档

2. uWSGI 中与 log 相关的选项

2.1 前置选项

以下几个选项是必须要配置的:

[uwsgi]
; 启用 master 进程,管理 worker,提供大量高级功能
master = true
; log 在 master 中处理
log-master = true
; 使用单独的线程处理插件化 logger
threaded-logger = true

2.2 daemonize

daemonize 保证进程自守护。在这个选项中通常会配置一个文件地址,日志会写入这个地址。

如果不配置 daemonize,uWSGI 会在前台运行,日志输入到 STDOUT。这种情况下,建议用 Supervisor 来管理 uWSGI 进程。 因为 Sueprvisor 要求被管理的程序 必须运行在非守护模式

当使用了 Supervisor 来管理进程后,uWSGI 输入到 STDOUT 的日志会被 Supervisor 的日志系统接管。

2.3 logto

如果使用 Supervisor 来管理 uWSGI,又不希望 Supervisor 来接管日志,logto 就能排上用场了。

配置 logto 写入一个文件,此时日志就输入到 logto 配置的文件中了。

logto 是支持 logreopen 参数的。这一点我在 Flask+uWSGI logging rotate:重要补充 一文中有详细介绍。

2.4 logger 和 req-logger

logger 是插件化的日志处理器。和 logto 是完全不同的两套机制。

如果希望输出到其他目标,例如 redis、ZeroMQ、MySQL。就可以使用插件化的 logger 配置,此时 logto 和 daemonize 都不会输出。

req-logger 也是插件化的日志处理器。所不同的是它仅仅处理请求类的日志。如果不配置 req-logger,请求类的日志会和其他日志一起写入同一个目标。为了方便处理,我建议必须分离请求类的之日。

req-logger 的具体的使用方法,在 pyzog:logging rotate 的终极方案 中就有介绍。

使用了 logger 配置之后,logto 和 daemonize 都会不会有日志输出。

3. 相关阅读

全文完