OSprofiler 跨服务与项目性能分析¶
https://blueprints.launchpad.net/oslo/+spec/osprofiler-cross-service-project-profiling
使命宣言¶
OSprofiler 是一个分布式追踪工具包库。它提供 Python 辅助函数来生成追踪，避免重复代码来追踪 WSGI、RPC、DB 和其他重要位置…它还提供各种收集后端接口以及用于解析数据进出的辅助函数。
问题描述¶
提议的变更¶
OSprofiler 已被 Cinder、Heat、Glance 使用，并将被大多数其他项目使用，例如：
OpenStack Client https://review.openstack.org/#/c/255861/
由于目前 OSprofiler 不受 OpenStack 治理伞形项目管理 https://github.com/openstack/governance/blob/master/reference/projects.yaml，我们建议 Oslo 项目应成为 OSprofiler 的归属。
此外，与其他 oslo 项目一样，我们也应该为 OSprofiler 设立一个核心团队。
实现¶
OSprofiler 如何工作 *
OSprofiler 是一个非常小的库，它允许您创建嵌套的追踪。基本上，它只是在内存中维护一个元素堆栈（列表）。
每个元素有 3 个追踪 ID
- base_id - 同一追踪的所有点都具有相同的 base_id，这有助于
我们获取与某个追踪相关的所有点
parent_id - 父级点的 ID
current_id - 当前点的 ID
它有两个方法 start() 和 stop()。start() 压入新元素并调用驱动程序的 notify 方法，附带有效载荷；stop() 从堆栈中移除最新元素并再次调用 notify()。
这使我们能够构建一个包含持续时间和有效载荷信息的调用树：如此处所示。
有关更多详细信息，请阅读文档。
将用作 OSprofiler 驱动程序（追踪收集器）的组件 *
OSprofiler 将支持多驱动程序。这意味着基本上任何集中式系统都可以用于收集数据。甚至我们可以将追踪信息直接写入文件。
作为第一个驱动程序，我们将使用 oslo.messaging & Ceilometer
未来 OSprofiler 团队将添加对 MongoDB、InfluxDB、ElasticSearch 的驱动程序
OSprofiler 集成点 *
项目配置的更改
在所有项目中添加配置组 “profiler” 和 3 个配置选项
enabled = False # 默认完全禁用 OSprofiler
- trace_db = False # 是否追踪数据库请求。默认禁用
# 默认情况下，因为数据库请求太多 # 并且追踪它们只对深度调试有用。
- hmacs = SECRET_KEY # 用于签署激活 OSprofiler 的 HTTP 标头的 HMAC 密钥
# 用于阻止普通用户触发 OSProfiler。 # 它们必须对所有项目都相同。
- connection = None # 连接字符串，指定使用哪个
# OSProfiler 驱动程序以及指定后端的凭据。例如 # mongo://user:password@ip:port/schema
在 2 个项目之间保持单一追踪
将 OSprofiler 中间件添加到所有项目的所有 paste.ini 中的所有管道
如果存在用正确 HMAC 密钥签名的特殊 HTTP 标头，此中间件将初始化 OSProfiler。
在单个项目的 2 个服务之间保持单一追踪
如果 RPC 调用者已初始化分析器，它应该向所有 RPC 消息添加包含追踪信息的特殊有效载荷。如果被调用进程发现此类消息，它应该初始化 OSProfiler。
Python 客户端所需的更改
每个 Python 客户端需要进行 2 处更改
如果启用了分析器，则添加分析器追踪标头，这将在项目 A 通过 Python 客户端调用项目 B API 时使用。
CLI 参数 –profile
- 这将初始化 OSprofiler
默认应该追踪哪些点？
我认为所有项目默认应包含 5 种类型的点
所有 HTTP 调用 - 有助于获取以下信息：完成了哪些 HTTP 请求，调用持续时间（服务延迟），请求中涉及的项目信息。
所有 RPC 调用 - 有助于理解单个项目中与不同服务相关的请求部分的持续时间。此信息对于理解哪个服务产生瓶颈至关重要。
所有 DB API 调用 - 在某些情况下，缓慢的数据库查询可能会产生瓶颈。因此，追踪请求在数据库层花费了多少时间非常有用。
所有驱动程序层调用 - 在 Nova、Cinder 等项目中，我们有供应商驱动程序。（例如 nova.virt.driver）
所有 DB API 层调用（例如 nova.db.api）
所有原始 SQL 请求（默认关闭，因为它会产生大量流量）
特定项目方法/类/代码片段的任何其他导入
** 未来也应该追踪的点：**
所有外部命令。例如，oslo.concurrency processutils.execute() 调用。因为外部命令完成的工作是许多后端 API 实现的关键部分，并且需要不短的时间。
工作线程的产生/运行。一些 API 调用将导致生成一次性后台线程，以异步处理一些工作。我认为能够通过在请求线程启动时记录追踪，然后在线程主方法的开始+结束处进行追踪，从而捕获这项工作是很重要的。
备选方案¶
为什么不用 cProfile 和其他 python 追踪器/调试器？
这个库的范围完全不同
它应该创建跨所有服务/项目的单一追踪
能够收集代码中特定点的数据而不是所有方法的数据更有趣
CProfiler 类似的功能未来可以集成到 OSprofiler 中
这个库应该易于与 OpenStack 集成。这意味着
它不应该要求对集成项目的代码库进行太多更改。
应该可以完全轻松地关闭它
在生产环境中应该可以在惰性模式下保持开启（例如，知道 HMAC 密钥的用户可以追踪他们的请求）。
Zipkin 和其他现有分布式追踪解决方案如何？
OSprofiler 是一个小库，用于为 OpenStack 提供无供应商锁定的追踪解决方案。
OSprofiler 不打算实现整个 Zipkin 类似的堆栈。它只是一个用于将 OpenStack 与不同收集器集成的微型库，并提供不受任何追踪服务（例如 Zipkin）硬编码的原生 OpenStack 追踪器/分析器。
对现有 API 的影响¶
所有项目的所有 API 方法将接受 2 个新标头：X-Trace-Info 和 X-Trace-HMAC，它们将实际触发分析器。
- 所有 Python 客户端将接受 –profile 键，该键将实际放置正确的
X-Trace-Info 和 X-Trace-HMAC 标头到 HTTP 请求中，并打印追踪 ID。
目前不需要对任何现有 oslo 库进行任何更改。如果我们决定将 OSprofiler 集成到一些 oslo 库中，我们将在该特定库中进行标准规范/PR/审查流程。
安全影响¶
OSprofiler 使用 HMAC 来签署追踪标头。只有知道用于 HMAC 的密钥的人才能触发分析器。由于 HMAC 相当安全，因此不会出现安全问题。
即使在最坏的情况下，当攻击者知道密钥时，他将能够触发分析器，这将使他的请求变慢一点，但不会影响其他用户。
性能影响¶
如果关闭，性能开销可以忽略不计。只有几个 “if None” 检查
如果开启，有两种不同的情况
请求中没有追踪标头 => 没有性能影响
存在追踪标头
追踪 ID 用错误的 HMAC 签署，检查追踪 ID 是否由正确的 HMAC 密钥签署的开销。
追踪 ID 用正确的 HMAC 签署，开销将取决于追踪点的数量和通知 API 的性能。对于像启动虚拟机、创建卷这样的请求，开销可能是可测量的；对于像显示资源详细信息这样的简单请求，开销将微不足道。
每 N 个请求的追踪配置（尚未完成）
在这种配置下，每 N 个请求都会有 OSprofiler 开销，具体取决于许多因素：追踪点的数量（取决于 API 方法）、OSprofiler 后端以及其他因素……
Configuration Impact¶
我们正在向所有项目添加新的 CONF 组选项
[profiler] # 如果为 False，则完全禁用分析功能。 #enabled = False
# 如果为 False，则不追踪 SQL 请求。 #trace_db = True
# 用于签署标头的 HMAC 密钥。 # 由于 OpenStack 包含许多项目，我们无法同时更新所有 HMAC # 密钥。为了提供 HMAC 密钥的零停机滚动 # 更新能力（出于安全原因），我们需要能够指定多个 HMAC # 密钥。更新 OLDKey -> NEWKey 的过程将如下所示： # 1) 初始系统配置： # 所有服务都有 OLDKey，用户使用 OLDKey # 2) 中间 1： # 所有服务都有 OLDKey，其中一部分同时拥有 OLDKey 和 NEWKey，用户 # 使用 OLDKey # 3) 中间 2： # 所有服务都有 OLDKey 和 NEWKey，用户使用 NEWKey # 4) 中间 3： # 部分服务同时拥有两个密钥，部分服务只有 NEWKey， # 用户使用 NEWKey # 5) 最终系统配置： # 所有服务只有 NewKey #hmacs = SECRET_KEY1, SECRET_KEY2
# 分析器驱动程序收集器连接字符串。connection = None
默认情况下，OSprofiler 是关闭的。然而，它可以保持在生产环境中开启，因为它在被触发之前不会增加任何开销，并且分析器只能由知道 HMAC 密钥的人触发。
开发人员影响¶
开发人员将能够分析 OpenStack 并修复与性能和扩展性相关的各种问题。
实现¶
负责人¶
- 主要负责人
boris-42 dinabelova harlowja zhiyan
里程碑¶
Mitaka-3
工作项¶
从 paste.ini 中移除 OSprofiler 配置：https://github.com/openstack/osprofiler/blob/master/doc/specs/in-progress/make_paste_ini_config_optional.rst
多后端支持：https://github.com/openstack/osprofiler/blob/master/doc/specs/in-progress/multi_backend_support.rst
将所有项目迁移到新的多后端模型
在所有 OpenStack 项目中集成 OSprofiler
更好的集成测试：https://github.com/openstack/osprofiler/blob/master/doc/specs/in-progress/integration_testing.rst
更好的 DevStack 集成：https://github.com/openstack/osprofiler/blob/master/doc/specs/in-progress/better_devstack_integration.rst
集成 Rally & OSprofiler
孵化¶
采用¶
所有项目和 Python 客户端都应该添加少量代码，以实现跨项目/服务追踪。
库¶
OSprofiler 库的代码可以在这里找到：https://github.com/openstack/osprofiler/
预计 API 稳定¶
无。
文档影响¶
我们应该在一个地方记录如何配置和使用 OSprofiler。
依赖项¶
OSprofiler 可以是 Python 客户端的运行时依赖
OSprofiler 应该在将使用 OSprofiler 的项目的需求中
参考资料¶
OSprofiler 库：https://github.com/stackforge/osprofiler
OSprofiler 规范：https://github.com/openstack/osprofiler/tree/master/doc/specs
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
