在OpenStack控制节点上装完Keystone、Nova、Glance之后很多人会面对同一个疑问怎么才能知道某一台虚拟机过去一个月一共用了多少CPU时间、走了多少网络流量几个面板上看来看去只有运行状态和配置信息这些“用量数据”几乎完全空白。这时候就需要安装Ceilometer——OpenStack生态里的数据采集服务也就是常说的Telemetry遥测模块。Ceilometer负责把虚拟机、宿主机、各服务组件的资源使用数据按采样周期收集起来统一上报供监控看板、计费系统、告警策略去消费。这篇文章写给正在按组件逐个部署OpenStack的运维人员也写给那些Ceilometer装上了、API也能访问但页面上就是没有监控数据的开发者。我会从它到底采集什么、在整个云平台里的数据流向是什么开始然后给出控制节点和计算节点的完整安装步骤最后用真实排障过程说明“数据不流动”这类最常见问题该怎么查。1. 为什么是Ceilometer而不是别的采集器先搞清楚它在云平台里的角色很多人在装Ceilometer之前会先问一句Zabbix、Prometheus不也能采集指标吗这是值得先厘清的问题。Ceilometer在OpenStack里的定位是计量Metering和遥测Telemetry的数据生产者不是传统意义上的主机监控Agent。它关注的是“这台虚拟机用了多少资源”而不是“这台物理机CPU负载是否过高”。传统监控和Ceilometer的侧重点有交集但设计目标完全不同。1.1 计量、监控和计费的数据源头Ceilometer采集的数据分成两类一类是轮询Polling样本一类是事件通知Notification样本。轮询类样本是由Central Agent在控制节点上定期发起请求通过OpenStack各服务的API查询资源使用量。比如通过Nova API查虚拟机CPU时间、内存占用通过Neutron API查网络流量计数通过Cinder API查块设备的读写字节数。这种方式适合获取“物理层面的资源用量”是最接近业界监控Agent的采集手段。通知类样本则不一样。OpenStack各服务在运行过程中会往消息队列RabbitMQ发很多事件通知比如虚拟机创建成功、删除实例、快照完成。Notification Agent会订阅这些消息把其中的计量事件转换成一个标准化的样本。这种方式能拿到很多轮询拿不到的信息像“某台虚拟机创建时间”“这个实例是什么镜像启动的”“谁在什么时间执行了resize操作”。理解这两类样本的区别后面排查“为什么没有数据”非常关键。轮询类样本依赖Polling Agent的配置目标是否正确通知类样本依赖Nova等服务的notification_driver是否真正把消息发到了RabbitMQ。很多人安装完Ceilometer仅仅是API起来了、数据库也建了但两类样本一条都进不来就是因为这两个链路里至少有一个是断的。1.2 新旧版本架构差异从MongoDB时代到Gnocchi时代早期的Keystone先不看……这里直接说版本差异。在OpenStack Ocata版本之前Ceilometer自己存储采集到的数据后端默认是MongoDB同时它自己也提供API给你查原始样本。后来社区觉得这个设计不够合理Ceilometer既当生产者又当存储还对外提供查询接口压力过大不说存储的扩展性也不好所以在后续版本里把存储和对外查询拆了出去由Gnocchi负责指标存储和聚合查询Ceilometer只保留采集和分发能力。新架构下Ceilometer和Gnocchi配合的时候数据链路是Polling/Notification Agent → RabbitMQ → Dispatcher分发器→ Gnocchi存储 → 通过Gnocchi API对外查询。Ceilometer本身不再直接对用户提供一整套数据查询界面它变成了管道最上游的“水龙头”。做计费系统或运营大屏的人只需要从Gnocchi拿聚合后的指标数据不需要关心Ceilometer后台的采集细节。Gnocchi还带来了一个好处指标数据可以设置保留时间会自动降采样。原始样本可以保留一天小时精度的数据保留一个月日精度的数据保留一年存储成本远低于MongoDB全量保存方案。这也是后来我给别人做部署方案时默认只装Gnocchi不装MongoDB的原因。2. 安装前必须核对的环境前提与组件联动动手安装之前先把依赖关系核对一遍。Ceilometer本身不是一个“装了就能跑”的孤立服务它跟你环境里已经部署的Keystone、RabbitMQ、MariaDB都有直接关联。尤其是在Train版本我下面示例用的是这个版本线的二进制包里缺了任何一环服务能启动但数据流一定会卡壳。2.1 前置服务清单与端口规划我们先看看控制节点上需要提前存在并正常运行的服务KeystoneCeilometer所有服务都需要通过Keystone做认证API服务的endpoint注册也需要Keystone。RabbitMQ两类Agent产生的样本都会先发到消息队列再由dispatcher处理后写入Gnocchi没有RabbitMQ就等于没有数据通路。MariaDBCeilometer自己的资源定义、样本元数据映射以及Gnoccchi的索引数据都需要数据库保存。Gnocchi作为指标存储后端负责把Ceilometer送来的sample聚合保存。如果不想装Gnocchi而使用其他dispatcher也可以但边缘场景很少不建议那么干。Memcached主要用于token缓存不改的话问题不大但生产环境强烈建议配上。端口规划和建议见下表按默认端口配置避免后面防火墙排查走弯路服务端口说明Ceilometer API8777控制节点监听外部查询/管理用Gnocchi API8041Gnocchi在Train版上的默认端口RabbitMQ5672消息总线通讯端口Memcached11211Keystone token缓存提示如果你用的发行版包是更高版本比如Ussuri之后的Gnocchi API端口可能是8041也可能是配置里自定义的。先确认再开防火墙别照搬。另外Gnocchi和Ceilometer是两个独立项目各自有自己的配置文件和服务进程。现实中常有人把这两套东西混在一起说排查问题的时候频道就对不上了。建议先明确本轮安装目标只是让Ceilometer能正确发出采样数据Gnocchi专心做存储。2.2 计算节点上的Nova通知配置这是最容易漏掉、却直接影响通知类样本能否产生的环节。在计算节点上修改/etc/nova/nova.conf确保以下两个配置项存在且生效[DEFAULT] notification_driver messaging notify_on_state_change vm_state instance_usage_audit True instance_usage_audit_period hournotification_drivermessaging告诉Nova在发生状态变更时把通知消息发到消息总线而不是打印到日志就结束。notify_on_state_changevm_state表示只要虚拟机状态发生变化就会发通知这对Ceilometer拿到生命周期事件至关重要。instance_usage_audit和instance_usage_audit_period配合让Nova每小时自动审计一遍实例用量并生成周期性的通知样本。这个机制是周期型通知样本的主要来源也是很多人装完没数据之后第一个应该怀疑的对象。改完配置文件后一定要重启nova-compute服务。在某些发行版里nova-compute重启会导致宿主机上虚拟机短暂中断尤其是KVM环境所以实际操作时建议选择维护窗口或者只在一台计算节点上先验证。我当时第一次全量部署时为了省事没有重启配完Ceilometer之后通知类样本一条都没有查了一下午才发现是nova-compute还跑着旧配置。还要留意Neutron的通知配置。如果你的环境装了Neutron并且计划采集网络流量样本需要在neutron.conf里同步配置[DEFAULT] notification_driver messagingNeutron没有那么多状态变更事件但端口创建、网络创建这类事件的计量需求在租户用量审计里很常见建议顺手配上。3. 控制节点安装与核心参数逐项解析控制节点的安装步骤比较规整建数据库、建Keystone用户、安装二进制包、改配置文件、同步数据库、启动服务。每步单独讲解。3.1 软件包安装与数据库初始化先建数据库避免后面服务起来后连不上库。以管理员身份登录MariaDBCREATE DATABASE ceilometer DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; GRANT ALL PRIVILEGES ON ceilometer.* TO ceilometerlocalhost IDENTIFIED BY 你设置的密码; GRANT ALL PRIVILEGES ON ceilometer.* TO ceilometer% IDENTIFIED BY 你设置的密码; FLUSH PRIVILEGES;到这里数据库名字用的是ceilometer。注意Ceilometer自己的库很小主要存样本的索引定义和资源元信息真正的时间序列数据在Gnocchi里不在这个库里。然后创建Keystone用户、赋予admin角色注册服务openstack user create --domain default --password 你设置的密码 ceilometer openstack role add --project service --user ceilometer admin openstack service create --name ceilometer --description Telemetry service metering openstack endpoint create --region RegionOne metering public http://controller:8777 openstack endpoint create --region RegionOne metering internal http://controller:8777 openstack endpoint create --region RegionOne metering admin http://controller:8777这里service type用的是metering这是Ceilometer在Keystone里注册的固定类型不是随便起的名字。后续所有客户端要发现Ceilometer API都是依靠这个类型来找endpoint的。提示controller这个主机名要换成你环境里实际使用的Keystone API主机名不然服务能注册成功客户端解析时却找不到对应的VIP或域名。接着安装软件包。以RHEL系发行版为例dnf install -y openstack-ceilometer-api openstack-ceilometer-central openstack-ceilometer-notification openstack-ceilometer-common python3-ceilometermanager如果发行版仓库里把ceilometer-central和ceilometer-notification合并了按实际包名安装就行。关键是要确认openstack-ceilometer-api这个包存在它是API服务的承载进程。3.2 ceilometer.conf里最容易忽略的五个参数安装包完成之后重点全在/etc/ceilometer/ceilometer.conf这个文件上。文件默认很大大部分是注释掉的示例实际生效配置并不多。我先重点挑五个高频出问题的参数来讲。文件开头部分是传达URL配置Ceilometer如何连接RabbitMQ。格式如下[DEFAULT] transport_url rabbit://openstack:密码controller:5672transport_url是OpenStack所有服务统一的消息总线连接配置。当前环境里的openstack用户是RabbitMQ上专用的账号。你可以沿用安装RabbitMQ时创建的用户也可以单独建一个ceilometer专用账号更清晰。接下来是Keystone认证配置分两段[keystone_authtoken] auth_url http://controller:5000 www_authenticate_uri http://controller:5000 memcached_servers controller:11211 auth_type password project_domain_name Default user_domain_name Default project_name service username ceilometer password 你设置的密码 [service_credentials] auth_url http://controller:5000 region_name RegionOne project_domain_name Default user_domain_name Default project_name service username ceilometer password 你设置的密码 interface internalkeystone_authtoken段里那个www_authenticate_uri极易被忽略不配置的话API服务响应401时会拿不到正确的认证地址客户端会一脸懵。service_credentials是Ceilometer自己内部用admin身份去访问Nova、Neutron等服务的凭据所以username和password要填有admin权限的账号。不要试图在这里填一个普通项目用户出于安全考虑可能有人会想“用最小权限账号”但Ceilometer要访问所有租户的资源用量普通用户角色拿不到别的项目数据。接下来是notification和polling的消费队列[oslo_messaging_notifications] topics notifications [dispatcher_gnocchi] filter_service_activity Truetopics的默认值是notifications如果你在Nova和Neutron里自定义了notification topics这里必须对应上。dispatcher_gnocchi段的filter_service_activity是控制是否把Ceilometer自己内部的活动也上报默认设为True避免自己的操作污染业务数据。最后是polling的采样配置这个不是写在ceilometer.conf里而是在/etc/ceilometer/polling.yaml。默认文件已经有了标准资源定义比如CPU、内存、磁盘IO但需要确认sources: - name: my_pollster interval: 600 meters: - cpu - memory - disk.* resources: - *interval默认600秒。生产环境如果要多粒度数据可以改成300甚至60但代价是Gnocchi的存储压力和API请求量会成倍上升。我建议先用默认值把链路跑通确认没问题后再降低采样间隔。初学阶段频繁调整采样配置很容易把“配置没生效”和“链路有故障”混在一起排查。3.3 服务启动与注册验证配置写完后同步数据库su -s /bin/sh -c ceilometer-dbsync ceilometer输出没有任何报错就代表同步成功。这里要提一句ceilometer-dbsync在旧版MongoDB时代会连MongoDB做建表迁移新版本则只对MySQL执行操作。别把两个时代的问题混淆。然后启动控制节点上三个服务systemctl enable --now openstack-ceilometer-api openstack-ceilometer-notification openstack-ceilometer-central检查服务状态systemctl status openstack-ceilometer-api ss -tlnp | grep 8777API端口正常监听后用命令行验证一下openstack metric list这条命令会通过Gnocchi API查询指标。如果返回列表为空至少说明Keystone认证、Gnocchi连接和API链路是通的。接下来才算真正进入“采集”环节的验证。4. 计算节点Agent部署采集动作真正落地的地方控制节点上的服务只是管调度和分发的真正产生轮询样本的Agent在计算节点上。很多初次部署的人只装了控制节点发现没有任何指标数据其实是因为根本没在计算节点装采集Agent。4.1 安装openstack-ceilometer-compute在每一台计算节点上执行dnf install -y openstack-ceilometer-compute然后修改/etc/ceilometer/ceilometer.conf。计算节点上的配置不需要central和notification那么全重点保留transport_url、keystone_authtoken、service_credentials这几项跟控制节点保持一致。absolute路径下的polling.yaml默认就有了不需要额外创建。改完配置后启动服务systemctl enable --now openstack-ceilometer-compute检查日志journalctl -u openstack-ceilometer-compute -f正常情况下日志里会周期性出现“Polling pollster ...”之类的信息。如果完全没有任何输出先看服务是不是启动失败或者被SELinux挡住了。Try to see selinux status first。有一个比较烦的问题计算节点上的服务虽然叫compute但它做的事不只是polling也会作为notification agent消费RabbitMQ里的nova通知。所以计算节点上如果新装完Ceilometer最好确认RabbitMQ上对应队列的消费者数量是否增加了。如果消费者数没变说明notification服务没有真正连上消息队列。4.2 验证样本从虚拟机到数据库的完整链路等Ceilometer跑完一个采样周期默认10分钟后可以做一次端到端验证。先看Gnocchi侧有没有数据进来openstack metric listGnocchi指标列表应该能出现以cpu、memory、disk开头的指标名。还可以进一步查询具体指标的值openstack metric measures show $(openstack metric list -f value -c id | head -1)如果这里能输出带时间戳和数值的记录说明完整链路已经通了计算节点Agent采集 → RabbitMQ → Dispatcher → Gnocchi存储 → 查询API。但如果列表里为空不用急着放弃先按下一章的排查路径走一遍。5. 问题排查我在这套环境里遇到的三个真实故障Ceilometer装起来不难真正的难点在数据不流动。我自己的经验是90%的“装好了但没数据”问题都出在链路断点而不是Coding或Bug。这里分享三起我实际遇到过的故障起了典型课代表的作用。5.1 查不到样本数据先查通知队列还是先查polling有一回我在一套测试云环境里部署完Ceilometer等了二十分钟Gnocchi里还是空空如也。第一反应是检查Central Agent的轮询配置polling.yaml里改的interval没问题啊Topology也没错。后面静下来把数据链路从头到尾捋了一遍才发现问题在Nova的通知配置。计算节点上nova.conf里确实写了notification_drivermessaging但notify_on_state_change写成了vm_state没错问题是没改完就重启了nova-compute然后nova-compute起来的时候直接从旧配置里读了notification_drivernova.openstack.common.notifier.rpc_notifier这个旧值。这个值在Train版本里已经废弃不产生任何消息。排查这类问题的核心手段是看RabbitMQ队列。Ceilometer会订阅的消息队列名通常是以notifications.info开头的topic。登录RabbitMQ管理页面或者用命令行工具rabbitmqctl list_queues name messages consumers如果notifications队列的message数是0说明根本没有消息进来。这时候去计算节点看nova-compute日志里有没有“notification”相关的报错。如果message有数但一直不减少说明Ceilometer侧没有消费那就是dispatcher配置的问题。这两个方向一定要区分。5.2 配置了polling但Gnocchi里没指标另一台控制节点上遇到了更诡异的问题RabbitMQ的notifications队列一直在持续增加Ceilometer的consumer也在线但Gnocchi里就是不出指标。这样持续了半小时。后来查了ceilometer-notification服务的日志发现反复出现ERROR ceilometer.notification [-] Failed to process sample: ... Timeout connecting to Gnocchi问题清楚了——Notification Agent在RabbitMQ里甚至看到消息了但它往Gnocchi送数据时连接超时。为什么超时因为Gnocchi的API监听地址配置成了127.0.0.1而Ceilometer跑在同一台主机上的不同服务用域名访问时解析到了IPv6地址跟127.0.0.1对不上。解决办法是把Gnocchi监听地址改成管理网络的IP并确认ceilometer.conf里的dispatcher_gnocchi段的url指向了Gnocchi的真实IP和端口。[dispatcher_gnocchi] url http://controller:8041这是我踩过最典型的“服务活着但通信失败”的坑。查这类问题不要只盯服务状态要看日志里有没有一条真实的网络链路报错。5.3 API认证401的排查链路第三起故障比较浅但足以卡住很多人。Ceilometer API装完后执行openstack metric list却爆401。二进制包新装环境下这种问题的概率非常高。排查思路其实简单先检查keystone_authtoken段和service_credentials段是否有拼写错误或额外的空格这是最常见的低级错误。我的失败案例是usernameceilometer写成了usernameceilometer多了一个空格YAML解析不出来导致认证头缺参数。其次检查端点注册。如果之前用旧的region或者project名注册过endpoint新客户端请求会拿着旧endpoint去认证也可能401。重新注册endpoint即可。最后如果密码包含特殊字符比如或者#YAML配置文件里必须加引号包起来否则解析会有问题。这是老生常谈但永远有人踩。6. 安装完成后的一次端到端验证供参考确认服务都启动、队列都正常之后可以做一个完整的端到端验证确认这套Ceilometer没有白装。我的习惯流程是创建一台临时虚拟机等待一个完整的采样周期10分钟然后依次检查三层数据。第一步查RabbitMQ队列是否收到nova通知rabbitmqctl list_queues name messages consumers | grep notification第二步查Gnocchi里有没有这台虚拟机的指标openstack metric list | grep -i instance会发现以vm_id为维度出现cpu、memory、disk等指标。用GnocchiAPI查数值openstack metric measures show --resource-id 虚拟机UUID cpu第三步用命令行查这台虚拟机在生产环境里的真实用量openstack server show --fit-width 虚拟机UUID我通常还会用一张临时看板验证数据是否在持续变化比如把CPU指标的采样结果每两分钟刷一次看数值是否跟随负载变化。如果几步都通过就说明采集、传输、存储、查询这条数据链路完全可用。这里有个小技巧Ceilometer的采样周期默认是600秒验证等起来实在太煎熬。临时把/etc/ceilometer/polling.yaml里的interval改成60秒验证完再改回去能大幅提升测试效率。记得改完后要重启openstack-ceilometer-central和openstack-ceilometer-compute使配置生效。这是我自己在测试环境里一直用的方式别提多省时间。还有一点值得说的是磁盘和网络指标的表现形式。磁盘、网络这类计数器类型的指标Ceilometer上报给Gnocchi后一般存的是速率或者增量差而不是绝对值。解读数据时不要指望Gnocchi里直接出现“本月磁盘总写入1TB”这种聚合值。聚合计算通常在计费系统里做Ceilometer只是提供原始样本。这个认知误区在不少开发同学那里反复出现。安装Ceilometer到最后一定要把服务计量的思路想清楚。它解决的是“用量数据从哪里来”的问题而不是“数据怎么展示”的问题。后续不管是接Aodh做告警、接Gnocchi做容量预测还是接自研计费系统都只是把你已经采集到的数据换一种方式消费。数据源头稳了上面的业务才能稳。
