ceilometer基础介绍

Celiometer
1、基础介绍
1.1用途
Ceilometer是Openstack子项目，为计费和监控提供服务所需数据。
计量:获取用户对资源使用情况 。监控：确保资源处于健康状态。

2.2框架
整体处理过程:
计算节点代理，控制节点代理等主动调用API将收集的信息(COU,IO)发送到通知总线，而通知代理是由openstack组件将信息推送到通知总线，MessageBus将信息发送给Pipeine,经过处理后，发送给Collector收集器，收集器将信息存储到Metrics,Events。 报警程序将报警结果存储到Alarms，并产生相应动作(发短信，邮件).




设置cinder/neutron/galance/nova为组件
组件 -----push---→AMQP--→agent-notification-------
组件(API)<--poll--Pollsters agent-central---------
VM(Hypervisor)←--poll---Pollsters agent-compute--
发给Pipeline
Pipeline(transmeters publishers)
publish
{RPC -→message queue 绑定实例 ----
{UDP --→端口-----→ --------------   Collector --------Storage
{File --→File log->--------------


2.2监控项
meter:监控项，如内存占用，网络IO，磁盘IO。被跟踪资源测量值，如实例运行时间，请求磁盘数量
三种计量值：
Cumulative累计的：随时间增长(磁盘读写)
Gauge:计量单位，离散的(浮动ip，镜像上传)和波动值(对象存储数值)
Delta:增量，如带宽变化。

sample:某时刻监控项的值
statistics:某周期的监控项平均值
resource:被监控资源，如虚拟机，物理机，云硬盘
alarm:报警机制，通过阈值或组合条件报警,设置报警触发action

ceilometer对收集信息定义为event和sample。
Event:发生的事情，例如instance.create


2数据采集机制
2.1采集过程
采集的组件：计算节点代理，控制节点代理，通知代理，信息收集器
采集过程： agent*服务采集信息，通过RPC/UDP/File发送给收集器，收集器写入到数据库。
Agent-notification:收集组件推送到oslo-messaging[openstack消息队列框架]的消息.
Agent-compute:收集虚拟机CPU内存IO，需要安装在管理程序Hypervisor机器上
Agent-central:通过组件API收集信息
Agent-compute和Agent-central是Poll轮询收集信息
collector:将信息持久化到存储，支持mysql,DB2,HBase,mongoDB。收集到的信息经过存储首相曾，存储到对应数据库中，每个数据库后端在同一时间仅能使用一个。

补充：
通过stevedore插件来在采集项，利用setuptools的entry_points.
带宽采集：是通过neutron-meter-agent收集，发送到oslo-messaging。
流量计算是用iptables。
硬件采集:如kwapi(物理机耗电),snmp(简单网络管理协议)收集硬件CPU,IO等

2.2发布过程
发布器:
RPC:将信息以payload发布到消息队列，收集器监听队列收集信息，存储到介质
UDP:通过端口创建数据通道，收集器绑定到端口接受数据
File:将采集数据以filelog写入日志
pipline:决定发布信息的方式，/etc/ceilometer/pipline.yaml中的publishers配置。 



3 Pipeline数据加工
关于Pipeline数据加工
管道线实现：数据处理链。将多个转换器Transformers组装成数据处理链，链的末端装配Publisher。
加工方式。


4报警机制
4.1报警机制介绍
原理：监控一个或多个指标，若高于或低于阈值，就执行动作(发邮件，短信，autoscaling启动或关闭实例)
报警种类：1阈值threshold报警，2组合combination报警。
阈值报警：针对监控指标的阈值进行报警
组合报警：根据多个指标建立报警，如or,and关系,一般用于自动启动或关闭实例

报警信息：项目id,报警状态执行动作，阈值报警规则，组合报警规则，当前状态等。
阈值报警规则：监控指标，比较规则，获取指标数据的时间范围

报警组合规则： 定义报警项之间逻辑关系(and or)，报警项列表
报警时间约束：报警检查开始时间，持续时间等

4.2报警机制的实现
单进程报警服务:处理能力弱
分布式报警服务:通过rpc实现多个evaluator进程协作协议PartitionCoordinator，水平扩展来增大alarm service处理能力。

PartitionCoordinator:
原理：允许启动多个ceilometer-alarm-evaluator进程(报警求值程序)，最早启动的作为master进程，给其他进程分配alarm。每个进程执行：广播状态，抢夺master,执行alarm
1 通过rpc向其他进程广播自己状态，表明进程活着
2抢夺master,更新自己维护的其他进程状态列表，判断自己最先启动成为master
3执行alarm,调用ceilometer的api获取数据，判断，报警

负载平衡原理：
1 新alarm创建，平均分配给worker进程
2 新evaluator进程添加，把所有alarm分配给现有evaluator进程
3 master挂了，选择次最早进程

4.3存在的问题：
1每个alarm检查间隔60s.数量多，压力很大
2 alarm和ceilometer关系，alarm在ceilometer中，但并无紧密关系
3 alarm和billing使用同一数据库有安全隐患


5存储机制
5.1Gnocchi介绍
Gnocchi是多租户时间序列，计量和资源数据库。
用于：存储时间序列和关联资源数据
1）计费系统存储，2）报警触发或监控系统
架构：HTTP REST API，statsd守护程序 用于接受数据
异步处理守护程序对数据统计等操作。
后端：两个。存储时间序列，索引数据。
索引器：存储资源索引，类型，属性
存储器：存储度量的计量值，接受时间戳和值，根据归档策略计算聚合。

5.2Gnocchi的特点
快速：
检索时间复杂度O(1)
资源可以通过合理的数据类型被设置索引
支持并发写。
插件化：
索引驱动：推荐PostgreSQL,MySQL
存储驱动:文件,swift,Ceph
定制化集成功能
可以在Keystone或者非Keystone下工作



5.2 主要模块:
Indexer:存储资源索引，度量链接的资源
Storage:存储创建计量的方式，计量的类型和属性
如: Metric foobar,cpu.util等，为Indexer中的资源实例提供

Gnocchi模块和数据关系

Gnocchi支持的后端存储技术
File ,Swift, S3
Ceph(优先)：提供更好的数据一致性
不能处理时间序列数据，引入Carbonara处理时间序列



5.3归档策略
归档策略：保存数据例如每天5分钟，确定如何聚合
平均聚合，最小化和最大化聚合
时间序列是点的集合，
时间序列大小=点数* 8字节
点数=时间跨度 / 粒度
粒度:比如每一分钟统计一次

如何设置归档策略和计量粒度:
典型的： 1440点，粒度一分钟=24小时
默认归档策略：
low:metric最大估计大小: 5KB ,5分钟粒度1小时，1小时粒度1天，一天粒度超过1个月。
之所以查询时间快是因为按照归档策略预先处理

6其他