Ceilometer安装与配置

目录

• 实验概述
  • 实验介绍
  • 实验环境
  • 实验目的
  • 环境与约定说明
• 准备工作：登录实验环境
• 任务一：Gnocchi安装
  • 步骤1 为Gnocchi服务创建数据库
  • 步骤2 在Keystone注册Gnocchi服务
  • 步骤3 Gnocchi安装配置
  • 步骤4 安装配置redis
  • 步骤5 启动Gnocchi
• 任务二：Ceilometer安装配置
  • 步骤1 Ceilometer安装
  • 步骤2 Ceilometer配置
  • 步骤3 启动服务
  • 步骤4 Ceilometer-compute、ipmi安装与配置
• 任务三：配置Nova与通知源
  • 步骤1 配置Nova
  • 步骤2 配置Cinder通知
  • 步骤3 配置轮询ipmi
  • 步骤4 启动代理
• 任务四：验证
  • 步骤1 创建计量对象（云硬盘）
  • 步骤2 在控制节点验证
• 实验小结
• 思考题
• 附录：常用排查命令

实验概述

实验介绍

通过在鲲鹏平台上完成Gnocchi与Ceilometer的安装与配置，实现Ceilometer能够采集、监控OpenStack其他组件的数据。

实验环境

服务器说明

产品	操作系统	数量
鲲鹏服务器	openEuler 22.03 LTS for ARM	1

虚拟机说明

产品	版本	数量
虚拟机	openEuler 22.03 LTS for ARM	1

软件说明

请确保虚拟机已正确安装好 OpenStack Keystone、Glance、Placement、Nova 服务（控制节点组件：nova-api、nova-conductor、nova-scheduler）。

本实验所使用环境的主要软件版本如下，操作前可通过 rpm -qa | grep openstack 核对：

软件	版本	说明
OpenStack	Wallaby	已部署 Keystone/Glance/Placement/Nova/Cinder 等组件
MySQL(MariaDB)	10.5	数据库服务 mariadb.service
Gnocchi	4.3.5	本实验安装
Ceilometer	16.0.0	本实验安装
Redis	6.2.6	本实验安装，作为 Gnocchi 的协调（coordination）后端

实验目的

• 在鲲鹏服务器上完成Gnocchi与Ceilometer的安装

• 在鲲鹏服务器上完成Gnocchi与Ceilometer的基础配置与操作

• 在鲲鹏服务器上完成Ceilometer数据采集与查看

环境与约定说明

1. 主机名与IP：本实验虚拟机主机名为 controller，管理网 IP 为 10.60.10.151，/etc/hosts 中已存在 10.60.10.151 controller 的解析记录。若实际环境的 IP 不同，请把下文出现 10.60.10.151 的位置替换为实际的管理 IP。

2. 本实验为单节点（All-in-One）部署：控制节点与计算节点角色由同一台虚拟机承担，因此原手册中“在计算节点执行”的操作，全部在本机（controller）上执行。

3. 口令约定：为与环境中已有的服务用户保持一致，本手册统一使用如下口令，请勿随意更改，否则各配置文件之间会认证失败：

   用途	取值
   数据库 root 口令	Huawei@123
   Gnocchi 数据库用户口令	Huawei@123
   Gnocchi / Ceilometer 服务用户口令	Huawei@123
   RabbitMQ openstack 用户口令	Huawei@123（在 URL 中须写成 Huawei%40123）

   注意：口令中的 @ 在 URL 里是保留字符，凡是写在 mysql+pymysql://、rabbit:// 这类连接串里的口令，都必须转义为 %40；写在 password = 配置项里的口令则保持原样，不做转义。

4. 管理员环境变量：本手册中的 openstack、gnocchi 命令均需管理员身份执行，操作前请先加载管理员凭证：

   [root@controller ~]# source /root/.admin-openrc
   

   可通过 openstack token issue 验证凭证是否可用（能返回 token 信息即正常）。

5. 已知提示信息：执行 openstack 命令时，终端可能输出若干行

   Could not load 'alarm create': module 'pyparsing' has no attribute 'operatorPrecedence'
   

   这是由于环境中 python3-aodhclient 与高版本 pyparsing 不兼容导致的告警插件加载失败，不影响本实验任何命令的执行结果，可忽略。

6. yum 源：本实验环境的 yum 源已配置完毕，不允许修改任何 yum 源配置文件。若因 GPG 校验导致软件包无法安装，请使用临时绕过校验的方式安装（命令行追加 --nogpgcheck，或 -o gpgcheck=0），不要修改 /etc/yum.repos.d/ 下的任何文件。例如：

   [root@controller ~]# yum -y install --nogpgcheck <软件包名>
   

