《转》 Ceilometer项目源码分析----ceilometer项目源码结构分析

感谢朋友支持本博客,欢迎共同探讨交流,由于能力和时间有限,错误之处在所难免,欢迎指正!

如果转载,请保留作者信息。

博客地址:http://blog.csdn.net/gaoxingnengjisuan

邮箱地址:[email protected]

PS:最近没有登录博客,很多朋友的留言没有看见,这里道歉!还有就是本人较少上QQ,可以邮件交流。

ceilometer主要概念

sample:采样数据是每个采集时间点上meter对应的值;

statistics一般是统计学上某个周期内,meter对应的值(平均值之类);

resource是被监控的资源对象,这个可以是一台虚拟机,一台物理机或者一块云硬盘;

alarm是ceilometer的报警系统,可以通过阈值或者组合条件报警,并设置报警时触发的action,alarm的实现模型有两种,即单例报警系统和分布式报警系统;

meter被跟踪资源的测量值。一个实例有很多的计量值,比如实例运行时长、CPU使用时间、请求磁盘的数量等。在Ceilometer中有三种计量值:

Cumulative: 累计的,随着时间增长(如磁盘读写);

Gauge: 计量单位,离散的项目(如浮动IP,镜像上传)和波动的值(如对象存储数值);

Delta: 增量,随着时间的改变而增加的值(如带宽变化);

central agent运行在OpenStack架构中中央管理节点上用来测量和发送监控结果到收集器的服务;

compute agent运行再OpenStack架构中计算节点上的服务,用来测量和发送监控结果到搜集器中;

API serverCeilometer的HTTP REST API服务;

collector运行在OpenStack架构中的服务,用来监控来自其他OpenStack组件和监控代理发送来的通知,并且将其存入数据库中;

ceilometer中的服务组件

需要说明这里是针对icehouse版对ceilometer模块进行源码解析。根据配置文件setup.cfg以及/ceilometer/cli.py可以知道,运行在ceilometer中的服务组件有如下所示:

ceilometer-api: ceilometer.cli:api

ceilometer-agent-central: ceilometer.cli:agent_central

ceilometer-agent-compute: ceilometer.cli:agent_compute

ceilometer-agent-notification: ceilometer.cli:agent_notification

ceilometer-send-sample: ceilometer.cli:send_sample

ceilometer-dbsync: ceilometer.cli:storage_dbsync

ceilometer-expirer: ceilometer.cli:storage_expirer

ceilometer-collector: ceilometer.cli:collector_service

ceilometer-alarm-evaluator: ceilometer.cli:alarm_evaluator

ceilometer-alarm-notifier: ceilometer.cli:alarm_notifier

ceilometer监控数据采集机制

这里借助网上获取的一副图片来说明ceilometer监控数据的采集机制(对其作者表示感谢):

由上图可以看到,实现监控数据采集的服务组件有三个,分别是ceilometer-agent-central、ceilometer-agent-compute和ceilometer-agent-notification。按照我的理解,监控数据的采集主要分为两种情况实现,一种是服务组件通过相关模块的客户端或者计算节点的Hypervisor实现主动获取相关模块的相关监控数据,一种则是通过收集各个模块推送到oslo-messaging的通知(notification)信息,从中获取有用的监控数据,实现被动地采集相关监控数据。

其中ceilometer-agent-compute的服务组件主要用来收集计算节点上的虚拟机实例的监控数据,在每一个计算节点上都要运行这个服务组件,该agent通过Stevedore管理了一组pollster插件,分别用来获取计算节点上虚拟机的CPU,Disk IO,Network IO,Instance这些信息,这些信息大部分是通过调用Hypervisor的API来获取的,需要定期Poll轮询收集信息。

ceilometer-agent-central服务组件则运行在控制节点上,它主要通过调用相关模块的REST API,通过访问相关模块的客户端,从而实现主动收集相关模块(Image,Volume,Objects,Network)的监控数据,需要定期Poll轮询收集信息。

而ceilometer-agent-notification服务组件则实现访问oslo-messaging,openstack中各个模块都会推送通知(notification)信息到oslo-messaging消息框架,ceilometer-agent-notification通过访问这个消息队列服务框架,获取相关通知信息,并进一步转化为采样数据的格式。从消息队列服务框架获取通知信息,并进一步获取采样数据信息,可以理解为被动获取监控数据操作,需要一直监听oslo-messaging消息队列。

