背景
对于 REST api 服务，我想以一种无需为整个应用程序重写日志语句的方式提供更多日志记录上下文。我在 flask 中使用 python 日志记录库，在 gunicorn 中使用 eventlet runner 类型。
用例
想象一个 future ，通过这个系统的所有请求都有一个唯一的(足够的)事务 ID 作为来自某个上游源(可能是反向代理)的 header 传递。我想在每个日志语句中记录此事务 ID，以便即使在高峰负载期间也可以轻松跟踪通过我的系统的给定请求。
方法
编写一个自定义日志记录上下文过滤器类，从 flask 中提取所需的信息。据我了解，我应该能够从线程本地上下文变量中提取此信息(即请求对象)。在全局根记录器初始化后，我只需设置这个自定义上下文过滤器，在调试领域一切都应该很好!
我从以下食谱文档中发现了这种方法... https://docs.python.org/2/howto/logging-cookbook.html#using-filters-to-impart-contextual-information
问题
- 您是否预见到这种方法会出现任何扩展问题？
- 是否考虑将此事务 ID 传播到我网络中的下游其他请求？
- 使用 eventlet worker 类型是否会妨碍这种行为的预期(即由于并发问题而导致的混合上下文)？
- 仅仅因为你可以，并不意味着你应该。我不应该这样做的任何其他原因？
最佳答案
听起来您可能正在考虑实现 X-Trace像系统。免责声明:我使用的是这样运作的商业产品。
随着应用程序复杂性的增加，传播可能会成为一个问题。当您在后端需要更多现成的解决方案或多语言组件时，这些将需要支持上下文日志记录或因缺乏可见性而负担重重。如果您需要通过除 HTTP-RPC 之外的其他东西(如 JBoss 或 Thrift)传递上下文，或者某种实现复杂性上升的消息队列，备用消息传递机制也是如此。
对于异步请求，您肯定需要确保将唯一 ID 正确地从阻塞代码路径传递到事件代码路径，否则就有混合/重新使用 ID 的风险。在分析调用传播时，这可能是微妙的转移注意力的来源。
关于python - 将每个请求的上下文添加到 Python 中的日志记录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25153931/