7. 计量数据从哪来（重要）：Ceilometer 不“主动抓取”业务数据，它消费的是 OpenStack 各组件发到 RabbitMQ 的 notification 消息。组件不开通知，Ceilometer 就什么都收不到。因此本实验不仅要装 Ceilometer，还要给组件打开通知开关：

   组件	是否默认发通知	本手册的处理
   Nova	否	任务三 步骤1 打开
   Cinder	否	任务三 步骤2 打开（本环境无实例，云硬盘是唯一可演示的计量对象）
   Glance	否	本实验不做要求，需要时同样在 glance-api.conf 加 [oslo_messaging_notifications] driver = messagingv2

   如果跳过任务三，任务四的三个查询命令都会返回空表——这不是安装失败，是没有数据源。

准备工作：登录实验环境

后续所有操作都在虚拟机（controller）上以 root 身份执行。若你已经在虚拟机终端里，可跳过本节。

打开桌面终端“Terminal”，先用老师提供的 student 账号登录物理服务器，再由物理服务器跳到分配给自己的虚拟机：

ssh student@物理服务器IP        # 第一次登录输入 yes 和密码
ssh root@虚拟机IP               # IP 从老师处获取，第一次登录输入 yes 和密码

登录成功后提示符应为：

[root@controller ~]#

其中 controller 为虚拟机主机名。如果提示符不是 root@controller，说明进错了机器或身份，先不要继续往下做。

任务一：Gnocchi安装

步骤1 为Gnocchi服务创建数据库

创建Gnocchi数据库

[root@controller ~]# mysql -u root -p
Enter password:                       # 输入数据库root口令 Huawei@123

MariaDB [(none)]> CREATE DATABASE gnocchi;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON gnocchi.* TO 'gnocchi'@'localhost' IDENTIFIED BY 'Huawei@123';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON gnocchi.* TO 'gnocchi'@'%' IDENTIFIED BY 'Huawei@123';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> exit

注意：本实验统一使用 Huawei@123 作为 Gnocchi 的数据库用户口令。如需更换，必须同时修改两处——本步骤两条 GRANT 语句中的口令，以及步骤3 [indexer] 连接串中的口令（连接串里要写成 Huawei%40123）。两处不一致时 gnocchi-upgrade 会直接报数据库认证失败。

创建完成后可确认数据库已存在：

[root@controller ~]# mysql -u root -pHuawei@123 -e "show databases like 'gnocchi';"

预期输出一行 gnocchi。

步骤2 在Keystone注册Gnocchi服务

创建 gnocchi 用户，并设置密码

[root@controller ~]# openstack user create --domain default --password Huawei@123 gnocchi

说明：原手册使用 --password-prompt 交互式输入口令，本手册改为用 --password 直接指定，便于后续配置文件的口令与之一致；如需交互式输入，可将命令改为 openstack user create --domain default --password-prompt gnocchi。

在 service 项目下为 gnocchi 用户添加 admin 角色

[root@controller ~]# openstack role add --project service --user gnocchi admin

（该命令执行成功时无任何输出，属正常现象。）

创建 gnocchi 服务实体

[root@controller ~]# openstack service create --name gnocchi --description "Metric Service" metric

创建度量服务API端点

[root@controller ~]# openstack endpoint create --region RegionOne metric public http://controller:8041
[root@controller ~]# openstack endpoint create --region RegionOne metric internal http://controller:8041
[root@controller ~]# openstack endpoint create --region RegionOne metric admin http://controller:8041

三个端点创建完成后可用一条命令确认：

[root@controller ~]# openstack endpoint list --service gnocchi

预期输出三行，Service Type 均为 metric，URL 均为 http://controller:8041，Interface 分别为 public / internal / admin。

步骤3 Gnocchi安装配置

安装Gnocchi包

[root@controller ~]# yum -y install openstack-gnocchi-api openstack-gnocchi-metricd python3-gnocchiclient

说明：openEuler 22.03 LTS 的 OpenStack Wallaby 源中，上述三个软件包的正式包名为 gnocchi-api、gnocchi-metricd、python3-gnocchiclient；使用 openstack- 前缀的名字同样可以被 yum 正确解析并安装。安装完成后可通过 rpm -qa | grep gnocchi 确认。

修改配置文件/etc/gnocchi/gnocchi.conf

[root@controller ~]# vi /etc/gnocchi/gnocchi.conf

注意：gnocchi.conf 是安装包自带的完整配置模板，[DEFAULT]、[api]、[archive_policy]、[cors]、[indexer]、[metricd]、[storage] 等段落均已存在。请将下面各项直接写入对应的已有段落中（找到同名配置项后去掉行首注释并改值），不要重复添加同名段落，只有 [keystone_authtoken] 段落需要手工新增。

配置Gnocchi功能参数，log地址以及对接redis url端口

[DEFAULT] 

