为自己的系统定制openstack ceilometer

最新推荐文章于 2024-11-11 08:41:40 发布
最新推荐文章于 2024-11-11 08:41:40 发布
阅读量100 收藏
点赞数
文章标签： 数据库 python 运维
原文链接：http://www.cnblogs.com/yuhan-TB/p/4054966.html
版权

一、目的

最近研究了一下ceilometer，目的做一个监控系统，对系统中发生的事件进行处理。ceilometer对openstack各个组件信息的收集方式主要由 推 和  拉 两种。

“推”： 就是openstack的各个组件将信息以notification的形式发送到message bus，然后有agent_notification对消息进行监听，agent_notification 在接收到消息后，经过一个pipeline的处理，然后再通过rpc发送给collector，

collector负责将接收这些消息并且存储到持久化介质中，如 database，file等；这样中间会经过两次rpc的发送；

“拉”：  openstack ceilometer会部署compute agent 还有 central agent 来主动的轮询（polling)一些组件的信息，compute agent主要负责收集虚拟机 cpu 内存、io等信息，compute agent会部署到每个虚拟机上，compute agent定期通过hyperviser api去获取信息。central agent 只部署在控制节点上，负责收集其他的信息image ，network等等，是通过restfulapi的方式调用；两种agent收集到消息后也是发送到rpc，然后collector收集；

二、设计方案

回到我们项目的需求上，我们只需要收集系统中的事件（event），其实ceilometer对收集信息的定义包括event和sample，event 就是一件发生的事情（例如： intance.create）,sample是事件发生过程的产生的具体数据，（例如，为了instance分配了多少memory）。我们的系统中只需要处理event不用处理sample。所以删除了对sampe部分的处理。

第二个改动是，我们这边只有notification发出的消息，也就是只有推的机制，没有拉的机制，这样，其实就可以考虑不用对notification两次rpc传输了。考虑agent_notification接受到消息后直接存储到数据库，将collector做的事情放到agent_notification中，但最终程序的名字还是叫collector。。。。上图


系统中的各个组件通过notification api 发送消息到message bus（rabbit mq），collector通过监听一定的exchange和topic来获取notification信息，

然后交给预先定义好的函数（event process pipeline）来处理，最后通过dispatcher转存储到持久化介质中；其中的event definition部分通过event_definition.yaml 来进行控制；

三、示例sample

 （1） 发送notification消息，

具体请参见higgs/sample/manager.py中的_sample_notify_period函数
from openstack.common.notifier import api as notifier_api
…...
payload = {
                'samples': [
                            {
                                'name': 'test_notify_sample',
                                'type': 'gauge',
                                'unit': 'ns',
                                'volume': 1,
                            }
                            ],
                'reason': 'delete',
                'user_id': 'test',
                'tenant_id':'test',
                'instance_id':'1234567890',
            }
 
 
publisher_id = notifier_api.publisher_id('higgs_sample')
notifier_api.notify(context,publisher_id,'compute.instance.test.samples',notifier_api.CONF.default_notification_level,payload)
……
 

 字段的具体定义如下：

a) publisher_id 是数据的发送方，openstack中是指"the source worker_type.host of the message, e.g. ‘compute.host1’ “, 

获取值的顺序是 CONF.host > CONF.default_publisher_id > socket.gethostname()，也可以通过notifier_api的publisher_id来进行设置；
 
b) ‘compute.instance.test.samples’: 这个值是event_type,是string类型；如果要定义和发送一个新的事件，就起一个新的名字，例如：’scheduler.trigger’
 
c) payload：中文释义是“装载” 顾名思义，就是发送一个事件时附带的详细信息，这个参数比较重要，collector中对事件的处理大部分的信息都是从payload中获取的；

d) CONF.default_notification_level 默认的notification级别，级别为 DEBUG < INFO < WARNING < ERROR < CRITICAL；
 

（2）collector中对事件的处理

 
 collector对事件的处理是通过yaml文件可配置的，具体的定义在event_definition.yaml中，截取一部分如下：
- event_type: compute.instance.*
  traits: &instance_traits
    tenant_id:
      fields: payload.tenant_id
    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:
      fields: publisher_id
      plugin: split
    memory_mb:
      type: int
      fields: payload.memory_mb
    disk_gb:
      type: int
      fields: payload.disk_gb
....... 

