Ceilometer/blueprints/multi-dimensions

• Launchpad Entry: tbd
• Created: 2012年11月27日
• Contributors: Nick Barcet& Julien Danjou

总结

为了能够在API中执行智能且快速的聚合，我们需要能够执行基于简单租户/用户/资源三元组之外的其他键值对进行聚合的查询。 本规范建议以一种新的方式处理元数据，从而解决此问题。

发布说明

现在可以请求基于Ceilometer中每个计数器/计量表的附加“维度”的聚合值。

用户故事

• John希望检索其所有名为xxx的容器中的对象聚合数量
• Peter希望了解其所有实例类型yyyy的总CPU使用量
• Andrew希望检索CPU使用量的最大值，针对实例ID列表

前提条件

• 我们假设这里元数据的使用方式包含第一级json中的大多数键值对，这将构成我们未来的维度。

设计

此蓝图假设3个变更

1. 从元数据切换到维度

建议假设当前json格式的元数据中，所有形式为<string>:<string>的第一级键值对都是我们需要考虑的维度。

2. 向API添加维度过滤器

与计量表相关的每个API调用都将有一个额外的可选参数，该参数将是一个需要全部满足（逻辑与）的键值对列表，从而允许对匹配记录执行聚合求和、最大值和最小值函数（另一个蓝图将指定添加平均函数）。

• 维度：键值对，可能以URL的形式表示为多个参数（例如：&dimension="key1:value1"&dimension="key2:value2"...）

在功能的未来迭代中，另一个参数可以允许嵌套条件表达式，混合逻辑与和或。

• dimensionExpr -- 键值对上的嵌套条件，如 ( (("key1"="value1") & ("key2"="valueN")) | (("key1"="value3") & ("key2"="value4")) )

WSME包支持将复杂数据结构作为GET请求的参数，例如使用以下语法进行这些查询

 q.dimensions[0].name=dim1&q.dimensions[0].value=dim1val&q.dimensions[1].name=dim2&q.dimensions[1].value=dim2val

被调用的方法将接收一个“q”参数，该参数将是Query类的一个实例，其结构如下

  class Dimension(Base):
    name = text
    value = text

  class Query(Base):
    dimensions = [Dimension]

3. 隐式维度

现有的Source、ResourceID、UserID和TenantID被认为是隐式维度，不需要在元数据中指定，但可以像这样查询。

实现

存储设计

如果决定使用关系数据库存储引擎，则维度将存储在单独的表中，如下所示

+------------+       +------------+
| Dimensions |       | Event      |
+------------+       +------------+
| EventID    |N-----1| EvenID     |
| Key        |       | ResourceID |
| Value      |       | .....      |
+------------+       | .....      |

代码变更

待定

迁移

如果决定修改现有元数据的结构，我们需要提供一个过程将现有的元数据信息转换为新格式。

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。

---