debug = true 
verbose = true 
log_dir = /var/log/gnocchi 
parallel_operations = 4 
coordination_url = redis://controller:6379

配置Gnocchi工作端口信息，host为控制节点管理IP

[api]

auth_mode = keystone
host = 10.60.10.151
port = 8041
uwsgi_mode = http-socket
max_limit = 1000 

注意：host 必须填写控制节点的管理 IP（本环境为 10.60.10.151，可用 ip addr 查看），不要写成 controller 主机名，否则 uwsgi 会因为无法绑定该地址而启动失败。

配置元数据默认存储方式

[archive_policy]

default_aggregation_methods = mean,min,max,sum,std,count 

配置允许的访问来源

[cors]

allowed_origin = http://controller:3000 

配置数据库检索

[indexer]

url = mysql+pymysql://gnocchi:Huawei%40123@controller/gnocchi

注意：数据库口令中的 @ 必须转义为 %40，否则 SQLAlchemy 会把 @ 之后的内容误解析为主机名，导致 gnocchi-upgrade 报数据库连接错误。

配置ceilometer测试指标

[metricd]

workers = 4
metric_processing_delay = 60
greedy = true
metric_reporting_delay = 120
metric_cleanup_delay = 300

配置Gnocchi存储方式以及位置，在这种配置下将其存储到本地文件系统

[storage]

coordination_url = redis://controller:6379
file_basepath = /var/lib/gnocchi
driver = file

配置Keystone认证信息，该模块需要另外添加

[keystone_authtoken]

region_name = RegionOne
www_authenticate_uri = http://controller:5000
auth_url = http://controller:5000/v3
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = gnocchi
password = Huawei@123
service_token_roles_required = true

注意：[keystone_authtoken] 是默认配置文件中没有的段落，需要手工新增；password 处填步骤2中为 gnocchi 用户设置的口令，此处不转义。

配置完成后，可执行如下命令检查关键配置项是否已正确写入，输出应包含 host、port、url、driver、password 各行：

[root@controller ~]# grep -E "^(host|port|url|driver|password) *=" /etc/gnocchi/gnocchi.conf
host = 10.60.10.151
port = 8041
url = mysql+pymysql://gnocchi:Huawei%40123@controller/gnocchi
driver = file
password = Huawei@123

步骤4 安装配置redis

在控制节点执行以下操作

安装redis server

[root@controller ~]# yum -y install redis

编辑配置文件 /etc/redis/redis.conf，修改以下配置

[root@controller ~]# cp /etc/redis/redis.conf /etc/redis/redis.conf.bak
[root@controller ~]# vi /etc/redis/redis.conf

注意：openEuler 22.03 LTS 的 redis 软件包，配置文件路径为 /etc/redis/redis.conf（不是 /etc/redis.conf）。

配置redis可以在后台启动

daemonize yes

配置redis关闭安全模式

protected-mode no

配置redis绑定控制节点主机

bind 10.60.10.151

注意：bind 必须填写控制节点管理 IP，Gnocchi 通过 redis://controller:6379 访问时，域名会被解析为该 IP；若保持默认的 127.0.0.1，Gnocchi 与服务端将无法建立连接。

以配置好的redis.conf启动redis server service

[root@controller ~]# redis-server /etc/redis/redis.conf

验证 redis 已正常监听并可读写：

[root@controller ~]# ss -lntp | grep 6379
[root@controller ~]# redis-cli -h 10.60.10.151 ping
PONG

ss 应显示 10.60.10.151:6379 处于 LISTEN，redis-cli 应返回 PONG。两条都对，才说明 Gnocchi 后面能连上协调后端。

redis服务不会开机自启动，可以将上述命令放入开机启动项里，否则每次开机都需要手动启动

编辑配置文件 /etc/rc.d/rc.local

[root@controller ~]# vi /etc/rc.d/rc.local

并新增以下内容

redis-server /etc/redis/redis.conf

保存退出后，赋予 /etc/rc.d/rc.local 文件执行权限

[root@controller ~]# chmod +x /etc/rc.d/rc.local

说明：rc.local 默认不具备执行权限，赋予执行权限后 systemd 才会在开机时调用该脚本，因此 chmod +x 不能省略。

注意：这里不要改用 systemctl enable redis。安装包自带的 redis.service 是 Type=notify + --daemonize no（前台运行），而我们在 redis.conf 里设置了 daemonize yes（后台运行），两者冲突，用 systemctl 启动会失败。要么按本节用 rc.local，要么把 daemonize 改回 no 后再用 systemctl，二选一，不要混用。

步骤5 启动Gnocchi

初始化gnocchi数据库

[root@controller ~]# gnocchi-upgrade

说明：gnocchi-upgrade 失败时最常见的两个原因，一是 [indexer] 的口令没有转义成 %40，二是 MariaDB 还没启动（systemctl status mariadb）。

