最轻量稳定的RabbitMQ监控方案是启用rabbitmq_prometheus插件（≥3.8+Erlnag≥23.2），Prometheus抓取/metrics/per-object路径，Grafana展示；需验证插件启用、端口开放、认证配置、label一致性及告警逻辑。
直接用 RabbitMQ 自带的 rabbitmq_prometheus 插件 + Prometheus 抓取 + Grafana 展示，是当前最轻量、最稳定、也最贴近官方支持的方案。不用额外部署 Exporter，不引入单点故障，指标全、延迟低、权限收敛——前提是 RabbitMQ ≥3.8 且 Erlang ≥23.2。
确认 rabbitmq_prometheus 插件已启用并暴露端口
这是整个链路的起点。很多问题不是配置错，而是插件根本没跑起来。
- 执行
rabbitmq-plugins list，确认输出里有[E*] rabbitmq_prometheus（E*表示已启用）；如果没有，运行rabbitmq-plugins enable rabbitmq_prometheus - 默认监听在
15692端口，用curl -s http://localhost:15692/metrics | head -n 5能看到类似# HELP rabbitmq_queue_messages_ready Number of messages ready to be delivered的指标文本才算成功 - 如果返回连接拒绝或超时：检查防火墙（
firewall-cmd --permanent --add-port=15692/tcp）、SELinux（setsebool -P prometheus_can_network_connect 1），以及 RabbitMQ 是否以非 root 用户启动但绑定了特权端口（改prometheus.tcp.port = 15692到非特权端口如95692更稳妥）
Prometheus 配置 job_name 时必须用 /metrics/per-object
只写 /metrics 会漏掉绝大多数关键指标——比如单个队列的 rabbitmq_queue_messages_ready、消费者数量、通道状态等，全在 /metrics/per-object 下。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 在
prometheus.yml的scrape_configs中添加如下片段：
job_name: 'rabbitmq'
scrape_interval: 30s
metrics_path: '/metrics/per-object'
static_configs:
- targets: ['192.168.1.100:15692', '192.168.1.101:15692']
labels:
cluster: 'prod-rmq'-
/metrics/per-object是关键。它会让插件为每个 queue、exchange、channel、connection 单独生成指标（例如rabbitmq_queue_messages_ready{queue="order.created",vhost="/"} 124），否则你只能看到节点级聚合值，无法定位具体哪个队列堵了 - 如果目标多于 1 个节点，建议加
relabel_configs去重或打标，避免同名 queue 在不同节点上冲突（比如都叫default） - Prometheus 抓取失败时，看日志里是否出现
server returned HTTP status 401 Unauthorized：说明 RabbitMQ 启用了管理插件认证，需在static_configs下加basic_auth配置
Grafana 导入 Dashboard 前先验证指标是否存在
别急着导入 ID 为 10991 或 12027 的 RabbitMQ 官方仪表盘——如果 Prometheus 根本没采到 rabbitmq_queue_.* 类指标，面板只会显示 “No data”。
- 进 Grafana → Explore → 选择 Prometheus 数据源 → 输入查询：
count by (queue) (rabbitmq_queue_messages_ready{queue!=""})，能列出所有队列名说明数据通了 - 常见空数据原因：RabbitMQ vhost 名含特殊字符（如
/、.），导致 Prometheus label 解析失败；此时需在 Prometheus 配置中加metric_relabel_configs对vhostlabel 做 replace 替换（例如把/换成_slash_） - 导入 Dashboard 后，检查变量（Variables）里的
$queue、$vhost是否能下拉出真实值；不能的话，说明label_values(rabbitmq_queue_messages_ready, queue)查询无结果，得回上一步排查采集链路
告警规则要避开“平均值陷阱”
直接对 rate(rabbitmq_queue_messages_unacknowledged[5m]) 取平均，可能掩盖单个慢消费者拖垮整个队列的问题。
- 真正有用的告警是：“某个队列未确认消息持续超过 1000 条，且最近 5 分钟消费速率低于生产速率” —— 这需要两个 PromQL 组合：
absent(rate(rabbitmq_queue_messages_published_total{queue=~".+"}[5m])) == 0 and
(rabbitmq_queue_messages_unacknowledged{queue=~".+"} > 1000) and
(rate(rabbitmq_queue_messages_published_total[5m]) - rate(rabbitmq_queue_messages_delivered_total[5m]) > 10)- 注意：
rabbitmq_queue_messages_delivered_total是消费者主动basic.get或推送给消费者的总量，而rabbitmq_queue_messages_consumed_total是成功 ack 的量，告警应基于前者判断“是否在消费”，而非后者判断“是否消费成功” - 所有告警规则里涉及的指标，必须在 Prometheus 的 Targets 页面里明确显示为 UP 状态，且 Last Scrape 时间距现在不超过
scrape_interval * 2，否则规则永远不触发
最容易被忽略的是指标命名空间和 label 的一致性：RabbitMQ 插件默认用 vhost、queue、node 作 label，但如果你在 Prometheus 里做了 relabel 重命名，Grafana 查询和告警规则里的 label 名就得同步改，否则就是静默失效。