具体含义:
a) event_type: 被识别的event_type名称，支持通配符，这里的意思是，凡是以compute.instance.开头的事件都会有这段逻辑来处理；
traits: trait的中文是“特点”，可以理解为是一个event所携带的一个特点或者属性；例如trait下面的tenant_id、user_id......等都是一个trait；
 
b) tenant_id:
      fields: payload.tenant_id 
这两行一起看，表示这个trait的名字是tenant_id，它的值从你发送的event所携带的payload中的tenant_id中提取，payload.tenant_id的写法符合jsonpath https://pypi.python.org/pypi/jsonpath/ 
 
c) host:
      fields: publisher_id
      plugin:
        name: split
        parameters:
          segment: 1
          max_split: 1 
这七行一起看，这个trait的名字是host，它的值是从event的payload中的publisher_id这一项提取，不同的是，它要对提取的值进行一定的处理，调用name 为split的插件，给插件提供两个参数：
segment和max_split；collector使用了stevedore来增加可拓展性，split的具体定义可以在setup.cfg中进行查看；
如果需要自己发送的event进行特殊的处理，可以自己仿照着写插件；
 
d) memory_mb:
      type: int
      fields: payload.memory_mb
这三行一起看，与前两个不同的是，有一个type参数。这个type是针对trait而言的，trait有四种类型，string、int、float、datetime；如果没有实际写明type的类型，默认是string类型； 
 

总之，如果你有一个新的event要处理，首先你要定义这个event中的重要信息，然后在event_definition.yaml中写一个类似的将event转成trait的处理单元；

四、数据库结构

 
 
简单的介绍下 event 和 trait的数据库结构，对于理解这个两个概念更有好处；
event
+---------------+---------------+------+-----+---------+----------------+
| Field         | Type          | Null | Key | Default | Extra          |
+---------------+---------------+------+-----+---------+----------------+
| id            | int(11)       | NO   | PRI | NULL    | auto_increment |
| message_id    | varchar(50)   | YES  | UNI | NULL    |                |
| event_type_id | int(11)       | YES  | MUL | NULL    |                |
| generated     | decimal(20,6) | YES  | MUL | NULL    |                |
+---------------+---------------+------+-----+---------+----------------+
每一个 event 都会有一个message_id，系统会默认生成，通过uuid；
event_type_id是与另外一张event_type表相关联；
generated是时间戳；
 
 
event_type
+-------+--------------+------+-----+---------+----------------+
| Field | Type         | Null | Key | Default | Extra          |
+-------+--------------+------+-----+---------+----------------+
| id    | int(11)      | NO   | PRI | NULL    | auto_increment |
| desc  | varchar(255) | YES  | UNI | NULL    |                |
+-------+--------------+------+-----+---------+----------------+
id表示event的type id，与event表中的event_type_id是外键关联；
 
trait
+---------------+---------------+------+-----+---------+----------------+
| Field         | Type          | Null | Key | Default | Extra          |
+---------------+---------------+------+-----+---------+----------------+
| id            | int(11)       | NO   | PRI | NULL    | auto_increment |
| t_string      | text          | YES  |     | NULL    |                |
| t_float       | double        | YES  | MUL | NULL    |                |
| t_int         | int(11)       | YES  | MUL | NULL    |                |
| event_id      | int(11)       | YES  | MUL | NULL    |                |
| trait_type_id | int(11)       | YES  | MUL | NULL    |                |
| t_datetime    | decimal(20,6) | YES  | MUL | NULL    |                |
+---------------+---------------+------+-----+---------+————————+
t_ 开头表示trait的类型，在openstack中t_string是varchar(255)，bsp考虑到可能会发送比较长的字符值，所以改成了text；
event_id与event表中的id是外键关联；
trait_type_id与trait_type表中的id是外键关联；
 
trait_type
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| desc      | varchar(255) | YES  | MUL | NULL    |                |
| data_type | int(11)      | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+————————+
id 与 trait表中的trait_type_id是外键关联；

 

转载于:https://www.cnblogs.com/yuhan-TB/p/4054966.html