执行成功后数据库 gnocchi 中会生成 resource、metric、archive_policy 等数据表，可确认：

[root@controller ~]# mysql -u root -pHuawei@123 -e "use gnocchi; show tables;"

赋予 /var/lib/gnocchi 文件可读写权限

[root@controller ~]# chmod -R 777 /var/lib/gnocchi

启动Gnocchi服务并将其配置为在系统引导时启动

[root@controller ~]# systemctl enable openstack-gnocchi-api.service openstack-gnocchi-metricd.service
[root@controller ~]# systemctl start openstack-gnocchi-api.service openstack-gnocchi-metricd.service

查看Gnocchi服务状态

[root@controller ~]# systemctl status openstack-gnocchi-api.service openstack-gnocchi-metricd.service

正常的输出应包含 Active: active (running)（两个服务各一处），且 8041 端口处于监听状态：

[root@controller ~]# ss -lntp | grep 8041

预期输出中地址为 10.60.10.151:8041。若端口没有监听，先看 /var/log/gnocchi/api.log，十有八九是 [api] host 填成了主机名。

说明：openstack-gnocchi-api.service 与 gnocchi-api.service 指向同一个服务单元，systemctl status 中显示的名称为后者属正常现象。

任务二：Ceilometer安装配置

步骤1 Ceilometer安装

创建对应Keystone资源对象

[root@controller ~]# openstack user create --domain default --password Huawei@123 ceilometer
[root@controller ~]# openstack role add --project service --user ceilometer admin
[root@controller ~]# openstack service create --name ceilometer --description "Telemetry" metering

说明：本实验只创建 metering 服务实体，不需要为它创建 endpoint。Ceilometer 组件之间通过消息队列通信，不对外提供 REST API，因此没有 endpoint 是正常的。

安装Ceilometer

[root@controller ~]# yum -y install openstack-ceilometer-notification openstack-ceilometer-central

步骤2 Ceilometer配置

编辑配置文件 /etc/ceilometer/pipeline.yaml 并完成以下操作

[root@controller ~]# cp /etc/ceilometer/pipeline.yaml /etc/ceilometer/pipeline.yaml.bak
[root@controller ~]# vi /etc/ceilometer/pipeline.yaml

注意：publishers 不是文件的顶层键，而是位于 sinks 下的 meter_sink 中。请不要在文件末尾新增一个顶层 publishers 段落，那会让 Ceilometer 找不到发布端。做法是：定位到文件末尾的 sinks: → - name: meter_sink → publishers:，只把其中的 - gnocchi:// 这一行改成下面这行，其余保持不动：

      publishers:
          - gnocchi://?filter_project=service&archive_policy=low

修改完成后，文件的末尾结构应如下所示（重点是缩进层级）：

sinks:
    - name: meter_sink
      publishers:
          - gnocchi://?filter_project=service&archive_policy=low

参数含义：archive_policy=low 指定写入 Gnocchi 时使用名为 low 的归档策略（默认 300 秒粒度），任务四查到的 granularity 就是 300；filter_project=service 用于过滤掉 gnocchi 自身（service 项目）产生的样本，避免“自己采自己”形成循环，它不是用来限定只采集某个项目的资源。修改后可用 Python 校验 YAML 是否合法：

[root@controller ~]# python3 -c "import yaml;print(yaml.safe_load(open('/etc/ceilometer/pipeline.yaml'))['sinks'])"

能正常打印出 sinks 列表（不报 ScannerError）即表示格式正确。

编辑配置文件 /etc/ceilometer/ceilometer.conf 并完成以下操作：

[root@controller ~]# cp /etc/ceilometer/ceilometer.conf /etc/ceilometer/ceilometer.conf.bak
[root@controller ~]# vi /etc/ceilometer/ceilometer.conf

注意：与 gnocchi.conf 一样，ceilometer.conf 也是完整模板，[DEFAULT]、[notification]、[polling]、[service_credentials] 段落均已存在，请在对应段落内修改，不要重复添加段落。

配置身份认证方式以及消息列队访问

[DEFAULT]
    
debug = true
auth_strategy = keystone
transport_url = rabbit://openstack:Huawei%40123@controller:5672/
pipeline_cfg_file = pipeline.yaml

配置日志消息窗口

[notification]
    
store_events = true
messaging_urls = rabbit://openstack:Huawei%40123@controller:5672/

定义轮询配置文件

[polling]
    
cfg_file = polling.yaml

说明：transport_url 与 messaging_urls 中的 openstack 为 RabbitMQ 中已有的用户，其口令与 nova.conf 中的取值保持一致（URL 中的 @ 转义为 %40）。auth_strategy 为兼容旧版本保留的参数，当前版本的 Ceilometer 已不再使用，保留不影响服务运行。

