检查用于数据收集和门控的计数器¶
问题描述¶
OpenStack 项目对它们所依赖的基础设施的影响差异很大。在进行全面部署之前很难衡量这一点，但我们应该能够通过检查系统已经维护的计数器来衡量这种影响。
提议的变更¶
创建一个名为“OpenStack QA Tools”的新仓库，用于存放用 Python 编写的小工具，用于此类目的。
创建一个工具，os-collect-counters，它可以收集从它可以访问的任何后端收集相关的计数器，使用它自己的配置，并输出包含所有计数器的 JSON 映射。包括与先前运行进行差异比较的能力，以便显示给定时间窗口内对计数器的影响。
初始计数器至少应包含一组 MySQL 计数器（例如 Innodb_bytes_written）和来自 RabbitMQ 管理接口的已发布消息，这些消息按可以从每个队列名称推断出的范围进行汇总。
利用现有的 subunit/statsd/graphite 基础设施来记录 devstack 门控中多个测试的结果。
对于每次运行，os-collect-counters 的 JSON 将作为附件添加到 subunit 流中。
附件中的计数器将被馈送到 statsd/graphite，以便建立趋势。
这将通过将附件存储插件添加到 subunit2sql 来实现。用于 OpenStack 门控作业的插件将特定于 OpenStack 的基础设施，并查找特定名称的附件以推送到 statsd/graphite。
监控计数器以获取稳定的指标，并确定问题的最佳预测指标。
一旦确定了稳定的计数器，就为这些计数器创建上限，以帮助防止系统中的新更改意外地给被测代码路径引入过多的成本。
由于围绕在全局冲突上失败门控测试的社会问题令人担忧，关于这些警告和错误的警告和错误可能是我们能够实现的唯一合理结果。要使这些限制变得严格，需要大量的社区共识。
实现¶
一个新的 Python 仓库，os-performance-tools，已经创建，并将用于提取和将计数器推送到 statsd/graphite 的目的。这将包括一个 subunit2sql 附件插件和将计数器作为 subunit 附件输出的代码。
负责人¶
主要负责人
Clint Byrum <clint@fewbar.com>
里程碑¶
- 完成目标里程碑
Mitaka-2
工作项¶
创建工具以从正在运行的安装中发出计数器
修改 devstack 门控作业输出以包含计数器
将 subunit2sql 附件插件添加到 subunit2sql 工作器，以将计数器推送到 infra graphite
分析数据以获取稳定的计数器和有用的趋势
将上限检查添加到 devstack 门控
