RabbitMQ-Overview：用 Grafana 仪表盘替代 Management Overview 的集群监控实战指南-平芜编程栈

后端
消息队列
消息路由

【免费下载链接】rabbitmq-server

Open source RabbitMQ: core server and tier 1 (built-in) plugins

项目地址：https://gitcode.com/gh_mirrors/ra/rabbitmq-server

RabbitMQ-Overview 是一份随rabbitmq_prometheus插件一起发布的 Grafana 仪表盘，目标是成为 RabbitMQ Management UI 中 Overview 页面的可替代方案：它把 Management 概览页展示的指标几乎全部搬进 Prometheus 生态，并以"按节点"的粒度呈现，让集群热点一目了然。读完本文，你将掌握该仪表盘覆盖的全部指标分类、其背后的 PromQL 查询模式、本地一键拉起 Prometheus + Grafana + 负载模拟的复现方法，以及如何把它导入自己的监控栈。

仪表盘是什么：Management Overview 的指标化替代

原文定位（见 rabbitmq-overview-10991.md）："An alternative to RabbitMQ Management Overview"、"Understand the state of any RabbitMQ cluster at a glance. Includes all metrics displayed on RabbitMQ Management Overview page."

它不是一个全新监控体系，而是把 RabbitMQ Management 插件Overview页面上已有的指标，以 Prometheus 时间序列的形式重新组织成 Grafana 仪表盘。其核心设计目标有三点：

一站式集群体检：所有 Management Overview 页面上的指标都能在此找到，并附带每个指标的说明及指向官方文档/指南的链接；
按节点聚合、暴露集群不均衡：所有指标都是节点粒度的（node-specific），因此可以直观地发现"热点"（cluster hotspots）——例如某个节点的文件描述符或内存余量明显低于其他节点；
内置合理阈值：部分图表面板带有默认阈值（threshold），资源余量一触线就会变色告警。

仪表盘 JSON 的description字段也印证了这一设计意图："A new RabbitMQ Management Overview"，仓库中对应的清单文件位于 RabbitMQ-Overview.json。

一个关键的实现前提

仪表盘描述中明确要求："Requiresrabbitmq-prometheusto be enabled, a built-in plugin since RabbitMQ v3.8.0"。也就是说，该仪表盘的数据全部来自rabbitmq_prometheus插件暴露的/metrics端点，而不是 Management 插件的 HTTP API。这也解释了为什么它可以作为 Management Overview 的替代——监控链路从"Management 插件统计"迁移到了"Prometheus 拉取"。

快速开始：三步搭起本地监控栈

仪表盘描述中给出的官方路线是 RabbitMQ 官方文档的 "Quick Start"（3 步在本机跑通 Prometheus + Grafana + RabbitMQ）。在仓库内，这套流程已经被封装成 Docker Compose 编排，一键即可复现：

第一步：启用 Prometheus 插件

rabbitmq_prometheus是内置插件，需要先启用（依据 README.md）：

rabbitmq-plugins enable rabbitmq_prometheus

插件默认监听端口15692，默认抓取路径/metrics，绝大多数环境无需额外配置。快速验证：

curl -v -H "Accept:text/plain" "http://localhost:15692/metrics"

抓取到的指标名统一以rabbitmq_前缀开头（如rabbitmq_global_messages_received_total），完整清单见 metrics.md。

第二步：让 Prometheus 发现 RabbitMQ 节点

仓库自带的 prometheus.yml 展示了标准抓取配置。其中与 RabbitMQ 相关的 job 有两个：

global: scrape_interval: 15s # 高于 collect_statistics_interval，保证抓到的指标是"新鲜"的 scrape_configs: - job_name: 'rabbitmq-server' static_configs: - targets: - 'rmq0:15692' - 'rmq1:15692' - 'rmq2:15692'