配置服务凭据

[service_credentials]
    
auth_type = password
auth_url = http://controller:5000/v3
project_domain_id = default
user_domain_id = default
project_name = service
username = ceilometer
password = Huawei@123
interface = internalURL
region_name = RegionOne

初始化数据库

[root@controller ~]# ceilometer-upgrade

注意：Gnocchi必须在这个阶段状态为运行（任务一 步骤5 已启动）。执行成功后，Gnocchi 中会被创建 instance、volume、image 等资源类型，可通过 gnocchi resource-type list 确认。

这一步的常见报错是 Could not connect to Gnocchi：先确认 8041 端口在监听，再确认 [service_credentials] 里的 project_name（service）与 username（ceilometer）拼写无误。

步骤3 启动服务

启动Ceilometer服务

[root@controller ~]# systemctl enable openstack-ceilometer-notification.service openstack-ceilometer-central.service
[root@controller ~]# systemctl start openstack-ceilometer-notification.service openstack-ceilometer-central.service

查看Ceilometer服务状态

[root@controller ~]# systemctl status openstack-ceilometer-notification.service openstack-ceilometer-central.service

两个服务都应为 Active: active (running)。

启动后若 notification 代理正常订阅消息队列，rabbitmqctl list_queues 中可看到 notifications.info、notifications.error 等队列，且消费者数量为 1：

[root@controller ~]# rabbitmqctl list_queues name consumers | grep notifications

预期输出（7 个队列，每个消费者的数量都是 1）：

notifications.audit	1
notifications.critical	1
notifications.debug	1
notifications.error	1
notifications.info	1
notifications.sample	1
notifications.warn	1

若某个队列的消费者数量为 0，说明 notification 代理没订上，先看 /var/log/ceilometer/agent-notification.log 里有没有认证失败（401）的记录。

步骤4 Ceilometer-compute、ipmi安装与配置

（计算节点操作，本实验环境在 controller 上执行）

openstack-ceilometer-compute 提供计算节点侧的采集代理（polling agent），openstack-ceilometer-ipmi 为可选的带外硬件采集插件。

[root@controller ~]# yum -y install openstack-ceilometer-compute
[root@controller ~]# yum -y install openstack-ceilometer-ipmi

说明：本环境未安装 libvirt，openstack-ceilometer-compute 启动后日志里会出现 Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro' 的报错，属正常现象，不影响本实验。本实验实际使用到的数据来自 notification 代理，与 compute 代理无关，该组件按手册安装即可。

任务三：配置Nova与通知源

注意：请在配置 nova 前，确保 nova 已正确安装并正常运行（systemctl is-active openstack-nova-api openstack-nova-conductor openstack-nova-scheduler）。

本实验环境为单节点部署，控制节点与计算节点为同一台虚拟机，因此任务三的全部操作均在 controller 上执行。

为什么任务三很重要：Ceilometer 的数据来源是各组件的 notification 消息。Nova 和 Cinder 默认都不发通知，本任务就是把这两个开关打开。跳过本任务，任务四将查不到任何数据。

步骤1 配置Nova

编辑 /etc/nova/nova.conf 文件并在以下 [DEFAULT] 部分配置消息通知：

[root@controller ~]# cp /etc/nova/nova.conf /etc/nova/nova.conf.bak
[root@controller ~]# vi /etc/nova/nova.conf

[DEFAULT]
instance_usage_audit = True
instance_usage_audit_period = hour
    
[notifications]
notify_on_state_change = vm_and_task_state
    
[oslo_messaging_notifications]
driver = messagingv2

注意：[notifications] 与 [oslo_messaging_notifications] 两个段落默认配置文件中不存在，需要手工新增；instance_usage_audit 等两项写入已有的 [DEFAULT] 段落。修改完成后必须重启 Nova 服务使配置生效：

[root@controller ~]# systemctl restart openstack-nova-api.service openstack-nova-conductor.service openstack-nova-scheduler.service
[root@controller ~]# systemctl is-active openstack-nova-api.service openstack-nova-conductor.service openstack-nova-scheduler.service
active
active
active

若重启后服务未处于 active 状态，说明 nova.conf 存在语法错误，可用 grep -n "^\[" /etc/nova/nova.conf 检查段落是否重复。

步骤2 配置Cinder通知

本环境的虚拟机里没有运行中的实例（没有 nova-compute），能拿来做计量演示的只有云硬盘。Cinder 默认同样不发通知，需要打开：

[root@controller ~]# cp /etc/cinder/cinder.conf /etc/cinder/cinder.conf.bak
[root@controller ~]# vi /etc/cinder/cinder.conf

在文件中找到已存在的 [oslo_messaging_notifications] 段落，把被注释掉的 driver 一行改为（若段落不存在则手工新增）：

