将每个请求上下文添加到使用Python登录

Question

背景

对于REST api服务,我想以一种我不必重写整个应用程序的日志语句的方式提供更多的日志记录上下文.我正在使用烧瓶内的python日志库和带有gunicorn的eventlet运行器类型.

用例

想象一下,通过这个系统的所有请求都有一个唯一的(足够的)事务ID作为来自某个上游源(可能是反向代理)的头传递的未来.我想用每个日志语句记录此事务id,以便即使在峰值负载期间也可以通过我的系统轻松跟踪给定的请求.

途径

编写一个自定义日志记录上下文过滤器类,从烧瓶中提取所需信息.我的理解是,我应该能够从线程本地上下文变量中提取此信息(即请求对象).在初始化全局根记录器之后,我只需设置这个自定义上下文过滤器,所有这些都应该在调试方面做得很好!

我从以下食谱文档中发现了这种方法... https://docs.python.org/2/howto/logging-cookbook.html#using-filters-to-impart-contextual-information

问题

• 您是否预见到这种方法存在任何扩展问题？
• 有关将此事务ID下游传播到我网络中的其他请求的想法？
• 使用eventlet worker类型是否会妨碍这种行为(即并发问题导致的混合上下文)？
• 只因为你可以,并不意味着你应该.我不应该这样做的任何其他原因？

Answer 1

听起来您可能正在考虑实施类似X-Trace的系统。免责声明：我使用的商业产品是这样运作的。

随着应用程序复杂性的增加，传播可能会成为一个问题。当您在后端需要更多现成的解决方案或多语言组件时，这些将需要上下文日志记录的支持，否则就会因缺乏可见性而受到负担。如果您需要通过 HTTP-RPC 之外的其他东西（如 JBoss 或 Thrift）传递上下文，或者某种实现复杂性上升的消息队列，那么备用消息传递机制也是如此。

对于异步请求，您肯定需要确保唯一 id 从阻塞代码路径正确传递到事件代码路径，否则存在混合/重复使用 id 的风险。在分析呼叫传播时，这可能是微妙的转移注意力的来源。