声明：下文大部分内容参见Ceilometer官网文档

https://docs.openstack.org/developer/ceilometer/
另有部分内容参考了几个blog，具体地址忘记了，对这些作者表示感谢。
 

Ceilometer技术介绍

1、基础介绍

1.1用途

Ceilometer是Openstack子项目，为计费和监控提供服务所需数据,确保资源健康。包含计量metering，计费rating，结算billing。
metering:计量，收集资源使用数据
rating:计费，资源使用数据按照商务规则转化为可计费项目并计费
billing:结算，收钱开票
 

1.2基础概念

ceilometer对收集信息定义为event和sample。Event:发生的事情，例如instance.create。
agent: 一种服务，运行在OpenStack架构上，衡量使用量并根据publishers发送结果到任意数量的目标上
API Server:为ceilometer提供的基于http的 rest api
bus listener agent:总线监听代理，将Oslo通知总线上生成的事件转化为Ceilometer的Sample采样值。
Ceilometer:计量/计费系统
polling agent:轮询代理，运行在控制节点或者计算节点，用于衡量使用量并
且将结果发送到队列。
Notification agent:不同的OpenStack组件会针对不同的事件类型发送几个通知。
通知代理会从各自的队列中获取并按照时间类型对它们过滤。
Data store:存储系统会将收集的数据存储
meter:监控项。比如CPU使用时间。包含三种类型
    1）Cumulative:累积的，例如磁盘吞吐量
    2）Gauge:离散的，比如上传的镜像大小
    3）Delta:增量，如带宽
metering:监控是信息收集过程
sample:某时刻监控项的值
statistics:某周期的监控项平均值
resource:被监控资源，如虚拟机，物理机，云硬盘
alarm:报警机制，通过阈值或组合条件报警,设置报警触发action
notification:通过外部的Openstack系统发送的信息，例如Nova,Glance。使用Oslo消息机制。这些消息会被Ceilometer通过RPC driver的notifier接收到。
Project:OpenStack的tennat租户或者project
publisher:发布者，将采样值发布到指定目标
push agents:推送代理，获取项目中的数据
 

2系统架构

架构特点：支持水平扩展，可以添加额外的workers和节点。

两个核心的服务:
1) polling agent:轮询代理，守护进程，轮询OpenStack各项服务并建立监控项。
2) notification agent:通知代理，守护进程，监听消息队列的通知，并将它们转化为事件和采样值，并且应用到管道pipeline动作。
采集的数据会被Ceilometer发送到不同的目标。
Gnocchi用于将捕获到的测量数据以时间序列的格式来优化存储和查询。Gnocchi被用于来替换现有的已经存在的监控数据库接口。
Aodh是报警服务，可以以指定的规则发送警告给用户。
Panko是事件存储项目，用于捕获文档格式的数据，例如日志和系统事件操作。
计算节点代理，控制节点代理等主动调用openstack组件的API将收集的信息(CPU,IO)发送到通知总线，openstack组件将信息推送到通知总线，通知代理监听oslo消息框架并获取信息处理后再发送到通知总线，MessageBus将信息发送给Pipeine,经过处理后，发送给Collector收集器，收集器将信息存储到Metrics,Events。 报警程序将报警结果存储到Alarms，并产生相应动作(发短信，邮件)。

 

3数据采集机制   

3.1采集数据方式。

1) Notification agent通知代理:将生成的消息通过消息总线Notification bus，并且转换为Ceilometer采样值或者事件。这是主要的收集数据的主要方式。

2)Polling agents:轮询代理，并不是主要的方法，将会轮询一些API或者工具来周期性收集数据。轮询方式不是主要的，因为加载该服务需要强加到某些API服务中。
第一种方法被ceilometer的通知代理所支持，监控消息队列中的通知。
轮询代理可以被配置成去轮询本地的管理程序hypervisor(虚拟机)，或者API，和本机中的SNMP/IMPI守护进程。
 

3.1.1通知代理notification-agent    

通知代理会处理来自服务的数据。系统的核心是通知守护进程，可以监控Openstack组件发送的消息队列的数据，例如Nova,Galance,Cinder,Neutron,Swift,Keystone,Heat,Ceilometer内部通讯。
通知守护进程加载一个或多个监听插件，使用命名空间 ceilometer.notification。每一个插件可以监听任何主题，但是默认会监听notification.info,notification.sample,notification.error。
监听器会抓取配置主题topics中的信息，并重新分发它们到正确的插件中，最后处理变成Events和Samples。
采样插件Sample-oriented plugins提供一种方法会列出所有它们感兴趣的事件类型，并采用对应的回调函数来处理。
注册的回调函数名称被用于开启或禁止使用通知守护进程的pipeline。
还未被传送到回调函数的即将到来的信息会根据事件类型的值被过滤，因此插件只会接收到它感兴趣的事件。