[oslo_messaging_notifications]
driver = messagingv2

重启 cinder-volume 使配置生效，并确认状态：

[root@controller ~]# systemctl restart openstack-cinder-volume.service
[root@controller ~]# systemctl is-active openstack-cinder-volume.service
active

说明：volume.create.end 这类云硬盘通知由 cinder-volume 发出，因此重启它即可。若环境中还运行着 openstack-cinder-api、openstack-cinder-scheduler，一并重启也无副作用。

验证是否配好：grep -A3 "^\[oslo_messaging_notifications\]" /etc/cinder/cinder.conf 能看到 driver = messagingv2（不是 #driver）。这一步不会立即产生数据，要到任务四创建云硬盘后才有。

步骤3 配置轮询ipmi

在计算节点执行以下操作（本实验环境在 controller 上执行）

先确认安装包是否已经自带 rootwrap 免密规则——多数情况下已经自带，无需手工修改：

[root@controller ~]# cat /etc/sudoers.d/ceilometer
Defaults:ceilometer !requiretty
ceilometer ALL = (root) NOPASSWD: /usr/bin/ceilometer-rootwrap /etc/ceilometer/rootwrap.conf *

若上面已经输出了这条 ceilometer ALL = ... 规则，本步到此结束，跳到下面的 polling.yaml 配置。只有在文件不存在或规则缺失时，才需要编辑 /etc/sudoers 手工添加：

[root@controller ~]# visudo

ceilometer ALL = (root) NOPASSWD: /usr/bin/ceilometer-rootwrap /etc/ceilometer/rootwrap.conf * 

注意：用 visudo 编辑最稳妥，它会在保存时自动校验语法，比 vi /etc/sudoers 再 :wq! 强制保存安全（sudoers 语法写错会导致 sudo 不可用）。保存后也可执行 visudo -c，输出 parsed OK 即为正常。

编辑 /etc/ceilometer/polling.yaml，添加以下度量项目：

[root@controller ~]# cp /etc/ceilometer/polling.yaml /etc/ceilometer/polling.yaml.bak
[root@controller ~]# vi /etc/ceilometer/polling.yaml

    - name: ipmi
      interval: 300
      meters:
          - hardware.ipmi.temperature

注意：格式对齐。polling.yaml 的 sources 是一个列表，新增内容必须追加在文件末尾，并与已有的 - name: some_pollsters 处于同一层级：- name 前 4 个空格，interval、meters 前 6 个空格，meters 列表项前 10 个空格。追加完成后文件的结构应如下所示：

sources:
    - name: some_pollsters
      interval: 300
      meters:
        - cpu
        ...
    - name: ipmi
      interval: 300
      meters:
          - hardware.ipmi.temperature

添加完成后可用 Python 校验 YAML 格式是否正确，若输出两个数据源名称即表示格式无误：

[root@controller ~]# python3 -c "import yaml;d=yaml.safe_load(open('/etc/ceilometer/polling.yaml'));print([s['name'] for s in d['sources']])"
['some_pollsters', 'ipmi']

修改 polling.yaml 后需要重启中央代理使配置生效：

[root@controller ~]# systemctl restart openstack-ceilometer-central.service

说明：若这里报 ScannerError，多半是缩进用 Tab 或空格数不对；若输出的列表里只有 some_pollsters，说明新增内容被追加到了文件最外层（顶格写的），也会被 YAML 解析成非法结构。

步骤4 启动代理

在计算节点执行以下操作（本实验环境在 controller 上执行）

启动代理并将其配置为在系统引导时启动

[root@controller ~]# systemctl enable openstack-ceilometer-compute.service 
[root@controller ~]# systemctl start openstack-ceilometer-compute.service 

[root@controller ~]# systemctl enable openstack-ceilometer-ipmi.service (optional)
[root@controller ~]# systemctl start openstack-ceilometer-ipmi.service (optional) 

注意：上面两条 ipmi 命令末尾的 (optional) 只是标注该服务为可选项，实际执行时不要输入 (optional) 这几个字符。

说明：openstack-ceilometer-ipmi.service 为可选服务，需要物理服务器具备 IPMI 管理接口。在虚拟机环境中该服务虽可启动，但无法采集到带外硬件数据，日志中会出现 IPMI 相关报错，未部署 IPMI 硬件时可略过该服务的启动（不影响本实验的任何验证结果）。

重新启动Compute服务

[root@controller ~]# systemctl restart openstack-nova-compute.service

环境适配说明：本实验虚拟机为单节点部署，仅安装 nova-api、nova-conductor、nova-scheduler 等控制节点组件，未安装 nova-compute 及 libvirt。因此执行上述命令会提示：

Failed to restart openstack-nova-compute.service: Unit openstack-nova-compute.service not found.