配置注释里有一个容易被忽略的联动点：scrape_interval: 15s的取值与 RabbitMQ 侧的collect_statistics_interval（默认 5s）相关，该参数决定统计刷新频率，也会影响仪表盘中rate()函数使用的区间范围。

第三步：导入仪表盘并登录查看

仪表盘 JSON 位于 RabbitMQ-Overview.json，在 Grafana 中通过Dashboards → Import导入即可；该 JSON 使用变量DS_PROMETHEUS引用 Prometheus 数据源，导入时将其绑定到你的 Prometheus 实例。

如果使用仓库的 Compose 编排（docker-compose-overview.yml），一条命令即可获得完整环境：

# 在 deps/rabbitmq_prometheus 目录下 make overview metrics # 拉起 Prometheus + Grafana + 3 节点 RabbitMQ 集群 + 负载发生器 # 浏览器访问 http://localhost:3000，默认账号 admin / admin # 拆除环境用 make down

该编排会启动rmq0/rmq1/rmq2三个 RabbitMQ 节点（镜像rabbitmq:4-management，端口15673~15675映射 Management，15693~15695映射 Prometheus 抓取端口），并挂载 rabbitmq-overview.conf 与rabbitmq-overview-definitions.json；同时启动一批perf-test容器模拟各类真实流量（basic.get 轮询、贪吃消费者、publisher confirms、慢消费者持久化、nack、不可路由消息返回/丢弃、stream 流量等），让仪表盘图表"活"起来，便于观察非零指标。

仪表盘覆盖的指标全景

依据仪表盘描述，其指标覆盖范围可划分为 6 大类。下面逐一说明，并给出对应的 Prometheus 指标与查询依据（指标名以 metrics.md 为准）。

1. 节点身份与版本

展示 RabbitMQ 与 Erlang/OTP 版本、节点与集群身份。对应指标：

rabbitmq_build_info：RabbitMQ 与 Erlang/OTP 版本信息；
rabbitmq_identity_info：RabbitMQ 节点与集群身份信息（标签rabbitmq_cluster、rabbitmq_node）；
rabbitmq_erlang_uptime_seconds：节点运行时长。

仪表盘 "NODES" 区域正是用这些指标渲染出"每节点一行"的表格（含rabbitmq_version、erlang_version标签），并在此区域实现按集群过滤。

2. 资源余量（阻断发布前的可用容量）

对应 Management Overview 上"内存/磁盘/文件描述符可用量"的展示，是判断是否触发 alarm（publisher 被阻断）的关键：

内存：rabbitmq_resident_memory_limit_bytes（内存高水位，bytes）与rabbitmq_process_resident_memory_bytes（当前占用）；
磁盘：rabbitmq_disk_space_available_limit_bytes（磁盘低水位）与rabbitmq_disk_space_available_bytes；
文件描述符：rabbitmq_process_max_fds与rabbitmq_process_open_fds。

面板标题为 "Memory available before publishers blocked"、"Disk space available before publishers blocked"、"File descriptors available"。从 JSON 面板表达式看，其计算方式为"总量 − 已用量"，例如：

(rabbitmq_process_max_fds - rabbitmq_process_open_fds) * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster="$cluster"}

这类面板带有默认阈值：余量跌破阈值时颜色由绿转红，直观提示资源即将触发 alarm。仓库的 rabbitmq-overview.conf 将vm_memory_high_watermark.absolute设为768MiB，并把ulimits.nofile压到 2000，正是为了在演示环境里模拟出"逼近阈值"的视觉效果。

3. 队列深度（排队消息）

待投递消息：rabbitmq_queue_messages_ready（对应面板 "Messages ready to be delivered to consumers"）；
待确认消息：rabbitmq_queue_messages_unacked（对应 "Messages pending consumer acknowledgement"）。

注意 dashboard 顶部的 Stat 面板使用sum(...)聚合全集群，而中部的明细图按节点拆分展示（group_left(rabbitmq_cluster, rabbitmq_node)），以便定位消息积压在哪个节点。