dingmu2707
关注
Openstack基础知识-PPT.pptx
05-10
2. 具有可扩展性及很好的弹性，支持定制化IaaS 3. 良好的社区氛围 OpenStack的劣势包括： 1. 入手难、学习曲线较高，在对整体把握不足的情况下，很难快速上手 2. 偏底层，需要根据实际应用场景进行二次开发 3. 现...
OpenStack Cloud Computing Cookbook
08-21
6. **监控与日志**：了解如何使用 ceilometer进行计量和监控，以及如何处理OpenStack的日志数据，对于确保系统的稳定运行至关重要。 7. **故障排查与性能优化**：书中可能会提供实用技巧来诊断和解决OpenStack环境...
OpenStack 定制CoreOS镜像
weixin_33695450的博客
02-04 109
1，下载相关制作ISO 包a)#coreOS安装文件（coreos-install脚本会从官网自动下载，这里手动下载，可以节省时间）wgethttp://stable.release.core-os.net/amd64-usr/444.5.0/coreos_production_p_w_picpath.bin.bz2 wgethttp://stable.release.c...
OpenStack Ceilometer简介
axd34177的博客
02-18 203
Ceilometer项目创建时最初的目的是实现一个能为计费系统采集数据的框架。在G版的开发中，社区已经更新了他们的目标，新目标是希望Ceilometer成为OpenStack里数据采集（监控数据、计费数据）的唯一基础设施，采集到的数据提供给监控、计费、面板等项目使用。 Project Goal For Grizzly, the new objective is The project...
OpenStack-Ceilometer组件-详解
m0_62727902的博客
05-18 1060
1. 计量 （Metering）： 收集资源的使用数据，其数据信息主要包括：使用对象（what）, 使用者（who）, 使用时间（when）和 用量（how much）。1. 概念：告警机制，可以通过阈值或者组合条件告警，并设置告警时触发的action，但是相对ceilometer是独立的一块，只是放在了ceilometer的代码树里面。3. Statistics：某个周期内（Period）的Samples聚合值，包括计数（Count）、最大（Max）、最小（Min）、平均 （Avg）、求和（Sum）等。
OpenStack-Ceilometer项目功能与架构介绍
SpiritedAway
09-17 1829
介绍OpenStack-Ceilometer项目功能与架构
OpenStack实践分享：OpenStack Gnocchi项目
mark's technic world
02-09 1526
简介 Gnocchi是一个能够高效存储海量监控指标（metric）测量值的系统，其设计目标是能够在云环境中提供时序数据库服务（TDBaaS，Time-series Database as a Service），通过对外暴露HTTPREST API来创建和操作各种监控资源的属性和各项监控指标的测量数据，最终实现了监控指标测量值的查询与存储的数据规模无关。Gnocchi最初由Julien Danjo...
openstack ceilometer
fabian4的专栏
06-05 1094
OpenStack添加监控服务 693497293 在 星期六, 12/07/2013 - 09:33 提交 添加监控服务 监控服务 OpenStack监控服务： 有效的收集有关CPU和网络花费的计量数据通过由服务或基础设置发送的监控通知收集信息。配置收集数据的类型，让他适应多种操作需求。通过REST API来接受和插入元数据。通过额外插
Kickstarter定制OpenStack安装光盘脚本
黑天的猩猩
10-06 326
基于CentOS 7 定制OpenStackliberty安装盘 #!/bin/sh -v sed -i 's#keepcache=0#keepcache=1#g' /etc/yum.conf yum clean all yum makecache yum -y install yum-utils yum-config-manager --add-repo http://mirrors.aliyun.com/repo/Centos-7.repo yum-config-manager --add-rep.
OpenStack与监控系统
小白的专栏
11-26 5463
转载自：https://www.ustack.com/blog/openstack_monitor/ 数据监控和展示是云平台中重要的部分，随着节点数目和所需监控对象的数量的增加，一个强大、健全、可扩展的监控系统才能满足各类用户的需求。它是一个云平台非常重要的特性，也是评估一个IAAS的可运维程度的参考。 首先我们需要看看目前众多云平台的监控现状。 第一类监控服务 这类监控服务为基本数据监控
OpenStack云监控：Ceilometer与Gnocchi实战优化
传统的开源监控系统如Zabbix、Cacti和Nagios虽然强大且灵活，但它们作为独立的工具，无法与OpenStack紧密集成，导致在云资源增删时无法自动同步监控。 Ceilometer是OpenStack官方推荐的资源监控项目，自Folsom版本...
openstack云系统第四周课程.rar
02-14
- **插件和扩展**：OpenStack允许添加自定义插件或扩展以满足特定需求，例如Telemetry（Ceilometer）用于计量和计费，Orchestration（Heat）用于模板化资源部署。 - **API和自动化**：OpenStack提供了丰富的...
07 Oracle数据库恢复基础解析：从检查点到归档，一步步构建数据安全防线
超哥的博客
11-09 1245
检查点是Oracle数据库中的一个特殊事件，它的作用是将内存中的数据块同步到磁盘上，以确保数据的持久性。简单来说，就是让数据库“记住”到目前为止所有的更改。Redo日志是Oracle用来记录所有数据更改的日志文件。每次对数据库进行修改时，都会先写入Redo日志，然后再写入数据文件。这样，即使系统崩溃，也能通过Redo日志恢复数据。当数据库运行在归档模式下时，一旦当前的Redo日志文件满，Oracle会将其复制到一个安全的存储位置，并标记为已归档。这样可以长期保留Redo日志，便于历史数据的恢复。
2024.11.6-Redis的事务与持久化
whisper_Java 的博客
11-06 861
MULTI、EXEC、DISCARD和WATCH 是 Redis 事务相关的命令。Redis的事务是将一系列待执行的指令存到一个Queue中，并使用exec执行事务。​--1. Redis事务是一个独立的隔离机制：事务中的所有命令都会序列化到queue、并按顺序地执行queue里的指令。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。​​multi: 用于开启事务，将待执行的命令放入到队列中exec命令:负责触发并执行事务中的所有命令：discard: 用于取消组队。
随堂测微信小程序ssm+论文源码调试讲解
最新发布
u014445459的博客
11-11 752
微信小程序，简称小程序，英文名Mini Program，是一种全新的连接用户与服务的方式，可以快速访问、快速传播，并具有良好的使用体验。小程序的主要开发语言是JavaScript，它与普通web的开发有很多相似之处。小程序和普通网页开发并不是相同的东西，是有差异的。网页开发的渲染线程和脚本线程是互斥的，而在小程序中，确实分开的，分别在不同的线程之中运行。
Redis - 事务
ketil27的博客
11-08 889
Redis 的事务和MySQL的事务概念上是类似的.都是把⼀系列操作绑定成⼀组.让这⼀组能够批量执 ⾏.弱化的原⼦性:redis没有"回滚机制".只能做到这些操作"批量执⾏".不能做到"⼀个失败就恢复到 初始状态".不保证⼀致性:不涉及"约束". 也没有回滚.MySQL的⼀致性体现的是运⾏事务前和运⾏后,结果都 是合理有效的,不会出现中间⾮法状态.不需要隔离性:也没有隔离级别,因为不会并发执⾏事务(redis单线程处理请求).
【达梦数据库】Oracle数据库通过DTS工具迁移数据到达梦数据库--索引数量存在出入
weixin_47686079的博客
11-06 166
【代码】【达梦数据库】Oracle数据库通过DTS迁移到达梦数据库索引数量不一致。
Java基于小程序公考学习平台的设计与实现（附源码，文档）
chusheng1840的博客
11-09 1143
Java基于小程序公考学习平台的设计与实现，小程序公考学习平台使用Java语言进行编码，使用Mysql创建数据表保存本系统产生的数据。系统可以提供信息显示和相应服务，其管理小程序公考学习平台信息，查看小程序公考学习平台信息，管理小程序公考学习平台。总之，小程序公考学习平台集中管理信息，有着保密性强，效率高，存储空间大，成本低等诸多优点。它可以降低信息管理成本，实现信息管理计算机化。关键词：小程序公考学习平台；Java语言；Mysql。
SpringBoot助力的共享汽车业务优化系统
2402_85762143的博客
11-09 1093
在整个系统测试中，根据需求文档和设计文档，逐一对功能进行检测并写好测试用例，有效避免残片缺陷，因为产品出现缺陷不仅影响功能，而且可以导致数据的不准确，导致产品质量的降低，经过测试，才能使得产品的稳定性和成熟度得到极大的提升，产品质量也才有保证。近来，软件工程界趋向于一种新的观点，即认为软件生命周期每一阶段中都应包含测试，从而检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正，如果不在早期阶段进行测试，错误的延时扩散常常会导致最后成品测试的巨大困难。任务：消除软件故障，保证程序的可靠运行。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值