Ceilometer/blueprints/monitoring

Launchpad Entry: CeilometerSpec:monitoring
创建时间: 2012年11月28日
贡献者: Angus Salkeld

总结

请注意这是一个很大的规范，尽可能地将其分解为子规范，以便更容易地分摊工作。

发布说明

原理

用户故事

告警的目的是在某个计量指标满足特定条件时通知用户。

一些例子

"当最大磁盘利用率超过 90% 时通知我" "当平均 CPU 利用率超过 80% 持续 120 秒时通知我" "当我的 Web 应用程序变得无响应时通知我" (负载均衡器延迟计量指标) "当我的 httpd 守护进程崩溃时通知我" (自定义用户脚本，用于检查守护进程健康状况)

如何使用告警

创建一个告警

{
 'period': '300',
 'eval_periods': '2',
 'meter': 'CPUUtilization',
 'function': 'average',
 'operator': 'gt',
 'threshold': '50'
 'resource_id': 'inst-002',
 'source': 'OS/compute',
 'alarm_actions': ['rpc/my_notify_topic', 'http://bla.com/bla'],
 'ok_actions': ['rpc/my_notify_topic']
}

这将每 300 秒检查 "CPUUtilization" 计量指标事件，如果对于 inst-002，过去两个 300 秒周期内的平均 CPUUtilization 均大于 50%，则它将在 "my_notify_topic" 主题上发送一个 rpc 通知，并将告警详细信息发布到 http://bla.com/bla。

当告警值低于此水平时，它将执行 "ok_actions"。

前提条件

我们试图提供类似于 CloudWatch 的功能，但以一种“OpenStack 方式”来实现，使其可以扩展。
需要监控的指标类型：http://docs.amazonwebservices.com/AmazonCloudWatch/latest/DeveloperGuide/CW_Support_For_AWS.html

   these are really the same kinds of meters that ceilometer currently samples

采样间隔在 10 秒到 60 秒之间，传输间隔在 1 分钟到 5 分钟之间
尝试尽可能地重用当前的 Ceilometer 代码，以便我们添加的功能也可以被计量 Ceilometer 使用。

设计

想法是尽可能地使用 Ceilometer 原有的功能，因此程序流程如下

数据插入

发布者可以选择以更快的速率（例如 60 秒）发出样本。它通过一种比 rpc 更高效且不干扰计量的不同传输方式来实现。

我们可以运行一个不同的（或相同的 - 待定）收集器，以与现在一样将样本插入数据库（仅传输方式不同）。

"Blueprint: https://blueprints.launchpad.net/ceilometer/+spec/multi-publisher"

API 认证

API 需要可供非管理员访问，以便获取用户自己的数据并控制自己的告警。这不应该成为问题，并且已经计划了相关工作。

"Blueprint: https://blueprints.launchpad.net/ceilometer/+spec/user-api"

数据查询

为了处理聚合查询（用于自动伸缩组），我们需要扩展查询机制，以便能够获取在定义的资源集（通常信息在元数据中）上的统计信息。

"Blueprint: https://blueprints.launchpad.net/ceilometer/+spec/multi-dimensions"

我们需要扩展 API，以便能够列出资源在租户中的计量指标类型。

我们需要支持更多的统计函数：最大值、最小值、平均值、计数，在定义的周期内。

"Blueprint: https://blueprints.launchpad.net/ceilometer/+spec/api-aggregate-average"

支持发布新的样本数据

"Blueprint: https://blueprints.launchpad.net/ceilometer/+spec/meter-post-api"

告警检测

TODO

告警通知

TODO

实现

本节应描述实施所讨论更改的行动计划（“如何”）。可以包括诸如

API 变更

新的告警 REST 资源
新的告警历史 REST 资源
需要更改以使统计聚合更灵活
需要一个新的发布计量数据 API
需要一个新的列出计量指标 API

代码变更

代码变更应包括需要更改的内容的概述，并且在某些情况下甚至包括具体细节。

迁移

包括

数据迁移（如果有）
从旧 URL 到新 URL 的重定向（如果有）
如何引导用户使用新的操作方式（如果需要）。

测试/演示计划

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

未解决的问题

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

BoF 议程和讨论

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