3.1.2轮询代理Polling Agents

轮询计算节点资源信息的代理叫做compute-agent。轮询控制节点资源的代理叫做central-agent。
轮询代理被配置为可以在1个或多个pollster plugins中使用以下任意组合的命名空间。
Ceilometer.poll.compute,ceilometer.poll.central,ceilometer.poll.impi。
轮询的频率是通过pipeline来配置的。代理的框架将会产生采样值给通知代理处理。

3.1.3数据处理

1）管道控制器Pipeline Manager



管道线Pipeline:是由一些列的转换器transformers将数据转换成发布者知道如何发送给外部系统的事物。
Ceilometer提供了功能可以将通过代理收集到的数据进行操作后，然后发布到多个不同的管道组合中。
一个管道功能的例子：将T,T+1,T+2时间点收集到的CPU使用率经过处理后，计算这段时间平均CPU使用率。

2）发布数据



将Sample通过:
1)Gnocchi Publisher存储到Gnocchi数据库
2)oslo.messaging Publisher:通过AMQP的签名消息发送到外部系统，例如监视器，统计，容量等。

3.1.4存储/获取数据 

数据被发布到任意目标中，参见Publishers章节。推荐的工作流是将数据推送到Gnocchi，一种高效的
事件序列存储并可追踪资源生命周期。
已经存在的监控项:参见
https://docs.openstack.org/admin-guide/telemetry-measurements.html
添加新的监控项：参见
https://docs.openstack.org/developer/ceilometer/new_meters.html#add-new-meters

4报警机制

4.1报警机制介绍

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

报警信息：项目id,报警状态执行动作，阈值报警规则，组合报警规则，当前状态等。
报警规则：
1）阈值报警规则：监控指标，比较规则，获取指标数据的时间范围
2）报警组合规则： 定义报警项之间逻辑关系(and or)，报警项列表
报警时间约束：报警检查开始时间，持续时间等
 

4.2报警机制的实现

报警机制分为：单线程报警服务和分布式报警服务
1）单进程报警服务:处理能力弱
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 Gnocchi  

5.1Gnocchi介绍

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

5.2Gnocchi的特点

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

5.3Gnocchi架构  

5.4Gnocchi模块

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

Gnocchi模块和数据关系

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


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

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

6 Ceilometer常用命令

Ceilometer命令:参见http://blog.csdn.net/violet_echo_0908/article/details/52243199

1）查询现在所有监控资源
ceilometer meter-list
得到一个监控资源表:
Name        Type        Unit        ResourceID        UserID        ProjectID
image.create gauge    image        3650e032-…        None            910dc7f

2）监控某种资源
ceilometer sample-list -m cpu
采样表要关注
ResourceID        Name        Type        Volume        Unit        TimeStamp
m:meter 监控项


3）查询某个监控资源
ceilometer meter-list –query user=xxxx

4 ）查询某个监控资源并限定条件
ceilometer sample-list –meter cpu -q 'resource_id='91;timestamp<2015-12-08T05:20:47'

ceilometer sample-list --meter cpu -q 'resource_id=921903ea-ccda-4eda-b86e-7d44f3aa71c2;timestamp<2015-12-08T05:20:47'

-q:指定多个过滤条件，用分号，是与的关系
-q “resource=xxx;timestamp<yyy”

5）查询某种资源的统计信息
ceilometer sample-list -m cache.miss
查询缓存的采样列表
ceilometer statistics –meter cpu_util
这张表要关注
Period    Period Start    Period End    Max    Min    Avg    Sum    Count    Duration Duration Start    Duration End


6）查询现在所有的alarm
ceilometer alarm-list
报警表
Alarm ID | Name | State | Severity | Enabled | Continuous | Alarm Condition | Time constraints

7）创建一个alarm
报警阈值创建 名称 缓存 描述 实例运行 监控项 名字 缓存 阈值 60 比对符号 大于 统计方式 平均值
周期 600s 验证次数 3此 报警 动作 日志 查询 资源id
ceilometer alarm-threshold-create --name cache --description 'instance running hot2' --meter-name cache --threshold 50.0 --comparison-operator gt --statistic avg --period 600 --evaluation-periods 3 --alarm-action 'log://' --query resource_id=INSTANCE_ID

得到一个
Property | Value
alarm_actions [u'log://']
alarm_id 08...
comparison_operator gt
…..
的表

8）更新某个alarm的阈值
ceilometer alarm-update --threshold 30 -a b6a745aa-6d5f-4a05-a240-f279fdfe0145
a:alarmid



9)查询某个alarm历史耕还
ceilometer alarm-history -a b6a745aa-6d5f-4a05-a240-f279fdfe0145