4. 入站消息速率

仪表盘描述的 "Incoming message rates" 全部落在这组全局计数器上（见 metrics.md 的 Global Counters 一节）：

面板	指标	说明
Messages published / s	`rabbitmq_global_messages_received_total`	从发布者收到的消息总数
Messages routed to queues / s	`rabbitmq_global_messages_routed_total`	路由到队列或流的消息总数
Messages confirmed to publishers / s	`rabbitmq_global_messages_confirmed_total`	向发布者确认的消息总数
Messages unconfirmed to publishers / s	`rabbitmq_global_messages_received_confirm_total`	期望确认的发布者发来的消息数
Unroutable messages dropped & returned / s	`rabbitmq_global_messages_unroutable_dropped_total`/`rabbitmq_global_messages_unroutable_returned_total`	不可路由被丢弃 / 被退回发布者

为什么用rabbitmq_global_*？metrics.md 中有一段重要的背景说明：在默认的聚合（aggregated）模式下，连接/通道一旦关闭其指标就会被垃圾回收，导致rate()/irate()计算出的速率出现虚假尖峰（例如每秒 400 万条消息）；Global counters 正是为修复这一缺陷而引入，并为按协议、按队列类型拆分的指标提供了基础。

5. 出站消息速率

Messages delivered / s：rabbitmq_global_messages_delivered_total；
Messages delivered with manual ack / s：rabbitmq_global_messages_delivered_consume_manual_ack_total；
Messages delivered auto ack / s：rabbitmq_global_messages_delivered_consume_auto_ack_total；
Messages acknowledged / s：rabbitmq_global_messages_acknowledged_total；
Messages redelivered / s：rabbitmq_global_messages_redelivered_total。

面板对速率统一采用rate(metric[$__rate_interval])，并乘上rabbitmq_identity_info以保留rabbitmq_cluster/rabbitmq_node标签用于过滤与按节点拆分。

6. 轮询操作（basic.get）

Polling operations with auto ack / s：rabbitmq_global_messages_delivered_get_auto_ack_total；
Polling operations with manual ack / s：rabbitmq_global_messages_delivered_get_manual_ack_total；
Polling operations that yield no result / s：rabbitmq_global_messages_get_empty_total（basic.get 空轮询次数）。

7. 队列、通道、连接及其变更速率

仪表盘底部分别用 "QUEUES"、"CHANNELS"、"CONNECTIONS" 三个区域展示存量与变更速率：

区域	存量指标	变更速率指标
QUEUES	`rabbitmq_queues`	`rabbitmq_queues_declared_total`、`rabbitmq_queues_created_total`、`rabbitmq_queues_deleted_total`
CHANNELS	`rabbitmq_channels`	`rabbitmq_channels_opened_total`、`rabbitmq_channels_closed_total`
CONNECTIONS	`rabbitmq_connections`	`rabbitmq_connections_opened_total`、`rabbitmq_connections_closed_total`

此外还有 "Publishers"（rabbitmq_global_publishers）与 "Consumers"（rabbitmq_global_consumers）两个实时计数 Stat 面板。

仪表盘背后的 PromQL 模式

从 RabbitMQ-Overview.json 的表达式可以看出三条可复用的查询范式，这也是你在自建监控时值得照搬的写法：

1. 集群聚合 + 集群标签注入

顶部 Stat 面板把全集群各节点求和，并通过group_left把rabbitmq_identity_info里的集群名标签带进来，从而支持顶部下拉框按集群过滤：

sum(rabbitmq_queue_messages_ready * on(instance, job) group_left(rabbitmq_cluster) rabbitmq_identity_info{rabbitmq_cluster="$cluster"})

2. 按节点拆分，暴露热点