由示意图可以看出,当监控获取完成之后,则会执行信息发布操作,有三种实现方案可供选择,即RPC/UDP/FILE。其中,RPC将会发布相关消息到消息队列,后续的collector组件服务将会监听相应的消息队列来获取这些数据信息;UDP将会建立socket建立一个信息通道,实现发送相关消息数据,而后续的collector组件服务将会通过这个信息通道接收相关的消息数据;FILE将会直接保存相关消息数据到指定的日志文件中。

由示意图可以看出,当信息发布操作完成之后,collector组件服务将会分别获取相关的消息数据,并实现保存获取的消息数据到数据存储系统中。而数据存储系统方案目前也支持几种实现,即log/mongodb/mysql/postgresql/sqlite/hbase/db2等;

其他服务组件的介绍

ceilometer-alarm-notifier 加载并启动AlarmNotifierService服务,实现报警器被触发的相关通知服务;

ceilometer-alarm-evaluator 实现加载并启动报警服务,ceilometer中实现的系统报警服务有两种,即单例报警系统SingletonAlarmService和分布式报警系统PartitionedAlarmService,而ceilometer默认应用的是SingletonAlarmService;对于报警系统相关的内容,我将会在另外一篇博客中进行详细的分析;

I版ceilometer项目源码结构

/ceilometer/alarm 报警系统的实现;

/ceilometer/api 提供REST API服务;

/ceilometer/central ceilometer-agent-central的具体实现

/ceilometer/compute ceilometer-agent-compute的具体实现

/ceilometer/dispatcher 用于实现保存数据到数据存储系统;

/ceilometer/energy 通过kwapi架构,获取物理机能耗相关信息数据;

/ceilometer/event Ceilometer Events

/ceilometer/hardware 获取物理机硬件的相关监控数据信息;

/ceilometer/image 实现通过客户端访问glance模块,获取相关的监控数据信息;

/ceilometer/network 实现通过客户端访问Neutron模块,获取相关的监控数据信息;

/ceilometer/objectstore 实现通过客户端访问swift模块,获取相关的监控数据信息;

/ceilometer/openstack 通用应用代码工具;

/ceilometer/orchestration 通过Heat的通知信息获取相关监控项的采样数据信息;

/ceilometer/publisher 收集到的监控数据的发布实现;

/ceilometer/storage 存储监控数据到数据存储系统的实现;

/ceilometer/transformer 数据转换

/ceilometer/volume 实现通过客户端访问cinder模块,获取相关的监控数据信息;

/ceilometer/agent.py Ceilometer通过Agent模块去polling虚拟机或者OpenStack中需要的信息;

/ceilometer/cli.py 实现若干服务组件的启动;

/ceilometer/collector.py 实现发布的监控数据的收集;

/ceilometer/middleware.py HTTP相关插件实现;

/ceilometer/notification.py 通过oslo-messaging框架,监听compute/image/network/heat/cinder等服务的队列,来获取相关的通知信息;

/ceilometer/notifier.py 根据不同的插件实现Instance/Image/Network/Volume/HTTPRequest中的具体方法process_notification,用来从通知中获取监控项的采样数据信息;

/ceilometer/nova_client.py nova客户端;

/ceilometer/pipeline.py pipeline实现;

/ceilometer/plugin.py 插件实现基类;

/ceilometer/sample.py 根据已知的采样数据形成Sample格式;

/ceilometer/service.py 服务实现相关;

/ceilometer/utils.py 若干通用工具;

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-09 06:47:01

《转》 Ceilometer项目源码分析----ceilometer项目源码结构分析的相关文章

【E2LSH源码分析】E2LSH源码综述及主要数据结构