该提示不影响本实验的安装与配置结果，步骤1中重启控制节点 Nova 服务即已使通知配置生效。若在已部署计算节点的环境中执行本实验，则需在计算节点上执行该命令重启 nova-compute。

任务四：验证

在控制节点执行以下操作

注意：请确保前面所有内容安装配置无误后再进行以下验证操作。执行前请先加载管理员凭证：

[root@controller ~]# source /root/.admin-openrc

步骤1 创建计量对象（云硬盘）

为什么要先建云硬盘：Ceilometer 只是“消息的搬运工”，没有组件发通知就没有数据可查。本环境没有运行中的实例，云硬盘是唯一能在几十秒内产生一条完整计量链路的对象。

[root@controller ~]# openstack volume create --size 1 telemetry-vol

[root@controller ~]# openstack volume list

预期能看到 telemetry-vol，Status 为 available。

确认云硬盘可用后，等待约 30 秒再做步骤2 的查询（实测资源在 20~30 秒内写入 Gnocchi）。其中度量数据点由 metricd 按周期处理（metric_processing_delay = 60），若 measures show 一时为空，再等 1 分钟重试即可。

如果只想验证“链路是否通”、不想建云硬盘，可以直接跳到步骤2 执行 gnocchi resource-type list——只要有 instance、volume、image 等类型输出，就说明 ceilometer-upgrade 成功、Ceilometer 与 Gnocchi 的对接正常。但 resource list / metric list 需要真实数据，必须靠这一步产生。

步骤2 在控制节点验证

列出所有计量resource资源

[root@controller ~]# gnocchi resource list 

说明：资源列表来自 Ceilometer 采集到的数据，type 为 instance 的记录对应虚拟机，volume 对应云硬盘，image 对应镜像。输出列较多（id、type、project_id、user_id、original_resource_id、started_at、creator 等），这里只摘录关键列：

id	type	original_resource_id
c02f6f5f-79b1-4601-9265-2abe3b848218	volume	c02f6f5f-79b1-4601-9265-2abe3b848218

只要 type 列出现 volume 一行，任务四的关键目标就达成了。本环境没有实例，看不到 instance 类型是正常的；如果连 volume 也没有，按本节末尾的排查清单逐条检查（最常见的原因是任务三 步骤2 的 Cinder 通知没配或没重启）。

[root@controller ~]# gnocchi resource-type list

这条命令列出 Gnocchi 中已注册的资源类型（instance、volume、image、network 等）。它与采集到的数据无关，只要有输出就说明 ceilometer-upgrade 执行成功，可以作为“链路通”的最低验收点。

列出所有可计量的metric计量类型

[root@controller ~]# gnocchi metric list 

预期输出如下（archive_policy 为 low，与 pipeline.yaml 中的 archive_policy=low 对应；resource_id 即上一步资源列表中的 id）：

+--------------------------------------+---------------------+-------------+------+--------------------------------------+
| id                                   | archive_policy/name | name        | unit | resource_id                          |
+--------------------------------------+---------------------+-------------+------+--------------------------------------+
| 986cb99b-df1f-4341-b60e-0ae215810af6 | low                 | volume.size | GB   | c02f6f5f-79b1-4601-9265-2abe3b848218 |
+--------------------------------------+---------------------+-------------+------+--------------------------------------+

查看某条度量的采集数据

[root@controller ~]# gnocchi measures show ID

说明：命令中的 ID 需替换为上一步 gnocchi metric list 中查到的 id（度量 ID，不是资源 ID）。为方便复制，可用下面两条命令一步到位：

[root@controller ~]# gnocchi metric list -c id -c name -c resource_id
[root@controller ~]# gnocchi measures show <上一步查到的度量ID>

正常的输出示例如下（granularity 为 300 秒，取自 archive_policy=low；value 为云硬盘容量 1 GB）：

+---------------------------+-------------+-------+
| timestamp                 | granularity | value |
+---------------------------+-------------+-------+
| 2026-11-10T21:35:00+08:00 |       300.0 |   1.0 |
+---------------------------+-------------+-------+

只要这张表里有至少一行 value，就说明“组件发通知 → Ceilometer 消费 → 发布到 Gnocchi → metricd 入库”整条链路已经打通，本实验完成。若表里没有数据行，再等 1 分钟重试一次，metricd 是按周期处理的。

若 gnocchi resource list 或 gnocchi metric list 结果为空，按以下顺序排查：

