从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等

Telemetry系统架构相关推荐

OpenStack Telemetry系统架构及实践
1. 概述早期OpenStack的计量功能由Ceilometer项目负责,后来Ceilometer一分为四,每个项目负责一个方面的工作.不得不说这是OpenStack开发中的一个特色,比如Cinde ...
系统架构升级要不要上微服务？历“久”弥新微服务——你真的需要升级微服务架构吗
在 <微服务架构设计模式> 一书中,作者总结了关于微服务的一些"重点",原文如下: 中国企业和开发者对微服务架构的热情让我印象深刻.但如同我给所有客户的忠告一样,我想对 ...
商品详细信息的代码html_电商网站的商品详情页系统架构
小型电商网站的商品详情页系统架构小型电商网站的页面展示采用页面全量静态化的思想.数据库中存放了所有的商品信息,页面静态化系统,将数据填充进静态模板中,形成静态化页面,推入 Nginx 服务器.用户浏 ...
大型网站采用什么系统架构保证性能稳定性
from http://www.bobd.cn/design/web/Theory/200904/31145.html 千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用 ...
系统架构的过程浮现式设计
系统架构如果设计之初就设计错了,那么必然是南辕北辙. 很多人做系统设计总是东一下,西一下,杂乱无章,想到那是那,然后系统的边界很大,总会有疏漏. 那么系统架构应该怎么设计呢? 首先来说分层系统分为三 ...
centos5.6 (64bit)编译安装vsftpd-2.3.4的配置(两种用户登录)[连载之电子商务系统架构]...
centos5.6 (64bit)编译安装vsftpd-2.3.4的配置(两种用户登录) 出处:http://jimmyli.blog.51cto.com/我站在巨人肩膀上Jimmy Li 作者:Ji ...
说说大型高并发高负载网站的系统架构【转】
我在CERNET做过拨号接入平台的搭建,而后在Yahoo&3721从事过搜索引擎前端开发,又在MOP处理过大型社区猫扑大杂烩的架构升级等工作,同时自己接触和开发过不少大中型网站的模块,因此在大 ...
型网站的架构设计问题----大型高并发高负载网站的系统架构
随着中国大型IT企业信息化速度的加快,大部分应用的数据量和访问量都急剧增加,大型企业网站正面临性能和高数据访问量的压力,而且对存储.安全以及信息检索等等方面都提出了更高的要求-- 本文中,我想通过几个 ...
17张图揭密支付宝系统架构
支付宝的系统架构图,仅供参考.不管是不是支付行业,都值得我们参考,学习. image image image image image image image image image image ima ...
转:秒杀系统架构分析与实战
原文出处: 陶邦仁欢迎分享原创到伯乐头条 0 系列目录秒杀系统架构秒杀系统架构分析与实战 1 秒杀业务分析正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单: ...

Telemetry系统架构

总则

分类