在OpenStack这套体系里Ceilometer是个典型“不起眼但关键时刻坑你一把”的角色。它的大名是数据采集服务英文全称OpenStack Telemetry——记住这个词后面搜资料会频繁遇到。部署排期上Ceilometer经常被排到Nova、Neutron之后很多人觉得晚点装没什么可真到了要出计量报表、要做调度决策、要接告警的时候才发现采集这层没铺好上面全得返工。这篇文章是部署系列的第三篇先把控制节点和计算节点上的Ceilometer拆开讲明白再给出一套能落地的安装步骤和排障思路适合刚把Nova集群跑起来、准备补全遥测能力的开发者。1. 开工前先想清楚Ceilometer在整套OpenStack里管什么1.1 别把“监控”和“采集”混为一谈很多新手容易把Ceilometer当成“OpenStack版的zabbix”装上就以为能看到漂亮图表、收到告警通知。这个预期从一开始就偏了。Ceilometer的核心职责只有一个把计量数据采集上来。它不负责展现趋势图不负责判断阈值并报警这两件事分别由Gnocchi和Aodh或者你自建的监控平台去干。相当于Ceilometer是“采买员”Gnocchi是“仓库”Aodh是“保安”你要让采买员去干保安的活系统必然别扭。这套边界在OpenStack各服务划分里很清晰Nova管计算资源、Neutron管网络资源、Cinder管块存储资源而Ceilometer管的是这些资源在使用过程中产生的“度量事件”。比如虚拟机CPU累计多少秒、内存当前占用多大、网卡进出了多少字节、某时刻发生了虚拟机创建事件这些都是Ceilometer的采集对象。理解了这个定位你才会明白为什么它需要agent分散部署在各节点而不是只装一个中央服务就完事。1.2 四个角色组成的一条完整数据流典型的Ceilometer部署会拆成几个角色安装时别一股脑全塞在一个节点上先看它们各自干什么ceilometer-agent-compute跑在每个计算节点直接通过虚拟化层一般是libvirt抓取虚拟机CPU、内存、磁盘IO、网络流量等基础设施级指标。ceilometer-agent-central跑在控制节点负责采集不归属某个计算节点的资源指标例如镜像数量、卷指标、网络指标等。ceilometer-agent-notification也跑在控制节点它不主动轮询而是订阅消息队列里Nova、Neutron、Cinder等发出的notification事件把事件转成对应的计量数据结构。虚拟机创建、删除、快照、迁移这类生命周期变化主要靠它感知。ceilometer-api与collector等配套服务提供对外查询接口并把收到数据做后续分发。数据流可以用一句话概括agent采集或者订阅到数据后先经过管道pipeline做格式转换和加工再通过publisher发布到后端存储目前主流后端就是Gnocchi。Ceilometer本身变得越来越“薄”存储和分析能力都下沉到专用组件这其实是OpenStack社区刻意做的架构瘦身你在配置时不要把大量逻辑都堆在Ceilometer里。1.3 版本差异直接决定你怎么装我在网上搜过不少Ceilometer安装教程其中很大一部分是E版、H版时代的老文章动辄让你装MongoDB、在ceilometer.conf里写database连接串。那个时代的数据确实直接进数据库而且告警逻辑也内置于Ceilometer。但从Ocata以后社区已经明显转向“Ceilometer只做采集和发布、Gnocchi做时序存储、Aodh做告警”的新架构。到Queens、Train这一代你再按老教程改配置服务大概率起不来或者起来了也写不进数据。所以开装之前先确认三件事你的OpenStack版本是哪一代Gnocchi服务是否已经可用消息队列和认证服务Keystone是否稳定。下面的安装步骤以Queens及之后的手工部署方式为例包管理器以yum/dnf为主Ubuntu系包名略有差异但配置逻辑完全一致。如果你还停留在老版本把新配置往上一套多半会报缺配置项。2. 控制节点端安装api、notification、central一个都不能少2.1 在Keystone中注册账号和服务端点Ceilometer要正常工作第一步是在Keystone里有自己的合法身份。控制节点上先创建ceilometer用户并把它加入service项目并赋予admin角色openstack user create --domain default --password ceilometer ceilometer openstack role add --project service --user ceilometer admin然后注册服务。这里要注意服务类型Ceilometer注册时用的service type是metering虽然新版本里一些client工具显示为metric但创建服务时保持传统写法就行openstack service create --name ceilometer --description Telemetry 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为什么这步不能省因为后续agent们要用这个账号去Keystone换token所有服务之间的调用都靠这个身份做鉴权。如果endpoint里的hostname写错或者region不一致后面查询接口时经常报401或者404而且日志里不会直接告诉你“端点配置错了”只会显示认证失败。2.2 安装核心组件与生成基础配置控制节点上需要安装的包包括api、notification和central三部分collector按版本决定是独立包还是合入其他进程。以RDO系为例dnf install -y openstack-ceilometer-api openstack-ceilometer-notification openstack-ceilometer-central openstack-ceilometer-common python3-ceilometerclient装完后/etc/ceilometer目录下一般会有一个空的或者示例配置。先把示例文件复制成正式配置cp /etc/ceilometer/ceilometer.conf.sample /etc/ceilometer/ceilometer.conf接下来编辑配置文件。核心段落如下替换为你自己的RabbitMQ密码和Keystone密码[DEFAULT] transport_url rabbit://openstack:ceilometercontroller:5672 auth_strategy keystone [keystone_authtoken] www_authenticate_uri http://controller:5000 auth_url http://controller:5000 memcached_servers controller:11211 auth_type password project_domain_name default user_domain_name default project_name service username ceilometer password ceilometer [service_credentials] auth_url http://controller:5000 project_name service username ceilometer password ceilometer interface internalURL region_name RegionOne这里最容易踩坑的是keystone_authtoken和service_credentials两组配置的写法。keystone_authtoken是对外提供API时校验token用的service_credentials是Ceilometer自己主动调用Keystone、Gnocchi等接口时使用的身份。两组配置的用户名密码要一致都指向service项目下的ceilometer用户。如果分开填成两套账号初始可能看不出问题等到采集数据要写入Gnocchi时就会因为权限不足被拒。2.3 配置与Gnocchi对接新版Ceilometer默认把数据交给Gnocchi保管因此[dispatcher_gnocchi]段落必须配置。最简配置如下[dispatcher_gnocchi] filter_project service url http://controller:8041url指向Gnocchi服务的地址默认端口8041。这里的filter_project表示Ceilometer只处理service项目下的资源相关数据生产环境一般保持默认即可。还需要确认你的Gnocchi已经建好了相应的资源类型和archive policy否则数据过来也不知道该按什么策略归档。Ceilometer相关脚本ceilometer-upgrade会帮你创建默认资源类型但archive policy需要提前在Gnocchi侧准备常用的策略名比如“high”每1秒一个点存30天、“low”每5分钟一个点存365天具体看你的数据保留需求。有些文章会教你顺便把旧版database配置也写上说“留着兼容”。我的建议是不写。新版流程里Ceilometer根本不直接访问数据库写进去只会让配置膨胀排障时还多一个干扰项。如果后续采集数据没进Gnocchi优先查的是dispatcher配置而不是数据库连接串。2.4 启动服务并确认运行态配置文件改完后启动控制节点端几个服务systemctl enable --now openstack-ceilometer-api.service systemctl enable --now openstack-ceilometer-central.service systemctl enable --now openstack-ceilometer-notification.service然后盯一眼日志。Ceilometer的日志分散在/var/log/ceilometer/目录下有api.log、central.log、notification.log等。启动后立刻查看有没有ERROR级日志是个好习惯tail -f /var/log/ceilometer/central.log如果central正常起来说明RabbitMQ和Keystone连接没问题。如果卡在认证或者连接队列上多半是transport_url里密码错了或者rabbitmq账号权限不够。记住一个判断标准所有服务应该处于active(running)状态持续5分钟以上而不是起一下又退。我的经验是api服务即使配置有问题systemd也常常显示为active因为进程起来了但内部线程在反复重试所以一定要看日志确认。3. 计算节点端安装agent-compute才是采样主力3.1 为什么要把agent放到计算节点可能有人会问既然控制节点已经装了central为什么不能由central远程去每个宿主机采集理论上可以但生产环境没人这么做。第一SSH或者远程libvirt连接需要额外打通道安全策略复杂第二每台宿主机上有几十上百台虚拟机中央轮询的压力太大周期一长数据就不准。Ceilometer的设计思路是把采集动作尽量下沉到资源所在地计算节点上的agent本地通过libvirt的socket读取数据延迟极低宿主机数量再多也能水平扩展。这也是Ceilometer和很多传统监控系统最大的区别。传统监控是中央服务器主动去抓Ceilometer是每个节点主动往上报。所以你在规划部署时控制节点装上central、notification计算节点装上compute agent这种分布方式不是随意的是架构决定的。3.2 安装并配置agent-compute每台计算节点上执行dnf install -y openstack-ceilometer-compute python3-ceilometerclient然后同样生成配置文件。计算节点上的ceilometer.conf不需要api、collector那部分逻辑重点保证transport_url、keystone_authtoken、service_credentials三段正确即可配置内容与控制节点基本一致。但要注意region_name必须能解析到控制节点如果计算节点网络里controller主机名解析不通agent会一直报连接失败。启动agentsystemctl enable --now openstack-ceilometer-agent-compute.service计算节点上还有一个容易被忽略的前提必须存在/var/lib/libvirt/libvirt-sock这类本地socketCeilometer通过它访问虚拟化层。如果你用的是容器化的计算节点得确认socket挂载进了容器如果你是裸机部署确认libvirtd服务是运行状态。经常有人把compute agent装好日志里却全是“Failed to connect to hypervisor”检查一圈发现libvirtd根本没起来。3.3 pipeline.yaml的裁剪思路与格式陷阱计算节点上真正决定“采哪些数据、怎么加工”的是pipeline.yaml它位于/etc/ceilometer/。我的建议是不要用默认配置直接跑默认会开启大量meter很多指标你用不上白占队列和存储。先按业务需求裁剪后面再加。一个最小可用的pipeline例子sources: - name: compute_source interval: 300 meters: - cpu - cpu_util - memory.usage - disk.read.bytes - disk.write.bytes - network.incoming.bytes - network.outgoing.bytes sinks: - meter_sink sinks: - name: meter_sink transformers: - name: rate_of_change parameters: source: map_from: name: cpu map_to: name: cpu_util unit: % type: gauge publishers: - gnocchi://这里interval是采集周期单位秒。300秒一轮对大多数计量场景已经足够细。如果你做的是实时性要求很高的调度决策可以调到60秒但要注意Gnocchi存储压力和RabbitMQ队列堆积风险。pipeline.yaml最大的坑是YAML格式。Ceilometer对这个文件的缩进极其敏感一个Tab混进来就可能导致整个source识别不了而日志里往往只给一句很模糊的warning不会告诉你哪一行写错了。我的习惯是改完先做一次语法校验python3 -c import yaml,sys; yaml.safe_load(open(/etc/ceilometer/pipeline.yaml))没有任何输出就说明YAML结构合法然后再重启agent。如果结构不合法立刻会告诉你第几行有错省得启动后看半天“No meters defined”这种不知所云的日志。4. 各服务联动配置让Nova、Neutron把家底报上来4.1 Nova侧必须打开notification开关前面提到notification agent依赖的是Nova等组件主动发出的消息。如果Nova那边不发你装了notification agent也白搭。Nova的配置文件/etc/nova/nova.conf里需要确认以下几项[DEFAULT] instance_usage_audit True instance_usage_audit_period hour notify_on_state_change vm_state notification_topics notificationsinstance_usage_audit打开后Nova会周期性地对实例做用量审计并生成通知notify_on_state_change表示当实例状态变化时发通知。notification_topics定义发到消息队列的哪个topic默认是notificationsCeilometer的notification agent默认就订阅这个topic。改完Nova配置后必须重启nova服务例如nova-compute、nova-api、nova-conductor等。这里要特别提醒如果你集群里有多个计算节点每台计算节点上的nova.conf都要改只改控制节点没用因为实例跑在各自的compute上状态变更通知是从compute节点发出去的。4.2 从通知机制理解其他组件的联动方式理解了Nova怎么接进来其他组件就一通百通了。Neutron会在网络创建、端口绑定等事件时向消息队列发notificationCinder在卷创建、挂载、卸载时有notificationGlance在上传镜像、删除镜像时同样有notification。Ceilometer这边不需要逐个组件安装什么插件它只是作为消息队列的消费者把这些通知消费掉并按规则转成samples和events。实际部署时如果发现某些事件缺失先别怀疑Ceilometer而是顺着消息链路查对应组件有没有发出消息消息发到了哪个topicCeilometer订阅的topic是不是一致曾经遇到过一次镜像上传事件始终采不到的情况查到最后发现Glance所在节点配置的transport_url里RabbitMQ vhost和Ceilometer用的不是同一个消息确实发了但进了另一个vhost的死信队列。4.3 RabbitMQ与Keystone的权限死角联动配置里最不容易注意到的是RabbitMQ的权限。Ceilometer的transport_url里写了一个账号密码例如rabbit://openstack:ceilometercontroller:5672这个openstack账号需要在RabbitMQ里有读写权限。如果你是通过发行版脚本装的一般自动创建手工部署建议显式执行一次rabbitmqctl add_user openstack ceilometer rabbitmqctl set_permissions openstack .* .* .*另外在RabbitMQ中要确认能查看队列消息堆积情况。Ceilometer正常工作后消息队列里会出现类似notifications.info、metering.sample的队列。用下面命令查看消息数变化可以快速判断采集链路是否通畅rabbitmqctl list_queues name messages如果队列消息数持续增长不减少说明consumer消费能力跟不上或者consumer根本就没起来。如果某些队列一直为0说明消息没发过来问题在生产者侧也就是Nova、Neutron它们。5. 验证与排障实录5.1 怎么确认采集链路真的走通了装完别急着写结论先做一轮验证。第一步看服务运行状态控制节点和计算节点分别执行systemctl status openstack-ceilometer-api openstack-ceilometer-central openstack-ceilometer-notification systemctl status openstack-ceilometer-agent-compute第二步查认证是否能通过直接看Keystone里的服务列表openstack service list能看到ceilometer那一条就说明服务注册正常。第三步验证数据链路这个最关键。如果Gnocchi已经装了metric client直接查指标列表openstack metric list如果能看到一堆类似cpu、memory.usage的指标名说明采集到数据并且写入Gnocchi成功。如果列表是空的可以再用Ceilometer自带的client查一轮ceilometer sample-list -m cpu返回结果里有采样记录说明采集链路通。通过数据结果比对你能快速判断故障出在采集端还是存储端有sample但metric里没有问题大概率在dispatcher或Gnocchi连sample都没有问题在agent或pipeline。5.2 常见故障速查表下面这个表是我在实际部署和帮别人排查时整理出来的照着顺序查能省不少时间现象大概率原因排查办法服务起不来日志显示认证失败keystone_authtoken中密码错误或endpoint不一致确认ceilometer用户密码核对服务账号区域sample-list查不到数据pipeline中meter名称写错或agent没起检查pipeline.yaml语法重启agent看agent.logmetric列表空但sample有数据dispatcher_gnocchi配置错误或Gnocchi权限不足检查url、filter_project、Gnocchi里archive policy只有部分实例有数据某些计算节点agent没装或libvirtd未运行逐节点检查agent状态和/var/lib/libvirt/socketcpu_util指标永远为0rate_of_change的map配置错误或cpu采样周期未到核查pipeline transformers段缩进和meter名消息队列堆积严重周期太短或publisher配置不对拉长interval检查publisher是否指向gnocchi查询接口报404endpoint里URL写错或region不匹配用openstack endpoint list核对8777端口地址5.3 我踩过的两个具体坑第一次搭的时候我把pipeline.yaml里的缩进用Tab键补了一下启动后agent状态看着是正常的但日志里反复出现“No defined meters”那时我没太在意以为机器上确实采集不到数据。折腾了半天最后用yaml.safe_load一校验才发现是格式问题。从此以后我改任何yaml配置都先跑一遍语法校验再重启服务这个习惯帮我避免了很多“玄学”故障。另一个坑来自多计算节点环境。集群有3台计算节点我在第1台上配好了pipeline手工scp到第2、3台时不小心漏掉了一个meter名称。结果是三台节点上报的指标集合不一致Gnocchi那边有些指标时有时无查询图表时缺一段数据。排查到最后一条条对比三台机器的pipeline.yaml才发现差异。后来我把pipeline统一放到配置分发工具里管理再也不敢手工scp散装配置了。结尾从这套安装过程里我个人最深的体会是Ceilometer本身不难装难的是把采集边界、采样周期和存储策略想清楚。它不像Nova那样装完马上能建虚拟机效果不是立刻可见的但数据链路一旦打通后续接报表、接告警、接调度都会顺很多。建议你第一次部署时先按最小pipeline把CPU和内存两条链路走通确认Gnocchi里有数据了再逐步往pipeline里加磁盘、网络指标。别急着一次把全量meter都打开否则队列挤压、存储膨胀、查问题的时候无从下手。这个内容后续还可以继续扩展比如把Aodh接上来做阈值告警或者用Prometheus配合Ceilometer exporter做更灵活的监控展示但前提都是采集底座先稳了。