中部区域把同样的聚合改成按rabbitmq_node保留维度（group_left(rabbitmq_cluster, rabbitmq_node)），使每个节点各占一条序列——这正是"所有指标都是节点级、便于发现集群不均衡"这一设计目标的具体实现。

3. 速率函数与 $__rate_interval

所有"每秒"面板统一使用rate(...,[$__rate_interval])（Stat 面板用irate突出瞬时抖动）。$__rate_interval是 Grafana 自动适配抓取间隔的区间变量，比硬编码[5m]更能避免 rate 区间与 scrape_interval 不匹配造成的误差。

数据链路与源码佐证

这套监控的数据链路为：

RabbitMQ 节点（统计收集） ↓ telemetry 事件 rabbitmq_prometheus 插件的 collectors ↓ /metrics（默认 :15692） Prometheus 抓取 ↓ PromQL RabbitMQ-Overview Grafana 仪表盘

在源码层面可以找到对应的实现证据：

核心指标收集器位于 collectors/：prometheus_rabbitmq_core_metrics_collector.erl（核心指标）、prometheus_rabbitmq_global_metrics_collector.erl（全局计数器）、prometheus_rabbitmq_dynamic_collector.erl（连接/通道/队列等动态对象指标）、prometheus_rabbitmq_alarm_metrics_collector.erl（alarm 相关）；
HTTP 抓取端点由 rabbit_prometheus_dispatcher.erl 与 rabbit_prometheus_handler.erl 实现，监听配置项为prometheus.tcp.port（默认 15692）与prometheus.path（默认/metrics）；
仪表盘描述中"包含 Management Overview 页面上的所有指标"可以在 metrics.md 得到印证——该文件系统整理了rabbitmq_connection_*、rabbitmq_channel_*、rabbitmq_queue_*、rabbitmq_global_*等全套指标及语义说明，正是 Management Overview 各图表背后的数据源。

配置要点与进阶提示

抓取与统计间隔的联动

prometheus.yml 注释明确：scrape_interval: 15s高于 RabbitMQ 的collect_statistics_interval（默认 5s），但又要保证在 Prometheus 抓取时统计已刷新；该值同时决定了rate()的可用区间。rabbitmq-overview.conf 把collect_statistics_interval调成10000（10s），用于演示"低于 Prometheus 抓取间隔"的边界配置。生产环境应根据自身抓取频率调整这两个参数，避免速率计算失真。

指标聚合与按对象返回

默认/metrics返回的是聚合后的指标；如需逐个对象（per-object）的原始序列，可抓取/metrics/per-object，或用rabbitmqctl eval动态切换：

# 临时开启 per-object（无需重启） rabbitmqctl eval 'application:set_env(rabbitmq_prometheus, return_per_object_metrics, true).' # 恢复聚合 rabbitmqctl eval 'application:set_env(rabbitmq_prometheus, return_per_object_metrics, false).'

注意：per-object 模式开销很大（README 记载 8 万队列的节点返回约 190 万条指标、耗时约 58 秒、响应约 98MB），默认聚合正是为了不给指标系统带来不必要的压力。仪表盘基于聚合指标设计，日常监控无需开启。

三个内置抓取端点小结

/metrics：默认聚合指标，仪表盘数据源；
/metrics/per-object：全量逐对象指标，开销大，仅调试用；
/metrics/detailed：按family/vhost参数选择性返回逐对象指标（指标前缀为rabbitmq_detailed_），prometheus.yml 中rabbitmq-server-detailedjob 即为示例，如family=queue_coarse_metrics。

结语

RabbitMQ-Overview 的价值在于：把过去只能在 Management UI Overview 页面人工查看的集群状态，变成了可归档、可告警、可回溯的时序数据，同时保留了"按节点"的诊断视角。结合本仓库中的 RabbitMQ-Overview.json、docker-compose-overview.yml 与 metrics.md，你既可以在几分钟内复现一套完整的演示环境，也可以把其中的 PromQL 模式直接移植到自己的监控体系中。