Telemetry系统架构

从2015年5月份左右开始接触telemetry，一直期待能够有一张图描述清楚我工作中要面对的整个项目，始终没有找到，经过这段时间的摸爬滚打，也积累了一点点东西，既然网上找不到，我就腆着脸皮做一张，可能有理解不到位甚至错误的地方，还望大家批评指正(图片如果看不清可以右键点击“查看图片”或者类似操作)

总则

telemetry在设计上遵循着一些基本规则，包括：

可扩展，基于插件的系统架构

内部服务之间通过消息队列进行通信

向外提供RESTful API来访问数据

分类

telemetry大大小小包括了不下10个服务，每个服务都有自己的责任，他们中的部分服务一起协调完成一个功能；也有一些是独立于其他服务存在的，下面是telemetry的服务列表

服务名称	脚本入口	主要责任
ceilometer-agent-compute	ceilometer.cmd.polling:main_compute	从计算节点上采集虚拟机的使用情况相关的信息，例如：已使用内存、cpu利用率等
ceilometer-agent-central	ceilometer.cmd.polling:main_central	通过openstack 其他server的RESTful API获取相关资源的信息，例如：image.size从glance api获取镜像的size
ceilometer-agent-ipmi	ceilometer.cmd.polling:main_ipmi	获取当前宿主机的相关信息
ceilometer-agent-notification	ceilometer.cmd.agent_notification:main	从消息队列中获取其他服务发送的通知消息并转换成sample或者event
ceilometer-collector	ceilometer.cmd.collector:main	从消息队列中收集前四个服务采集到的数据持久存储
ceilometer-dbsync	ceilometer.cmd.storage:dbsync	主要负责数据库的管理，例如升级、降级
ceilometer-expirer	ceilometer.cmd.storage:expirer	跟crontab结合定期清理数据库中过期的数据，需要结合配置文件中的：metering_time_to_live，event_time_to_live，默认都是-1，永不过期
ceilometer-api	ceilometer.cmd.api:main	对外提供的RESTful API，访问telemetry采集到数据的唯一入口
ceilometer-alarm-evaluator	ceilometer.cmd.alarm:evaluator	根据ceilometer-api中alarms设置的监控策略和采样数据的统计结果进行评估，评估结果又三种：数据不足、正常、告警
ceilometer-alarm-notifier	ceilometer.cmd.alarm:notifier	当告警评估状态变化时，会忘消息队列中发送一条消息，有ceilometer-alarm-notifier接收处理

记得大学时候学习计算机科学时，给计算机系统分类，他们真是一群不厚道的人，竟然能搞出好多个分类，按照A标准分A1、A2、A3几种，按照B标准分B1、B2、B3、B4几种，这对那时候的我们真的有用吗？也许是有用的，但也可能没用，反正对我是没用，因为我连计算机是什么都搞不清楚，你跟我讲分类？

telemetry的目标在前一篇《Telemetry—简述 》中提到：“为收集openstack关心的信息提供基础设施；成为一种采集数据的标准方法，而不管使用数据的目的”，那数据采集是少不了的了，但有句话说：“酒足饭饱思淫”，在数据采集做到比较完善之后，总会想着往上层做一些事情，监控告警就是telemetry在比较完善之后的一个向上扩充

数据采集

数据采集有两种方式：由telemetry的服务主动发起的轮询和被动监听消息队列。在Kilo版本中对于轮询部分的服务做了一个合并，可以从ceilometer-polling服务启动，根据传输的参数不同而成为较旧版本的ceilometer-agent-compute、ceilometer-agent-central或者ceilometer-agent-ipmi，轮询的服务的流程大致是：

扫描指定命名空间下包含的pollster，ceilometer-agent-compute的命名空间为：ceilometer.poll.compute，ceilometer-agent-central的命名空间为：ceilometer.poll.central，ceilometer-agent-ipmi的命名空间为：ceilometer.poll.ipmi，在setup.cfg中可以看到个命名空间下的pollster

每个pollster都有一个default_discover，在setup.cfg的ceilometer.discover命名空间下可以找到每个discover的定义，discover负责指定pollster要轮询的资源。比如ceilometer-agent-compute的default_discover为local_instances，通过host获取指定节点上的虚拟机

采集到的数据根据meter_name放到指定的pipeline，pipeline的transformer负责转换数据，publisher负责将转换后的数据发布到消息队列

到此，轮询的工作结束。轮询的几个服务的区别在于采集数据的对象不同，可以参照上表中的主要责任列

除了主动轮询外，openstack系统中其他服务可能会有各种各样的数据上报，他们的做法是将数据（带有event_type）发送到消息队列，ceilometer-agent-notification服务一直监听消息队列，碰到感兴趣的event_type（例如：compute.instance.*）时用对应的类（例如：memory = ceilometer.compute.notifications.instance:Memory）对该消息处理转换为sample或者event

数据存储

数据采集中的服务，将sample经过pipeline的处理转换然后通过publisher发布到消息队列，ceilometer-collector将消息队列中的数据进行永久存储到指定的存储设备（dispatcher）上，例如默认的database = ceilometer.dispatcher.database:DatabaseDispatcher，当然还可以是file = ceilometer.dispatcher.file:FileDispatcher或者http = ceilometer.dispatcher.http:HttpDispatcher

数据访问

ceilometer-api作为外部访问telemetry采集数据的唯一接口，满足RESTful

数据管理

在数据库之上，有两个服务负责数据库的维护工作

ceilometer-dbsync，负责数据库的升降级

ceilometer-expirer，需要根据配置文件中的time_to_live配置项做处理，time_to_live是指记录在持久存储中保留的时间，一般ceilometer-expirer需要跟crontab配合，定期清理掉超过time_to_live指定期限的记录

告警系统

在telemetry中，有一个使用ceilometer-api的实例—告警系统，告警系统由两个服务组成：

- ceilometer-alarm-evaluator，负责告警的评估，在ceilometer-api中提供了创建基于阈值的Alarm（Threshold）和组合Alarm（Combination），在Kilo版本里面还有其他的几种Alarm，ceilometer-alarm-evalutor根据设置的规则，通过ceilometer-api获取统计数据跟阈值进行对比得出评估的结果：数据不足、正常或者告警，触发状态变化时将本次状态变化的信息发送到消息队列

- ceilometer-alarm-notifier，一直监听消息队列，接收到ceilometer-alarm-evaluator发送的消息之后进行解析根据消息的指示（scheme）将消息分发到具体的notifier，例如：log = ceilometer.alarm.notifier.log:LogAlarmNotifier；http = ceilometer.alarm.notifier.rest:RestAlarmNotifier等