日志请求 ID 映射

https://blueprints.launchpad.net/nova/+spec/log-request-id-mappings

在多个 OpenStack 服务之间跟踪请求非常困难。

问题描述

每个 OpenStack 服务都会在 HTTP 响应中发送一个请求 ID 头部。这个值对于在日志中追踪问题很有用。但是，当操作跨越服务边界时，这种追踪变得困难，因为服务为每个入站请求生成一个新的 ID；nova 的请求 ID 无法帮助用户找到由 nova 在满足请求时调用的其他服务的调试信息。当大量请求同时到达时，尤其是在 gate 环境下，tempest 现在并行运行测试时，这个问题变得更加突出。仅仅匹配服务日志之间的时间戳不再是一种可行的解决方案。因此，需要另一种请求追踪方法来帮助调试。

提议的变更

请求 ID 在请求处理开始时生成。这是用户在请求返回时看到的 ID。nova 调用到的其他 OpenStack 服务（例如 glance）会在响应中以头部形式发送它们自己的请求 ID。通过记录两个请求 ID 的映射（nova->glance），用户将能够轻松地在 n-api 日志中查找 glance 返回的请求 ID。有了 glance 的请求 ID，用户就可以检查 glance 日志，以获取与 nova 发起的请求相对应的调试信息。

需要两个请求 ID 来形成日志消息：一个由 nova 生成，另一个包含在来自另一个服务的响应中。nova 生成的请求 ID 位于传递到 python 客户端包装器中的上下文中。其他服务的请求 ID 尚未到达 nova 的客户端包装器；该值的返回取决于某些客户端蓝图的实现（参见依赖项）。一旦两个请求 ID 都可用，日志记录将使用 request_utils 中的 link_request_ids() 进行。

备选方案

这个想法在之前的周期中出现过[1]，提出的解决方案是在服务之间传递一个统一的请求 ID。虽然已经开始进行这项工作，但最终认为这种方法不令人满意，因为它允许客户端篡改请求 ID 值。客户端重用相同的请求 ID 将消除请求追踪的好处。使用精心选择的请求 ID，甚至一个用户可以干扰另一个用户的调试工作。因此，请求 ID 由服务器生成至关重要。

数据模型影响

无。

REST API 影响

无。

安全影响

无。

通知影响

使用的 request_utils 模块将为每个记录的请求 ID 映射生成一个 INFO 通知。

其他最终用户影响

最终用户只会看到这些信息在 nova 日志或生成的通知中。

性能影响

无。

其他部署者影响

为了使 nova 记录其他服务的请求 ID 值，该服务的 python 客户端需要将从服务 HTTP 响应中获取的请求 ID 返回。为了实现这一点，需要发布新版本的 python-glanceclient、python-cinderclient 等。因此，部署者需要运行较新版本的客户端才能记录请求 ID 映射。如果客户端没有返回请求 ID，则不会进行任何日志记录。

开发人员影响

无。

实现

负责人

主要负责人

chris-buccella

工作项

  1. 同步 oslo 中的 request_utils 模块

  2. 随着各种服务的 python 客户端更新为返回请求 ID，使用 request_utils.link_request_ids() 记录请求 ID 映射： 1. python-glanceclient 2. python-cinderclient 3. python-neutronclient

  3. 使用新版本的客户端更新 requirements.txt

依赖项

测试

可以添加一个 tempest 测试来确保以正确的格式生成通知。

文档影响

应更新操作指南，特别是

  • 第 11 章，在“确定哪个组件损坏”下

  • 第 13 章，在“追踪实例请求”下

参考资料

[0] 来自 Icehouse 周期的 nova<->glance 日志记录的提议变更：https://review.openstack.org/#/c/68518

[1] 来自 HK Summit 的讨论：https://etherpad.openstack.org/p/icehouse-summit-nova-cross-project-request-ids

[2] 来自邮件列表的改进：http://lists.openstack.org/pipermail/openstack-dev/2013-December/020774.html