1. systemctl status openstack-ceilometer-notification.service openstack-ceilometer-central.service 确认两个代理为 active；
2. rabbitmqctl list_queues name consumers | grep notifications 确认 7 个通知队列的消费者数量为 1；
3. 确认任务三 步骤2 已为 Cinder 配置 driver = messagingv2 并重启过 openstack-cinder-volume（漏了这步，后面查什么都是空的）；
4. 确认任务四 步骤1 的云硬盘已创建成功，且是在配置 Cinder 通知 之后 创建的（配置之前创建的云硬盘不会补发通知）；
5. tail -50 /var/log/ceilometer/agent-notification.log，看有没有资源创建失败、认证失败（401）的错误；
6. 确认 pipeline.yaml 中 meter_sink 下的 publishers 已改为 gnocchi://?filter_project=service&archive_policy=low（且没有被写成文件顶层的 publishers）；
7. 确认 Gnocchi 的 [api] host、Redis 的 bind 均填写为控制节点管理 IP，且 8041、6379 端口处于监听状态。

实验小结

完成Gnocchi与Ceilometer的安装与配置，实现Ceilometer能够采集、监控OpenStack其他组件的数据。

本实验的关键点可归纳为：

1. Gnocchi 由 API 服务（gnocchi-api）与后台处理服务（gnocchi-metricd）组成，依赖 MariaDB 存储资源元数据、依赖 Redis 完成多进程间的协调（coordination），时序数据本身存放在 file 后端（/var/lib/gnocchi）。
2. Ceilometer 通过消息队列消费 OpenStack 各组件的通知（notification），并按 pipeline.yaml 中的发布端（publisher）把数据写入 Gnocchi。
3. ceilometer-upgrade 负责在 Gnocchi 中创建 Ceilometer 所需的资源类型，因此必须在 Gnocchi 正常运行之后执行。
4. 光装 Ceilometer 是不够的：数据源头的组件（Nova、Cinder 等）必须打开 notification，否则 pipeline.yaml 配得再对，也没有消息可消费。

思考题

1. ceilometer-upgrade 命令的作用是？

答：在 Gnocchi 中创建 Ceilometer 采集所需的资源类型（resource type），如 instance、volume、image、network 等，并把 Ceilometer 的计量项映射到这些资源类型的属性上。因此它必须在 Gnocchi 正常运行之后执行，且只需在首次部署或升级时执行。

2. 本实验中为什么需要安装 redis，redis 与 MariaDB 在本实验中的作用有何区别？

答：redis 数据库可作为 Gnocchi 的后端存储，Gnocchi 目前支持不同的存储后端，如 File、Ceph、OpenStack Swift、Redis、S3；MariaDB 存储了 OpenStack 用户创建的对象及其状态信息。

补充说明：本实验的配置中，时序数据实际存放在 file 后端（[storage] driver = file，路径 /var/lib/gnocchi），Redis 承担的是 Gnocchi 各服务进程之间的协调（coordination_url）职责，用于分布式锁与任务分发；MariaDB 则保存资源、度量、归档策略等元数据。二者缺一不可，但作用不同。

3. 如果没有给 Cinder/Nova 打开 notification，装上 Ceilometer 能查到数据吗？

答：不能。Ceilometer 不主动采集业务数据，它只消费组件发到消息队列的 notification。组件不开通知，队列里没有消息，gnocchi resource list、gnocchi metric list 都是空表，但服务状态、端口、资源类型都完全正常——这类“装好了但没数据”的问题，最容易误判成安装失败。

附录：常用排查命令

# 查看 Gnocchi / Ceilometer 服务状态
systemctl status openstack-gnocchi-api.service openstack-gnocchi-metricd.service
systemctl status openstack-ceilometer-notification.service openstack-ceilometer-central.service
systemctl is-active openstack-cinder-volume.service openstack-nova-api.service

# 查看端口监听（8041 Gnocchi API，6379 Redis，5000 Keystone）
ss -lntp | grep -E "8041|6379|5000"

# 查看日志
tail -n 50 /var/log/gnocchi/api.log
tail -n 50 /var/log/ceilometer/agent-notification.log
journalctl -u openstack-ceilometer-compute.service -n 50 --no-pager

# 校验配置文件语法
python3 -c "import yaml;print(yaml.safe_load(open('/etc/ceilometer/pipeline.yaml')))"
python3 -c "import yaml;print([s['name'] for s in yaml.safe_load(open('/etc/ceilometer/polling.yaml'))['sources']])"
visudo -c

# 确认通知驱动是否开启（关键）
grep -A3 "^\[oslo_messaging_notifications\]" /etc/cinder/cinder.conf
grep -n "^driver = messagingv2" /etc/nova/nova.conf /etc/cinder/cinder.conf

# 确认通知队列有消费者
rabbitmqctl list_queues name consumers | grep notifications

# 查看 Keystone 中 metric / metering 服务与端点
openstack service list | grep -E "gnocchi|ceilometer"
openstack endpoint list --service gnocchi

# 查看计量对象与数据
openstack volume list
gnocchi resource list
gnocchi metric list