Telemetry系统架构
来源:互联网 发布:landesk软件下载 编辑:程序博客网 时间:2024/06/06 02:32
从2015年5月份左右开始接触telemetry,一直期待能够有一张图描述清楚我工作中要面对的整个项目,始终没有找到,经过这段时间的摸爬滚打,也积累了一点点东西,既然网上找不到,我就腆着脸皮做一张,可能有理解不到位甚至错误的地方,还望大家批评指正(图片如果看不清可以右键点击“查看图片”或者类似操作)
总则
telemetry在设计上遵循着一些基本规则,包括:
- 可扩展,基于插件的系统架构
- 内部服务之间通过消息队列进行通信
- 向外提供RESTful API来访问数据
分类
telemetry大大小小包括了不下10个服务,每个服务都有自己的责任,他们中的部分服务一起协调完成一个功能;也有一些是独立于其他服务存在的,下面是telemetry的服务列表
记得大学时候学习计算机科学时,给计算机系统分类,他们真是一群不厚道的人,竟然能搞出好多个分类,按照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系统架构
- 禁用Microsoft Compatibility Telemetry
- Telemetry的项目及主要功能
- 【Consul】Consul实践指导-telemetry
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构
- 系统架构。
- 系统架构
- CocoaPods 导入第三方库头文件自动补齐
- 86. Partition List【M】【48】【leetcode题解】
- Lemon静态链接库
- 第3周-项目3(4)-输出星号图
- tomcat架构分析(概览)
- Telemetry系统架构
- 模型融合技术的两种方法:Bagging Boosting
- 利用CMake管理QT5.5+VTK6.3+ITK4.8+Opencv3.0工程
- getBackground().setAlpha所导致问题
- K折交叉验证中k值大小和bias、variance的关系
- svn 工具conerstone 冲突解决办法
- 内省,BeanInfo
- TCP三次握手
- 冒泡排序思想解析及其实现(java)(1)