RabbitMQ监控怎么做？Prometheus+Grafana监控RabbitMQ教程-linux运维-PHP中文网

最轻量稳定的rabbitmq监控方案是启用rabbitmq_prometheus插件（≥3.8+erlnag≥23.2），prometheus抓取/metrics/per-object路径，grafana展示；需验证插件启用、端口开放、认证配置、label一致性及告警逻辑。

rabbitmq监控怎么做？prometheus+grafana监控rabbitmq教程

直接用 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 对 vhost label 做 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 名就得同步改，否则就是静默失效。