旧设计页面

此页面曾用于帮助设计 OpenStack 早期版本的一个特性。该特性可能已经或尚未实现。因此，此页面可能不会更新，并且可能包含过时的信息。上次更新时间为 2014-05-15

New Ceilometer Agent

我想提出一个新的、更简单的 Ceilometer 代理，基于 StackTach 模型。

现有代理框架存在的问题

需要在计算节点上部署自定义的通知驱动
- 我认为目前计算代理只检查实例信息，没有通知机制。--yjiang5
  - 我不确定你是什么意思，能详细说明一下吗？我说的是这个： https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/nova_notifier.py --S
使用一种迂回的方式，通过 api 层（需要一个 api 扩展）来获取 hypervisor 数据
需要在每个计算节点上显式部署。
- 我不确定我们是否可以避免在计算节点上部署，例如，我们可能需要收集主机利用率信息，甚至热信息。-- yjiang5
  - 对于 90% 的情况，我们可以不使用代理来完成（包括主机利用率）。如果热信息来自运行在 hypervisor 上的其他服务（并且没有 RPC API），那么是的，我们需要一个计算端代理。你指的是从 libvirt api 获取的热信息吗？如果是这样，我们可以从标准的 virt 层接口获取的任何信息都可以通过通知暴露出来。--S
混合轮询（periodic_task）和通知跟踪来获取数据
- 我记得现在通知/轮询在不同的代理中。-- yjiang5
  - 查看上面的文件，它似乎共享 AgentManger。除非我错过了什么？--S
    - 它们共享一个基类，仅此而已。-- dhellmann
    - CollectorService 将 periodic_tasks 定义为 pass。因此，通知中没有周期性工作。这是由于继承了 PeriodicService 类造成的。--ronghui
不会跟踪所有通知，只选择其中的一些，并且只在 .info 队列上（.error 被忽略）
- 这很容易修复现有的代码。-- dhellmann

这个新模型将解决所有这些问题

工作者可以部署在 openstack 网络上的任何地方。
一个工作者部署可以支持多个 cells/部署。
不需要 api 扩展
不需要在计算节点上部署。
- --如上所述，我不确定我们是否可以避免这一点。-- yjiang5
  - 也许在非常有限的情况下，但我很想知道这些用例的具体细节。--S

这个模型已经在 Rackspace 部署并正常工作。

替换策略包括以下内容

在与 Xen 相同的监控机制下支持 KVM（Nova 在 Virt 层已经支持）
确保现有的 Usage 机制与 KVM 协同工作。
并行开发新的工作者与现有的 CM Agent。现有策略不会被更改。
一旦我们拥有现有代理的 100% 功能覆盖，我们就可以讨论放弃旧的代理。
初始部署将假定
- 现有的 stacktach 日志和配置机制
- 仅支持 RabbitMQ
后续部署将
- 使用 Oslo 替换日志/配置信息
- 使 AMQP 机制基于驱动程序，和/或更新 Oslo 以支持通知式事件

可以从这里看到现有 StackTach 工作者的构建方式： http://www.youtube.com/watch?v=thaZcHuJXhM

反对意见

我们听到的关于采用完全基于通知的机制的一些论点是

服务中 periodic_task 机制的不可靠性。
- 提案：找到并修复这些延迟
  - --我认为这已经在邮件列表中讨论了很多次，我们也可以注意到已经有人在努力解决这个问题 (http://lists.openstack.org/pipermail/openstack-dev/2013-January/004491.html)，但我不知道是否容易修复。我同意 Nick 和 Hellman 的观点，我们需要一个可用的东西。从长远来看，我对此没有异议。-- yjiang5
    - 同意。我们现在不想替换所有东西并导致下一个版本出现问题。但是，我也推动不要过度扩展当前的机制，而是考虑将我们的精力投入到一个更简单的框架中。--S
并非所有服务都支持通知（例如，Swift）
- 提案：与那些 openstack 团队合作，以获得适当的通知支持
通知不适合高速监控。
- 提案：同意。为这些事件创建一个基于 UDP 的通知驱动程序，并使用像 statsd 这样高效的聚合器。--长期同意。-- yjiang5

这些都是相对简单的修改。

NewCeilometerAgent

New Ceilometer Agent

反对意见