企业官网建设流程全解析

在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:ceilometer@controller: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:8041

url指向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会一直报连接失败。

启动agent：

systemctl enable --now openstack-ceilometer-agent-compute.service

计算节点上还有一个容易被忽略的前提：必须存在/var/lib/libvirt/libvirt-sock这类本地socket，Ceilometer通过它访问虚拟化层。如果你用的是容器化的计算节点，得确认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 = notifications

instance_usage_audit打开后，Nova会周期性地对实例做用量审计并生成通知；notify_on_state_change表示当实例状态变化时发通知。notification_topics定义发到消息队列的哪个topic，默认是notifications，Ceilometer的notification agent默认就订阅这个topic。

改完Nova配置后必须重启nova服务，例如nova-compute、nova-api、nova-conductor等。这里要特别提醒：如果你集群里有多个计算节点，每台计算节点上的nova.conf都要改，只改控制节点没用，因为实例跑在各自的compute上，状态变更通知是从compute节点发出去的。

4.2 从通知机制理解其他组件的联动方式

理解了Nova怎么接进来，其他组件就一通百通了。Neutron会在网络创建、端口绑定等事件时向消息队列发notification；Cinder在卷创建、挂载、卸载时有notification；Glance在上传镜像、删除镜像时同样有notification。Ceilometer这边不需要逐个组件安装什么插件，它只是作为消息队列的消费者，把这些通知消费掉并按规则转成samples和events。

实际部署时，如果发现某些事件缺失，先别怀疑Ceilometer，而是顺着消息链路查：对应组件有没有发出消息？消息发到了哪个topic？Ceilometer订阅的topic是不是一致？曾经遇到过一次镜像上传事件始终采不到的情况，查到最后发现Glance所在节点配置的transport_url里RabbitMQ vhost和Ceilometer用的不是同一个，消息确实发了，但进了另一个vhost的死信队列。

4.3 RabbitMQ与Keystone的权限死角

联动配置里最不容易注意到的是RabbitMQ的权限。Ceilometer的transport_url里写了一个账号密码，例如rabbit://openstack:ceilometer@controller: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 常见故障速查表

下面这个表是我在实际部署和帮别人排查时整理出来的，照着顺序查能省不少时间：

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做更灵活的监控展示，但前提都是采集底座先稳了。