本文详细介绍了OpenStack的部署步骤，包括Keystone、Glance、Nova等核心组件的配置过程，以及Neutron网络管理和Cinder块存储的设置。此外，还探讨了Ceilometer与Gnocchi的数据迁移方案。
source openrc 运行openrc.sh来设定环境变量 ip a ip address:查看设备ip地址 vim /etc/ssh/sshd_config 把PasswordAuthentication no注释，才能连接ssh sshd_config :远程登陆配置文件 systemctl restart sshd 将该命令开机启动 OS_AUTH_URL='http://192.168.10.2:35357/v2.0' 解决这个问题 最后登录openstack的ssh ssh root@192.168.10.3 对应是ip a中 14:br-mgmt-hapr@if13地址 Keystone user-create –name=putter –pass=openstack –email=petter@example.com pass: 密码 创建租户: keystone tenant-create –name=OpenStack实战 创建角色 keystone role-create –name=computer-user 关联租户和用户关系 将用户petter指定到OpenStack实战租户中 keystone user-list 用户可以在不同的租户中承担不同角色，可在一个租户承担多个角色 developer:只能访问云主机 admin:管理所有developer主机 在/etc/SERVICE_CODENAME/policy.json中 控制用户可以对指定服务进行操作 如/etc/nova/policy.json中指定计算服务的访问策略 /etc/keystone/policy.json中指定身份服务的访问策略，默认admin 服务管理: 服务，访问端点 keystone service-create 创建服务 keystone service-create --name=nova --type=compute --description="nova compute service" 5.2配置文件及选项参数 配置文件: /etc/keystone/keystone.conf /etc/keystone/paste.ini 常规配置: DEFAULT:常规配置 SQL：可选的存储后端 EC2:亚马逊EC2认证驱动程序配置 identity:系统驱动程序配置 catalog:服务目录 token:令牌驱动程序 policy: auth:授权插件配置 endpoint_filter:提供目录创建项目和端点之间的关联 LDAP：轻量目录访问协议，树状层次 通知选项：用户或项目创建等时，发送通知方式: 日志，RPC(消息队列),没有通知 notification_driver=keystone.openstack.common.notifier.rpc_notifier 连接Openstack服务到KeyStone 配置：paste.ini文件 KeyStone调用OpenStack服务： 1客户端调用OpenStack服务产生令牌 2Keystone验证令牌并获取用户id,租户id等信息 1设置证书 default的admin_token=ADMIN 作用：OpenStack服务之间共享米要，用于API创建租户，用户，角色 2设置租户、用户、角色 使用keystone需要定义租户和用户，并关联，其他openstack服务才能被Keystone授权 auth_token：处理认证和授权行为。 创建租户: keystone tenant-create 用户:keystone user-create 角色：keystone role-create 创建返回UUID 3设置服务 Keystone提供用户管理，可以作为Openstack服务目录：OpenStack服务可通过Keystone知道访问地址 服务目录两种形式: 1在default_catlog.templates :只需要修改模板文件 2在SQL数据库中：创建命令 keystone service-create --name=swift --type=obejct-store --description="Swift Service" 4设置auth_token中间件 auth_token通过WSGI管道认证，处理。配置在 <服务名>.conf 文件中 5.3keystone认证原理 提供统一身份验证，是认证和授权 认证：确定用户是否如实描述。 认证协议：基于HTTP认证，摘要认证，公钥认证，令牌认证。 Openstack基于令牌认证。 认证中间组件：是代理，拦截HTTP调用，填充HTTP头部的WSGI中间件或应用程序使用。 中间件处理流程：从http请求头收集令牌并验证。 验证有效：填充已经认证的标头。 认证原理： 认证中间件接受请求，经认证后，只传递已经授权请求到OpenStack服务 认证中间件可设置委托模式，将验证操作交给Openstack。 2认证组件的配置 认证组件作为WSGI组件在配置文件配置。 令牌中间件配置在paste.ini文件或keystone.conf文件，一般在主配置文件中加入auth_token 比如在nova.conf中 paste.ini配置高于nova.conf,需要将相应配置从paste.ini中删除 配置参数: auth_host: 主机提供验证和请求令牌服务的API端点 admin_token:初始创建用户需要，是keystone特权密钥 delay_auth_decision:关闭，将无效身份请求传给WSGI组件 auth_port:验证令牌，默认35357 ayth_protocol:默认https auth_uri: 默认为 auth_protocol://auth_host:auth_port certFile:客户端证书公钥 keyFile:keystone需要客户端私钥 4用缓存提高Keystone响应 分那会存在且未失效的令牌，支持Memcache memcache_servers:可选 token_cache_time:默认300s 5交换用户信息 中间件寻找:X-Storage-Token(swift)和X-Auth-Token(OpenStack服务通用令牌) 两种状态：确认和无效 6Keystone和其他组件关系 nova-api,nova-network,swift-proxy,glance-api需要和Keystone交互获取认证Token,才能执行后续步骤。 Keystone管理应用入口。 Endpoint:Openstack的URL地址 租户和用户多对多，用户和惧色一对1 配置文件定义：角色，用户，password。 策略文件：定义角色可访问的资源 服务读取配置和策略文件。 包含服务访问端口：公共的，内部的，管理员的 创建虚拟机流程: 用户携带密码进行keystone认证，keystone认证通过返回token,并通过Token向Keystone获取服务访问目录，keystone返回服务访问目录。 携带token创建虚拟机，指令传递给nova-api,nova向keystone验证token。 nova携带token访问galance,galance返回镜像，nova返回创建成功的信息给用户。 所谓的计算节点其实就是分配给用户的虚拟机。 源码分析: keystone-all:负责启动keystone服务 keystone-manage:负责管理keystone服务 greenlet和eventlet:是协程，将单线程模拟成多线程 eventlet:调度,greenlet:模拟线程 WSGI:web服务网关接口，将python方法变成web服务器方法。 每个server放在greenthread协程池，让eventlet调度 Keystone-all:加载keystone配置和paste配置，monkeypatch：热加载，可以 不修改源码下对运行程序修改，目的用自己的I/O替换socket Keystone-manage:导入CLI模块， keystone-manage db_sync:调用db_sync()同步数据库 配置keystone.conf中，执行 service openstack-keystone restart Galance镜像组件 没有镜像，无法在计算节点生成虚拟机 Galance:存取虚拟镜像，通过RESTful API查询镜像 使用KVM:通过virt-manager生成KVM虚拟机，做配置，把虚拟机的文件用Galance命令商船到Galance，用一个目录存放镜像。 上述即：复制虚拟机文件到Galance镜像目录 虚拟机镜像是一个文件，包含可启动操作系统。 虚拟机磁盘文件个是:RAW , qcow2,VMDK等。 计算节点启动虚拟机：把镜像文件复制到计算节点，nova.conf如果定义instances_path， 就是计算节点虚拟机存放木。有一个_base目录，镜像放在该目录下。 nova使用qcow2.不能删除_base，增量使用 Galance:表结构 image_locations:存放镜像文件地址，创建时间 images:存放镜像数据 migrate_version:Galance数据库版本数据 6.1.2 Galance中镜像 1镜像状态： queued:镜像进入队列，上传的被Galance注册服务接受 saving:镜像数据正在被上传到Galance active：可用 killed:上传镜像数据发生错误 deleted:镜像磁盘会在定义时间后自动删除 pending_delete:Galance不删除镜像数据，可以恢复镜像 2镜像格式： 多种虚拟机化技术:KVM,VMware,XenServer 容器格式:表示虚拟机镜像位呢见是否包含元数据 镜像文件格式: RAW:裸机格式，简单，可挂载后直接读写数据 qcow2:是qemu的copy on write,磁盘文件大小可随着数据增长而增长。 创建10GB，实际使用5GB,大小就是5GB,节省空间 VHD:通用磁盘格式，使用Hyper-V的虚拟化 VMDK:VMware创建爱你的虚拟机磁盘格式 VDI: VirtualBox用的 ISO：数据在光盘的格式 AKI:Amazon的AWS使用镜像格式 6.2 Galance配置 Galance API和Galance Registry两个服务 配置文件:galance-api.conf,galance-registry.conf [DEFAULT] default_store = file: 默认值是file,定义Galace后端存放镜像文件的本地目录， 可以使用Ceph,Swift进行存储 rbd:是ceph workers:设置Galance API工作进程个数，实际对应CPU个数 galance-api将api请求传递给galance-registry:默认为http 如果使用SSL改为https 通知系统选项： galance创建删除镜像时，可向系统发送通知。 4种通知方式: 日志，rabbit,quid,默认noop不发送 notifier_strategy=noop 后端文件系统存储 filesystem_store_datadir 延时删除 glance-scrubberL开启守护进程，可以响应删除请求 配置镜像缓存：在镜像存放目录外复制副本，存放到其他地方作为缓存 需要添加image cache middleware,在 glance-api-paste-ini 使用cachemanagement glance-cache: glance image-list qemu-image create -f qcow2 openstack.qcow2 40G 这是创建空的虚拟机硬盘，qcow2可以随容量增加增大 通过virt-install 来安装 libvirt使用iptables做NAT，让虚拟机可通过该网络访问外网 6.3设置Galance后端存储 Ceph:分布式存储习题哦嗯，已经集成在Openstack中。可以为Galance和Cinder作为外部存储。 Ceph块设备使用RBD的pool池 Nova计算组件 是IaaS重要组成。 设计原则：组件，容错，扩展。 是无共享，基于消息的架构。组件之间通信是消息队列，异步响应，收到消息触发回调。 nova组件通过nova-conductor组件做代理。nova-compute数据操作通过消息队列交给i nova-conductor来对数据库操作。 AMQP消息交互方式 AMQP通过调度组件决定哪个主机运行虚拟机 虚拟化组件： 虚拟化：将计算服务器，内存等抽象出来。一般包括计算和数据存储 nova虚拟化指计算能力虚拟化。 虚拟化布局方式： 集中式：多台物理设备模拟一台服务器 分散式：一台服务器拆分虚拟程多台虚拟服务器 管理分散布局的:Hypervisor 分为:裸机Hypervisor,含操作系统的Hypervisor。 特点：各虚拟服务在独立环境运行，共享底层物理设备。 nova提供调度其computeFilter过滤Hypervisor。 Hypervisor类型: KVM : 基于内核的虚拟机，qcow2，nova只要支持的 Xen:硬件虚拟化 Docker:新的Linux容器，快速部署应用程序 backend=sqlalchemy: 后端的ORM模型 Hypervisor配置： 配置信息针对libvirt,libvirt统一Hypervisor实现接口 Openstack Nova的Hypervisor后端是libvirt，通过libvirt管理KVM。 RPC配置 RabbitMQ是RPC通信中间件 常用配置 rabit_host= 配额设置：防止资源被过度使用。配额是租户级别的 cores:租户使用的cpu数量 instances:租户创建的实例数量 ram:内存 日志配置： fatal_deprecations=False:致命故障信息描述 调度配置： nova-scheduler:管理虚拟机的调度，决定哪一台物理机上创建虚拟机 VNC配置：虚拟网络主机 Nova服务启动过程 nova-all:启动所有Nova服务的脚本。导入Nova库，配置文件，日志函数，热打包，用launcher启动进程。将WSGI server迭代处理，放入greenthread协程池 使用api->manager->driver的模块调度法哪个是。 需要各自的topic,manager模块处理 虚拟机状态转换 实例：Nova中虚拟机，实例三个状态: vm_state:novi-api调用 task_state:API调用到最终实现的过渡 power_state:Hypervisor中虚拟机状态 libvirt中虚拟机状态 Nova Context:是Nova请求的上下文，是持久化信息，不会随着请求终止而消失。 Keystone认证处理: 对认证header处理。交互过程： api请求->auth_token->nova_auth->handle_request。 认证模块/keystone/middleware auth_token通用模块 REST API调用 WSGIService读取paste.ini，加载nova.conf中的api api-paste.ini:定义APIRouter处理RESTful URL路由 Router：创建各类的RESTful方法框架。创建URL到Python方法的道路 组件间RPC调用: Neutron网络组件 作用： KVM:简单使用Linux网桥，把虚拟及的虚拟网口桥接到物理机 缺点：无法按照用户项目分类的网络隔离 VLAN模式: Neutron:可以创建多个私有网络，与其他用户隔离 包含：network网络，subnet子网，router:路由器，port端口 Nova,Galance,Keystone都是安装在控制节点上 Neutron：不同节点都会安装 Neutron的服务称为agent，需要部署： 1)neutron-server: Neutron主进程，是守护进程，接受请求，传到Neutron的agent。 在数据库中存取静态数据，安装在控制节点或网络节点 2)neutron-plugin-XXX:网络虚拟化技术插件。 paugin需要安装在neutron-server节点 3)neutron-plugin-XXX-agent:插件的代理。负责虚拟网络数据包 agent需要安装在处理虚拟机网络数据包的节点。 计算节点必须安装agent。 Neutron-DHCP-agent:给虚拟机提供DHCP服务,dhcp节点是数据流转发节点 neutrn-l3-agent:提供虚拟机访问外网 Open vSwitch:虚拟交换机软件。 Plugin:处理api请求，保存网络数据 agent:在计算节点和网络节点运行，从配置文件收集数据 网络分类: Provider网络：影射到数据中心存在的网络 Tenant网络：每个项目创建的网络 OVS实例模型 br-int:安装建立的网桥 br-tun:使用GRE技术与其他agent节点建立连接 Cinder块存储组件 块设备的API 操作类：删除是异步 创建/删除/挂载/卸载/给块设备建立快照/删除 快照 查询类: 列出云主机挂载的块设备 Nova-Cinder交互流程 Cinder API封装类调用cinder_client库来调用Cinder的API。 使用Ceph作为Cinder的后端 RBD：块设备接口，Ceph块设备使用的RBD池 cinder-volume节点和nova-compute计算节点需要安装Ceph的客户端 Openstack日常运维 高可用性HA配置控制节点和swift 查看进程 ps aux | grep nova- 确认服务 source openrc glance index nova list keystone tenant-list 网络诊断: 查看网卡信息 ip a | grep state brctl iptables-save 忽略virbr0，默认网桥 错误日志: /var/log/nova(keystone) service rabbitmq-server restart 进程监控 ps -aux | grep nova-api nova数据库中资源用量:nova,quotas nova usage-list 备份，恢复等 Fuel:Openstack统一安装入口，部署Openstack，可以添加/删除节点，可以认为是管理Openstack的软件 工作原理：先部署fule节点，包含两个工具 Puppet:配置管理系统，软件批量安装 Cobbler:安装服务器，通过PXE安装裸机 Fuel架构：定义但节点，多节点(不含高可用，分布式部署)，多节点(高可用，生产环境) 使用VMware创建虚拟环境。 Fuel节点：部署管理软件 Controller:Openstack控制器，管理Openstack节点，nova-api,cinder-api Compute:提供计算资源 PXE:fule_master通过pxe引用节点内存中的centos进行安装 Metering:监控 Gnocchi来存储计量数据Metrics Panko存储Events Aodh存储报警Alarms数据 我需要关注的是Gnocchi 安装Ceilometer中由一个Moving from Ceilometer to Gnocchi 之前已经安装了Ceilometer了,后端选择的是ceph for cinder/nova/galance https://docs.openstack.org/developer/ceilometer/install/dbreco.html 这个地址介绍如何将Ceilometer迁移到Gnocchi，目前没有迁移工具，很多发布者multiple Publisher在收集器中同时将捕获的数据存储到Ceilometer本地数据库和Gnocchi。这将允许你测试Gnocchi并且在适当的时候迁移。 编辑pipeline.yaml和event_pipeline.yaml去包含多个发布者。 Sinks: -name:event_sink publishers: --gnocchi:// --database:// pileline.yaml和event_pipeline.yaml在:/etc/ceilometer/ pipeline.yaml 暂时没有找到，需要弄清这个配置文件的参数含义 默认都没有配置 --- sources: - name: event_source events: - "*" - "!magnum.bay.metrics.update" sinks: - event_sink sinks: - name: event_sink transformers: triggers: publishers: - notifier:// 需要弄清用法。 目前最主要的工作就是写一个ceilometer的demo. 但是在开发者文档中没有发现如何使用的例子，估计应该是当成ceilometer命令来做了。 所以要深入到源码。目前只能将所有文档进行翻译查看。 目标：实现迁移数据库，一个自动化脚本。 迁移需要掌握:基础，使用，源码 三部分 1 原来ceilometer中基础概念，配置信息 基础概念通过开发者文档查看。 18：00～19：00 2 如何使用ceilometer 命令 3 源码分析: 这个人的解析源码:http://blog.youkuaiyun.com/gaoxingnengjisuan/article/details/41816885 放到后面看。 现有的解决方案 运行后发现： ceilometer meter-list :是可以的，说明已经安装了 安装部分可以跳过 18：20～18:50 完成到安装部分 概览：跳过 1 概览 Ceilometer三个目标：metering,rating,billing metering:计量，收集资源使用数据 rating:计费，资源使用数据按照商务规则转化为可计费项目并计费 billing:结算，收钱开票 基础概念: agent: 一种服务，运行在OpenStack架构上，衡量使用量并根据publishers发送结果到任意数量的目标上 API Server:为ceilometer提供的基于http的 rest api billing:结算 bus listener agent:总线监听代理，将Oslo通知总线上生成的时间转化为Ceilometer的Sample采样值。 Ceilometer:计量/计费系统 polling agent:轮询代理，运行在控制节点或者计算节点，用于衡量使用量并 且将结果发送到队列。 Notification agent:不同的OpenStack组件会针对不同的事件类型发送几个通知。 通知代理会从各自的队列中获取并按照时间类型对它们过滤。 Data store:存储系统会将收集的数据存储 meter:监控项。比如CPU使用时间。包含三种类型 Cumulative:累积的，例如磁盘吞吐量 Gauge:离散的，比如上传的镜像大小 Delta:增量，如带宽 metering:监控是信息收集过程 notification:通过外部的Openstack系统发送的信息，例如Nova,Glance。使用Oslo消息机制。这些消息会被Ceilometer通过RPC driver的notifier接收到。 Project:OpenStack的tennat租户或者project publisher:发布者，将采样值发布到指定目标 push agents:推送代理，获取项目中的数据，并不暴露 介绍消息机制的: http://blog.youkuaiyun.com/u014007037/article/details/50453928 AMPQ：应用层协议标准，规定异步消息传递使用的协议标准。需要中间件实现，例如RabbitMQ。 模式是：发布/订阅模式。 Openstack使用消息队列的原因：各模块需要通信，模块解耦。 RabbitMQ:用于分布式环境，不同模块之间通信。 RPC:远程调用协议。通过网络从远程计算机请求服务协议。并不是主要的方法 rating:计费。根据商业规则将监控项转化为收费项目 resource:OpenStack监控的实体 sample:某个一个监控项的数据采样值 source:原始监控数据 user:openstack用户 2系统架构：架构解读： 架构设计是为了支持水平扩展，额外的workers和节点可以被添加。 两个核心的服务: 1 polling agent:轮询代理，守护进程，轮询OpenStack各项服务并建立监控项。 2 notification agent:通知代理，守护进程，监听消息队列的通知，并将它们转化为事件和采样值，并且应用到管道pipeline动作。 采集的数据会被Ceilometer发送到不同的目标。 Gnocchi用于将捕获到的测量数据以时间序列的格式来优化存储和查询。Gnocchi被用于来替换现有的已经存在的监控数据库接口。 Aodh是报警服务，可以以指定的规则发送警告给用户。 Panko是事件存储项目，用于捕获文档格式的数据，例如日志和系统事件操作。 3采集数据 3.1采集数据由两种方式。 1 Notification agent通知代理:将生成的消息通过消息总线Notification bus，并且转换为Ceilometer采样值或者事件。这是主要的收集数据的主要方式。 2 Polling agents:轮询代理，并不是主要的方法，将会轮询一些API或者工具来周期性收集数据。轮询方式不是主要的因为加载该服务需要强加到某些额API服务中。 第一种方法被ceilometer的通知代理所支持，监控消息队列中的通知。 轮询代理可以被配置成去轮询本地的管理程序hypervisor(虚拟机)，或者热源程的API，和本纪中的SNMP/IMPI守护进程。 3.1.1通知代理:
通知代理会处理来自服务的数据。系统的核心是通知守护进程，可以监控Openstack组件发送的消息队列的数据，例如Nova,Galance,Cinder,Neutron,Swift,Keystone,Heat,Ceilometer内部通讯 通知守护进程加载一个或多个监听插件，使用命名空间 ceilometer.notification。每一个插件可以监听任何主题，但是默认会监听notification.info,notification.sample,notification.error。 监听器会抓取配置主题topics中的信息，并重新分发它们到正确的插件中，最后处理变成Events和Samples。 采样插件Sample-oriented plugins提供一种方法会列出所有它们感兴趣的事件类型，并采用对应的徽调函数来处理。 注册的回调函数名称被用于开启或禁止使用通知守护进程的pipeline。 还未被传送到回调函数的即将到来的信息会根据事件类型的值被过滤，因此插件智慧接收到它感兴趣的事件。 轮询代理Polling Agents
3.1.2轮询代理会查询服务的数据。 轮询计算节点资源信息的代理叫做compute-agent。轮询控制节点资源的代理被叫做central-agent。 轮询代理被配置为可以在1个或多个pollster plugins中使用以下任意组合的命名空间。 Ceilometer.poll.compute,ceilometer.poll.central,ceilometer.poll.impi。 轮询的频率是通过pipeline来配置的。【扩展阅读：pipeline】。 代理的框架将会产生采样值给通知代理处理。 3.1.3处理数据 管道控制器Pipeline Manager
管道线Pipeline:是由一些列的转换器transformers将数据转换成发布者知道如何发送给外部系统的事物。 Ceilometer提供了功能可以将通过代理收集到的数据进行操作后，然后发布到多个不同的管道组合中。 一个管道功能的例子：将T,T+1,T+2时间点收集到的CPU使用率经过处理后，计算这段时间平均CPU使用率。 发布数据：将Sample通过: 1)Gnocchi Publisher存储到Gnocchi数据库 2)oslo.messaging Publisher:通过AMQP的签名消息发送到外部系统，例如监视器，统计，行呢个，容量等。 7种传输方式 1 gnocchi:将samples/events发布到Gnocchi API 2 notifier:基于publisher的通知，推送samples到消息队列，可以被外部系统接收 3 udp:通过UDP数据包发布数据 4 http:目的是REST接口 5 kafka:将数据发布到Kafka消息队列 6 文件：存储到指定位置和名称的文件 7 database：数据库，存储到ceilometer的数据库 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 事件和事件处理 Ceilometer不仅能处理Sample数据，还能处理事件Events。 一个Sample代表一个数值点，一个事件表示Openstack对象中的状态,比如nova中实例在某个时间点被扩容，镜像创建等。 4.1事件的结构 event_type:事件类型，表示事件发生，例如compute.instance.resize.start message_id:事件的UUID(唯一标识符) generated:一个时间戳，表明事件何时创建 traits:特征，键值对，包含了事件的主要细节。 Raw:可选的，审核目的，全部的通知消息可以被存储，用于未来验证 4.2来自通知的事件 事件是被OpenStack的通知系统创建的。Nova,Galance,Neutron等会在一些重要的操作发生时以json格式发送通知消息到消息队列。Ceilometer会接收消息并处理。 通知会被被Ceilometer处理变成Events。通知会被装在，可以被设置成人工的JSON数据格式，键值对的形式。转换可以被配置文件所指定，因此只有指定的通知字段会被处理为事件，并以traits的形式存储。 4.3转换通知变成事件 为了方便转换，通知转换为事件是被配置文件所指定(ceilometer.conf中的defintions_cfg_file标记)。 包含了如何将通知中的字段映射为Traits。 如果定义文件不存在，警告会被记录，但是会被假定为空的定义。 如果通知有相关的数据，一个默认的traits会被添加到事件中。 Service: 通知的发布者 tenant_id: request_id: project_id user_id 4.4定义文件格式 事件定义是以YAML的格式。它包含一系列事件定义。顺序是重要的。逆序读取。将最明确的放在后面。 4.5事件定义 事件定义需要两个key event_type:是一个列表， traits:是一个映射，键是特性的名字，值是特性的定义 Trait Definitions 每一个特性被定义各一个映射，包含下面的键。 Type:可选的，数据类型，例如string，int,text,datetime。默认是text fields:指定希望从特性中抽取的通知字段 plugin:可选的，是一个映射，值为插件的名字。包含name,parameters: 4.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 4.7 Trait plugins 可以被用于做简单的编程转换通知字段中的值。例如分割字符串，大小写处理。 5 Web API Gnocchi提供了反应灵敏的统计功能的API。 Gnocchi的API参考：https://docs.openstack.org/developer/gnocchi/rest.html 5.1 Resources 参考:https://docs.openstack.org/developer/ceilometer/webapi/v2.html#resources 5.2 Meters 参考:https://docs.openstack.org/developer/ceilometer/webapi/v2.html#meters 5.3 Samples and Statistics 5.4 Capabilities 5.5 Filtering Queries 5.6 Links 5.7 API and CLI query examples 6安装Ceilometer 6.1选择数据库后端： 迁移Ceilometer到Gnocchi 6.2安装开发沙盒：配置devstack 6.3手动安装: 1)存储后端安装 2)安装通知节点 3)安装轮询节点 4）安装API Server 5)使得服务通知可用 6.4 定制化Ceilometer的部署 1）通知队列 2）使用多重发布器publishers 3）定制化pipeline 4)有效的轮询 6.5升级 全量升级 部分升级 开发者建议 发送消息过程： 创建连接，获得channel,创建exchange,创建producer[指定exchange与routing_key],发送消息。
6.1 Gnocchi安装 1 参见Gnocchi installation安装命令: https://docs.openstack.org/developer/gnocchi/install.html 2编辑/etc/ceilometer/ceilometer.conf 2.1开启Keystone验证 [dispatcher_gnocchi] [service_credentials] 3 拷贝gnocchi_resources.yaml到config directory (e.g./etc/ceilometer) 4初始化Gnocchi数据库通过创建ceilometer资源 ceilometer-upgrade –skip-metering-database 5 开启最小化数据请求，缓存和批处理 5.1 开启资源缓存 [cache] 5.2开启批处理 [notification] 6开启通知服务 7安装通知代理 8安装轮询代理 9安装API ServerName 10开启服务通知 cinder,glance,heat,neutron,nova,sahara,swift配置选项：
配置选项是为Ceilometer来启动服务
Sample配置文件：/etc/ceilometer/ceilometer.conf.sample 已经被移除
Polling:轮询，轮询的规则被定义在polling.yaml文件，定义了轮询器pollsters开启和轮询的时间间隔。
每个资源配置
|
--- sources: - name: 'source name' interval: 'how often the samples should be generated' meters: - 'meter filter' resources: - 'list of resource URLs' discovery: - 'list of discoverers'
|
轮询的定义中 interval参数是被定义为秒的，给定的轮询插件是根据meter参数匹配每个插件的meter名字，匹配source sections是被union组合的规定时间序列。功能类似于Pipelines过滤。
pipeline中可选的资源部分允许配置静态的资源URL数组。一个用于一组pipeline的混合的静态配置的资源列表都有共同的interval,这些interval会被传递到各自匹配pipelines的pollsters。
pipeline source中可选的discovery section包含了discovers列表。这些发现者可以在pipeline定义的pollsters中用于动态发现轮询的资源。发现者的名字需要和相关setup.cfg中插件名字相同。
如果resources或者discovers部分没有被设置，默认为空的列表。如果都被设置，最终发送给轮询者pollster的是由discoers返回的动态资源以及资源部分定义的静态资源的组合。若两者有重合，移除重复的部分。
pollster获得轮询资源的方式有3种：
1从配置在discovery中的per-pipeline或者静态资源获得
2来自于per-pollster的默认discovery
3来自于per-agent的默认discovery
管道线Pipelines:
管道线描述了采样值samples和对应的槽sink,sink是用于做转换和发布这些采样值、
一个槽sink处理samples,并提供转换的逻辑，可以将相关资源的采样值分发除去、
每一个sink配置仅仅是与转换规则和samples发布相关。
一个sink可以认为是一个处理链，开始于0或多个转换器，终止于一个或多个发布者publishers。
支持多重发布。
Pipeline配置
|
--- sources: - name: 'source name' sinks - 'sink name' sinks: - name: 'sink name' transformers: 'definition of transformers' publishers: - 'list of publishers'
|
参数source不和任何事物相关。
有几种方式定义监控项meter列表
1） 包含所有的meters,使用*
2） 等译监控项列表，使用下面任意方式:
A. 定义一个包含列表，使用meter_name
B. 定义一个排除列表，使用!meter_name
C. 对于meters.根据通配符识别复杂的采样字段，例如disk.read.bytes，使用disk.*
上述定义方法可以组合
transformers的名字需要和setup.cfg中拓展的名字相同
publishers包含采集数据将要被发送。发布者的名字需要和setup.cfg相关插件的名字一致。
默认配置可以在pipeline.yaml中
多重发布者参见: https://docs.openstack.org/developer/ceilometer/install/custom.html#publisher-configuration
管道处理过程
通知代理需要协调来确保相关信息被发送到同一个代理上。为了协调。
设置notification中workload_partitioning的值。
建议增加处理队列的数量。
Publishers部分参见: https://docs.openstack.org/admin-guide/telemetry-data-retrieval.html#publishers
编写一个代理插件
这篇文档给你一些线索如何来编写为ceilometer编写一个新的代理或插件。
轮询代理实现在/ceilometer/agent/manager.py中，加载ceilometer.poll.agent的所有插件，周期性带哦用get_samples()方法。
插件
包含ceilometer.poll.compute和ceilometer.poll.central
Pollster
计算插件被定义为ceilometer/compute/pollsters/__init__.py中ceilometer.compute.pollsters.BaseComputePollster 的子类，轮询者Pollster必须实现一个方法:
获取采样列表
get_samples(self,manager,cache , resources)
Notifications
是ceilometer.agent.plugin_base.NotificationBase的子类
通知必须实现:
event_types:将要传递给插件的字符串定义的时间类型序列
process_notification(self , message):接收到事件消息，并提供时间类型，返回sample列表
使用get_event_type方法并随后使用process_notification会在产生合适的采样对象后发送给收集器。
添加新的插件
基于setuptools entry points的插件系统使其容易添加在带i中新的监视器。
需要将entry point定义在Ceilometer的entry_points.txt文件
计算插件和代理的测试目录在test/compute和test/agent中。
单元测试会持续集成。
采用新特性的集成:http://blog.youkuaiyun.com/linshenyuan1213/article/details/51250585
扫一扫
805
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