上一小节,我们对p稳定分布LSH的基本原理进行了介绍(http://blog.csdn.net/jasonding1354/article/details/38237353),在接下来的博文中,我将以E2LSH开源代码为基础,对E2LSH的源码进行注解学习,从而为掌握LSH的基本原理以及未来对相似性搜索的扩展学习打下基础. 1.代码概况 E2LSH的核心代码可以分为3部分: LocalitySensitiveHashing.cpp--主要包含基于LSH的RNN(R-near neighbor)数

cocos2d-x 源码分析 : control 源码分析 ( 控制类组件 controlButton)

源码版本来自3.1rc 转载请注明 cocos2d-x源码分析总目录 http://blog.csdn.net/u011225840/article/details/31743129 1.继承结构 control的设计整体感觉挺美的,在父类control定义了整个控制事件的基础以及管理,虽然其继承了Layer,但其本身和UI组件的实现并没有关联.在子类(controlButton,controlSwitch,controlStepper等中实现不同的UI组件).下面通过源码来分析control与

cocos2d-x 源码分析 之 CCTableView源码分析(附使用方法讨论)

cocos2d-x源码总目录 http://blog.csdn.net/u011225840/article/details/31743129 源码来自2.x,转载请注明 1.继承结构 首先来看下CCTableView的继承结构 从继承结构上看,CCTableView是一种CCScrollView,所以为了研究CCTableView的源码,清先去了解CCScrollView的源码http://blog.csdn.net/u011225840/article/details/30033501. 其

【JDK源码分析】通过源码分析CyclicBarrier

前言 CyclicBarrier它是什么?一个同步辅助类,它允许一组线程互相等待,直到到达某个公共屏障点.类似于朋友之间联系要在中午聚个会,几个朋友全部到齐后才开始喝酒吃菜. 源码 CyclicBarrier属性和构造器 public class CyclicBarrier { // 互斥锁 private final ReentrantLock lock = new ReentrantLock(); // 条件等待 private final Condition trip = lock.new

dubbo源码分析系列——项目工程结构介绍

摘要 dubbo是目前国内最流行的分布式服务框架,已经俨然成为行业的标准了,多数无自研能力的公司都在使用这个框架,而且这个框架本身非常具有代表性,即使很多公司自研的分布式服务框架也都是对dubbo的扩展或者借鉴了该框架,因此研究它的源码意义还是非常大的,对于掌握分布式服务框架的原理和实现细节有着非常好的帮助. 项目源码地址 本系列文章是基于当当网维护的dubbox版本进行分析的,源码地址参考:https://github.com/dangdangdotcom/dubbox 项目源码结构 我们下载

【MyBatis源码分析】select源码分析及小结

示例代码 之前的文章说过,对于MyBatis来说insert.update.delete是一组的,因为对于MyBatis来说它们都是update:select是一组的,因为对于MyBatis来说它就是select. 本文研究一下select的实现流程,示例代码为: 1 public void testSelectOne() { 2 System.out.println(mailDao.selectMailById(8)); 3 } selectMailById方法的实现为: 1 public M

Java多线程 -- JUC包源码分析11 -- ThreadPoolExecutor源码分析

在JUC包中,线程池部分本身有很多组件,可以说是前面所分析的各种技术的一个综合应用.从本文开始,将综合前面的知识,逐个分析线程池的各个组件. -Executor/Executors -ThreadPoolExecutor使用介绍 -ThreadPoolExecutor实现原理 –ThreadPoolExecutor的中断与优雅关闭 shutdown + awaitTermination –shutdown的一个误区 Executor/Executors Executor是线程池框架最基本的几个接

spring事务源码分析结合mybatis源码(一)

最近想提升,苦逼程序猿,想了想还是拿最熟悉,之前也一直想看但没看的spring源码来看吧,正好最近在弄事务这部分的东西,就看了下,同时写下随笔记录下,以备后查. spring tx源码分析 这里只分析简单事务也就是DataSourceTransactionManager 首先肯定找入口了,看过spring源码的同学一定都会找spring tx的入口就是在TxAdviceBeanDefinitionParser这里将解析tx的配置,生成TransactionInterceptor对象,这个也就是一

【JDK源码分析】通过源码彻底理解ReentrantLock显示锁

前言ReentrantLock和synchronized一样是一个可重入的互斥锁,但ReentrantLock功能更强大,它提供了非公平和公平两种锁争用策略供使用者选择,而synchronized只有非公平一种.ReentrantLock提供了可中断的锁等待机制以及可用于多组线程需要分组唤醒的条件. 类图下面是ReentrantLock的类图,内部抽象类Sync继承了AbstractQueuedSynchronizer(以下简称AQS),公平锁FairSync.非公平锁NonfairSync继承