10)将某个alarm设置为无效
报警更新中设置为禁止
ceilometer alarm-update --enabled False -a  b6a745aa-6d5f-4a05-a240-f279fdfe0145

11)删除某个alarm
ceilometer alarm-delete -a b6a745aa-6d5f-4a05-a240-f279fdfe0145


12)得到某个alarm的状态
报警状态获取
ceilometer alarm-state-get b6a745aa-6d5f-4a05-a240-f279fdfe0145

13)设置某个alarm的状态
报警状态设置 状态 ok
ceilometer alarm-state-set --state ok -a 08ca166b-1ce8-4fcb-826d-8b069957c185

14)查看但各alarm详细信息
报警显示
ceilometer alarm-show 08ca166b-1ce8-4fcb-826d-8b069957c185

15)查看单个alarm的状态
包浆状态获取 报警号
ceilometer alarm-state-get -a 08ca166b-1ce8-4fcb-826d-8b069957c185

7 Ceilometer消息机制

参考:http://blog.csdn.net/u014007037/article/details/50453928
AMPQ：应用层协议标准，规定异步消息传递使用的协议标准。需要中间件实现，例如RabbitMQ。
模式是：发布/订阅模式。
Openstack使用消息队列的原因：各模块需要通信，模块解耦。
RabbitMQ:用于分布式环境，不同模块之间通信。
RPC:远程调用协议。通过网络从远程计算机请求服务协议。并不是主要的方法

8事件和事件处理

Ceilometer不仅能处理Sample数据，还能处理事件Events。
一个Sample代表一个数值点，一个事件表示Openstack对象中的状态,比如nova中实例在某个时间点被扩容，镜像创建等。

8.1事件的结构

event_type:事件类型，表示事件发生，例如compute.instance.resize.start
message_id:事件的UUID(唯一标识符)
generated:一个时间戳，表明事件何时创建
traits:特征，键值对，包含了事件的主要细节。
Raw:可选的，审核目的，全部的通知消息可以被存储，用于未来验证

8.2来自通知的事件

事件是被OpenStack的通知系统创建的。Nova,Galance,Neutron等会在一些重要的操作发生时以json格式发送通知消息到消息队列。Ceilometer会接收消息并处理。
通知会被被Ceilometer处理变成Events。通知可以被设置成人工的JSON数据格式，键值对的形式。转换可以被配置文件所指定，因此只有指定的通知字段会被处理为事件，并以traits的形式存储。

8.3转换通知变成事件

为了方便转换，通知转换为事件是被配置文件所指定(ceilometer.conf中的defintions_cfg_file标记)。
包含了如何将通知中的字段映射为Traits。
如果定义文件不存在，警告会被记录，但是会被假定为空的定义。
如果通知有相关的数据，一个默认的traits会被添加到事件中。
Service: 通知的发布者
tenant_id:
request_id:
project_id
user_id:

8.4定义文件格式

事件定义是以YAML的格式。它包含一系列事件定义。顺序是重要的。逆序读取。将最明确的放在后面。

8.5事件定义

事件定义需要两个key
event_type:是一个列表，
traits:是一个映射，键是特性的名字，值是特性的定义

Trait Definitions
每一个特性被定义各一个映射，包含下面的键。
Type:可选的，数据类型，例如string，int,text,datetime。默认是text
fields:指定希望从特性中抽取的通知字段
plugin:可选的，是一个映射，值为插件的名字。包含name,parameters:

8.6 字段路径指定

路径指定JSON通知体需要提取的特性中的值。可以用点标记，例如payload.host。

一个例子
---
- event_type: compute.instance.*
  traits: &instance_traits
    user_id:
      fields: payload.user_id
    instance_id:
      fields: payload.instance_id
    host:
      fields: publisher_id
      plugin:
        name: split
        parameters:
          segment: 1
          max_split: 1
    service_name:
      fields: publisher_id
      plugin: split
    instance_type_id:
      type: int
      fields: payload.instance_type_id
    os_architecture:
      fields: payload.image_meta.'org.openstack__1__architecture'
    launched_at:
      type: datetime
      fields: payload.launched_at
    deleted_at:
      type: datetime
      fields: payload.deleted_at
- event_type:
    - compute.instance.exists
    - compute.instance.update
  traits:
    <<: *instance_traits
    audit_period_beginning:
      type: datetime
      fields: payload.audit_period_beginning
    audit_period_ending:
      type: datetime
      fields: payload.audit_period_ending

8.7 Trait plugins

可以被用于做简单的编程转换通知字段中的值。例如分割字符串，大小写处理。
 

最后

以上就是敏感万宝路为你收集整理的Ceilometer: 1 、Ceilometer技术介绍Ceilometer技术介绍的全部内容，希望文章能够帮你解决Ceilometer: 1 、Ceilometer技术介绍Ceilometer技术介绍所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。