part one：理解

part two：实战

One：

0. namespace entry point,这个在源代码里面setup.cfg里面会详细体现，Ceilometer中数据的采集以及数据的处理等任务都可以从这些entry point list清晰看出，这也充分体现Ceilometer架构的灵活性。

1. message queue的理解，openstack每个项目内部进程之间都是利用queue来协作。在开始学习queue之前，当然有很多类queue，这里特指rabbitmq，网络上有篇兔场养兔的文章非常经典，很值得一看。也值得提一下可能有与社区积极推动和rabiitmq本身优秀特性有关，rabbitmq在openstack世界里面占据着大半江山。

2. 关于Ceilometer本身收集数据两种方式的理解，一是collector-agent，通常处理openstack像glance、nova等组件的notification信息，还有就是处理一些rpc调用（比如record_data到数据库里面），在icehouse以后的版本中，会把collector-agent中notification和rpc分为两个独立的agent；二是central-agent，这中方式和collector不太一样，central-agent调用openstack中其它组件的client直接从各自组件数据库中获取，相当于api直接获取。

Two: （publisher： 0 + consumer： 1，2）

举一个关于switch监控项目的扩展，主要是通过switch send notification的方式来实践。

(可以把switch当作一个类似glance或nova同等单独的模块,或者放在neutron里面,这里只是举例说方法)

0. 在switch端里面实现好自己的消息发送方法(主要是用kombu +　rabbitmq ). 消息的publiser一定注意exchange和topic的名字,如果是继承openstack.common.rpc的话,由于利用kombu封装的接口, exchange name是读取类似neutron.conf里面的exchangename，而topic name也可以类似方式。还有就是发送的消息格式，咱们可以在ceilometer的colletor打下消息的log可以看出event msg和rpc msg格式是不一样的。这里用event msg来发送监控信息。

1. 在setup.cfg里面(类redhat系列linux安装Ceilometer后，会在Ceilometer-****ege目录下面有entry_point.txt文件)添加需要扩展的监控项，

[entry_points]

ceilometer.collector =

...

myswitch.incoming.bytes = ceilometer.network.notifications:MyswitchInBytesPollster

myswitch.outgoing.bytes = ceilometer.network.notifications:MyswitchOutBytesPollster

2.在上面加了两个任务，需要在Ceilometer.network.notifications里面加入MyswitchInBytesPollster和MyswitchOutBytesPollster两个class,这两个类主要做作的事是处理交换机那端发过来的消息转换成sample格式, 处理好后再由collector再次发送给自己处理成metering格式，然后就是存数据库。这两个class的实现可以参考

classNetworkNotificationBase(plugin.NotificationBase)，特别要注意event_types

的定义，要不然在ceilometer/collector/service.py classCollectorService(CollectorBase,rpc_service.Service):里面能收到消息，

但是一直都无法记录到database里面。

然后就是在数据库里面就能select到咱们要监控的数据了，小激动...-_-|||...

part two: contd

上面part one中有提到利用ceilometer central-agent来监控数据，其实这种方式比上面讲到colletor的方式要简单很多，不需要考虑publisher消息发送格式，应该是根本就没有publisher。当然前提是得在switch或者咱们的component里面以及把监控的数据记录到该component的数据库里面了。然后主要的工作就是在ceilometer这端，这里的实现方式和前面提到的blog link讲的差不多。 

switch作为一个单独的componet或者集成到neutron里面，在这里就不深入讲了。

0. entry_point 任务的添加，这种实现方式添加的地方就不同了

 [entry_points]

ceilometer.poll.central=

myswitch.incoming.bytes = ceilometer.network.myswitch:MyswitchInBytesPollster

myswitch.outgoing.bytes = ceilometer.network.myswitch:MyswitchOutBytesPollster

1. 在ceilometer/network/myswitch.py里面实现MyswitchInBytesPollster，MyswitchOutBytesPollster.这两个class主要是利用componet

提供的client api来获取数据再封装成一定的格式，这里需要注意的格式在前面有提到，直接metering消息格式存储到DB里面。

这下更加激动了， so easy....

其实两种实现方式的代码都比较简单，但是如果有部署经验的人都知道，central-agent可能算ceilometer的一个硬伤，multi-node甚至multi-region部署的话，对数据库的压力也是不小的（这点可以仁者见仁）。当然colletor-agent的方式也有弊端，queue的压力或者软件的耦合性（也可以智者见智）。