Ceilometer/blueprints/tighten-model
< Ceilometer | blueprints
上下文
在 Ceilometer 中,我们的基本 Sample 是一个命名元组。Sample 之间没有关联。因此,发送以下内容是有效的
Sample(user_id='foo', resource_id='123abc', meter='bar', volume=123) Sample(user_id='xyz', resource_id='123abc', meter='bar', volume=234)
虽然在 OpenStack 中资源的所有者不能被更改,但由于 Ceilometer 不仅支持 OpenStack,还支持其他任何东西,因此允许这样做。
问题
虽然这在理论上,至少在 MongoDB 驱动程序中是成立的,但 Ceilometer API 无法反映这一点。例如,在检索资源时
GET /v2/resources/123abc
{
[...]
"resource_id": "123",
"timestamp": "2013-10-26T13:10:12.914529",
"user_id": "xyz"
}
API 将只返回一个资源,并且在这种情况下,一个 user_id,很可能是数据库中最新插入的一个。这不是很实用,最终也是错误的。
此外,允许这种非常灵活的存储方式会以一种可怕的方式降低大多数数据存储的性能。MongoDB 需要进行大型数据聚合,而 SQL 驱动程序无法以有效的方式将数据拆分到多个表中。拥有一个更“规范化”的数据存储将会有很大帮助。
我认为在 OpenStack 监控中,仅仅存储“sample”所提供的灵活性是不必要的,对于其他潜在平台来说,这是一个足够好的权衡。
解决方案
解决方案是
- 定义一个合适的数据模型。例如,假设一个资源始终属于同一个用户和项目。这应该在 ceilometer.storage.models 中完成。
- 相应地增强存储驱动程序。
- 尽可能地修复 v2 API,并可能准备一个更干净的 v3 API,利用这个数据模型来实现。