RabbitMQ Quorum Queues Raft 监控指南：Grafana 仪表盘与 Prometheus 指标深度解析

后端消息队列消息路由【免费下载链接】rabbitmq-serverOpen source RabbitMQ: core server and tier 1 (built-in) plugins项目地址https://gitcode.com/gh_mirrors/ra/rabbitmq-server点击查看免费下载RabbitMQ 的 Quorum Queues仲裁队列基于 Raft 共识算法实现每个队列都由一个 Raft 组由集群中多个节点上的 Raft 成员组成承载。本文围绕仓库中 RabbitMQ-Quorum-Queues-Raft 仪表盘发布文档 展开结合 rabbitmq-prometheus 插件源码 与仓库内配套的 Docker 演示环境讲解如何通过 Grafana 仪表盘观测集群中所有 Quorum Queue Raft 成员的提交速率、提交延迟、未提交日志、选主频率与日志积压并掌握每个面板的 PromQL 查询与故障诊断思路。一、仪表盘定位一张图看懂 Quorum Queues 的 Raft 状态原文档对该仪表盘的定义非常明确Raft state for all Quorum Queues running in a RabbitMQ cluster —— 展示集群中所有 Quorum Queue 所运行 Raft 成员的状态。它解决的核心问题在于Quorum Queue 的每一个队列实例实际上都是一个 Raft 状态机数据以日志log形式追加写入、通过多数派quorum提交后才算成功。传统队列监控只能看到吞吐与积压而这张仪表盘把视角下沉到Raft 共识层帮助你回答几类关键问题集群当前整体的日志提交吞吐是多少发布、消费确认等所有队列操作都包含在内一条日志从写入到被提交需要多久Raft 开销的量化指标是否有日志已经写入但迟迟无法提交往往意味着成员失联、多数派不可用是否有频繁的 Leader 选举term 快速增长通常是网络抖动或节点不稳定信号哪些队列的 Raft 日志已经积压了超过 5000 条可能是大积压也可能是可用性问题。原文档明确说明该仪表盘面向 RabbitMQ 3.8.x 集群并依赖rabbitmq-prometheus插件——该插件自 RabbitMQ v3.8.0 起内置。从仓库中仪表盘 JSON 的定义RabbitMQ-Quorum-Queues-Raft.json可以看到面板查询同时保留了旧版指标名如rabbitmq_raft_log_commit_index与 RabbitMQ 4.2 的新指标名如rabbitmq_raft_commit_index因此新旧版本均可使用。二、五大核心面板指标含义、PromQL 与诊断解读仪表盘共包含 5 个面板全部由 RabbitMQ-Quorum-Queues-Raft.json 定义。每个面板的查询都通过on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node)与rabbitmq_identity_info做标签关联把指标归属到具体的 RabbitMQ 集群与节点并按rabbitmq_node分组。2.1 Log entries committed / s每秒提交的日志条目数这是一个 Time series 折线面板统计 Raft 日志提交速率。面板描述指出它包含所有队列操作包括发布与消费者确认它跟踪的是所有成员含 follower上 commit index 的推进速度。如果一个 RabbitMQ 节点没有运行任何 Raft 成员它不会上报任何已提交条目。主查询旧版指标名sum(rate(rabbitmq_raft_log_commit_index[$__rate_interval]) * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) by(rabbitmq_node)RabbitMQ 4.2 版本使用新指标名rabbitmq_raft_commit_index其余结构相同。该面板为每条节点序列设置了 80 的阈值红色告警线并内置了节点级颜色编码节点名末尾数字 0–9 分别对应固定颜色如rabbit…0为绿色#56A64B、rabbit…1为黄色#F2CC0C、rabbit…2为蓝色#3274D9等便于多节点对比。2.2 Log entry commit latency日志提交延迟这是一个 Heatmap 热力图面板度量一条日志从写入 Raft 日志到被提交所耗费的时间是Raft 操作开销的直接指示器。面板描述给出了两个关键论断随着负载增加系统会用延迟换取吞吐因此该值会随负载上升Quorum Queue 在提交前会对所有操作执行 fsync 落盘因此它们天然不适合低延迟负载场景。查询表达式rabbitmq_raft_commit_latency_seconds * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}热力图按秒unit: s绘制延迟分布配合 Y 轴直方图可观察提交延迟的整体分布形态与拖尾。2.3 Uncommitted log entries未提交日志条目数统计「已写入但尚未提交」的 Raft 日志数量即 last written index 与 commit index 的差值sum( (rabbitmq_raft_log_last_written_index * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) - (rabbitmq_raft_log_commit_index * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) ) by(rabbitmq_node)RabbitMQ 4.2 版本对应替换为rabbitmq_raft_last_written_index与rabbitmq_raft_commit_index。面板描述给出了明确的诊断结论高且持续增长的值可能表明无法凑齐多数派成员quorum of members not being available导致队列无法推进——这是排查 Quorum Queue「卡住不消费/不产出」类故障的第一指标。2.4 Leader elections / s每秒 Leader 选举次数跟踪 Raft term 的递增速率sum(rate(rabbitmq_raft_term[$__rate_interval]) * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) by(rabbitmq_node)面板描述指出持续非零的选举速率通常意味着网络问题或可用性问题或是队列频繁增减queue churn另一种可能原因是频繁的 Quorum Queue 声明每次声明新队列都会触发 Raft 组初始化大于 0 是正常的少量选举在预期之内持续高值才值得警惕。面板设置了 3 次/秒的橙色告警阈值thresholdsStyle: linearea方便快速识别异常区间。2.5 Raft members with 5k entries in the log日志条目超过 5000 的 Raft 成员统计自上次快照snapshot以来每个 Raft 日志中积累的条目数sum( (rabbitmq_raft_log_last_written_index * on(instance, job) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) - (rabbitmq_raft_log_snapshot_index * on(instance) group_left(rabbitmq_cluster, rabbitmq_node) rabbitmq_identity_info{rabbitmq_cluster$rabbitmq_cluster, namespace$namespace,rabbitmq_endpoint$endpoint}) ) by(queue, rabbitmq_node)RabbitMQ 4.2 版本对应替换为rabbitmq_raft_last_written_index与rabbitmq_raft_snapshot_index。面板按queue与rabbitmq_node分组图例格式为{{rabbitmq_node}} {{queue}}可精确定位到具体队列。面板描述给出了组合判读方法大值可能意味着较大的 Quorum Queue 积压backlog也可能是可用性问题如果 Uncommitted entries 指标同时也很大则系统存在真实的可用性问题日志既积压又无法提交说明多数派很可能不可用。面板以 5000 条为阈值做了颜色区分0–5000 绿色5000 以上橙色这与面板标题中的 5k 完全对应。三、指标源头Raft 指标采集器的源码实现仪表盘展示的所有rabbitmq_raft_*指标都来自 prometheus_rabbitmq_raft_metrics_collector.erl。理解它的实现有助于你判断指标的粒度与含义。3.1 指标前缀与三种采集模式Collector 定义了三个指标前缀前缀用途rabbitmq_raft_默认聚合aggregate模式与 per-object 模式下的指标名rabbitmq_detailed_raft_/metrics/detailed端点下的详细指标采集模式由collect_mf/2的注册表参数决定并在默认模式下读取应用环境变量return_per_object_metrics对应配置文件中的prometheus.return_per_object_metrics聚合模式默认return_per_object_metricsfalse输出collect_aggregate_metrics/2即「关键组件指标 max 聚合指标」不带 queue 标签指标总量可控per-object 模式return_per_object_metricstrue输出collect_per_object_metrics/2为每个 Quorum Queue 输出带queue、vhost等标签的指标面板中按 queue 分组的查询依赖这种粒度detailed 模式通过/metrics/detailed端点配合prometheus_vhost_filter、prometheus_queue_filter过滤指定 vhost 与队列输出rabbitmq_detailed_raft_前缀的全量指标。3.2 Quorum Queue 与协调系统的区分采集器通过两个过滤函数区分指标归属does_belong_to_quorum_queue/1匹配带queue标签的指标即 Quorum Queue 的 Raft 指标does_belong_to_coordination_system/1匹配ra_system coordination的指标即集群协调系统如 Khepri的 Raft 指标。Quorum Queue 部分只取固定指标集term、snapshot_index、last_applied、commit_index、last_written_index、commit_latency、num_segments——这正是仪表盘各面板所用指标commit index、commit latency、last written index、snapshot index、term的直接来源。同时采集器还通过seshat:format(ra, …)输出 Raft 写入前端的 WAL 指标wal_files、bytes_written、mem_tables与 Segment Writer 指标entries、segments。3.3 max 聚合指标在聚合模式下采集器会对 Quorum Queue 的num_segments与commit_latency两类指标跨队列求最大值输出rabbitmq_raft_max_num_segments、rabbitmq_raft_max_commit_latency标签固定为ra_systemquorum_queues源码注释中注明这里硬编码了 ra_system理想做法是max() GROUP BY ra_system。这类指标适合做跨集群的聚合告警。四、仪表盘的过滤与模板变量原文档指出该仪表盘支持按RabbitMQ Cluster过滤。在 RabbitMQ-Quorum-Queues-Raft.json 的templating部分可以看到完整的变量体系变量类型数据来源说明DS_PROMETHEUSdatasourcePrometheus数据源选择namespacequerylabel_values(rabbitmq_identity_info, namespace)Kubernetes 命名空间维度endpointquerylabel_values(rabbitmq_identity_info{…}, rabbitmq_endpoint)指标端点默认端点排除memory-breakdownrabbitmq_clusterquerylabel_values(rabbitmq_identity_info{namespace$namespace}, rabbitmq_cluster)即文档所述「RabbitMQ Cluster」过滤对应配置项cluster_name所有面板查询都会引用$rabbitmq_cluster、$namespace、$endpoint三个变量因此在一个 Prometheus 同时监控多个 RabbitMQ 集群时可以轻松切换视角。仪表盘默认刷新间隔 15srefresh: 15s默认时间范围now-15m均可在 Grafana 中调整。五、三步快速开始用仓库自带 Docker 环境复现原文档给出了「3 步本地跑通」的 Quick Start 指引。仓库的 docker 目录 提供了可直接运行的完整演示环境包含三节点 Quorum Queue 集群、Prometheus、Grafana 与压测工具步骤如下第 1 步启动三节点 RabbitMQ 集群与压测负载docker-compose-qq.yml 定义了rmq0-qq、rmq1-qq、rmq2-qq三个节点镜像pivotalrabbitmq/rabbitmq:master-otp-max端口映射如下节点管理端口指标端口rmq0-qq15679 → 1567215699 → 15692rmq1-qq15680 → 1567215700 → 15692rmq2-qq15681 → 1567215701 → 15692每个节点通过只读挂载注入三份配置rabbitmq-qq.conf主配置、rabbitmq-qq-env.conf环境变量、rabbitmq-qq-definitions.json队列定义。qq-moderate-load服务使用pivotalrabbitmq/perf-test产生中等负载创建qq1–qq10共 10 个x-queue-typequorum、x-max-length1000的队列10 个生产者 10 个消费者持久化消息、每队列限速 50 msg/s 并开启 publisher confirms。关键配置说明rabbitmq-qq.confloopback_users.guest false允许 guest 远程登录演示环境用vm_memory_high_watermark.absolute 1536MBRaft WAL 默认上限 512MB注释明确要求节点可用内存达到其约 3 倍cluster_name rabbitmq-qq与仪表盘的RabbitMQ Cluster过滤器对应cluster_formation.peer_discovery_backend rabbit_peer_discovery_classic_confignodes.1/2/3静态组建三节点集群collect_statistics_interval 10000把统计刷新间隔从默认 5s 提到 10s——注释解释了原因要低于 Prometheus 的抓取间隔15s又能在抓取前完成刷新同时这个值决定了rate()查询使用的区间prometheus.return_per_object_metrics true按需开启 per-object未注释默认关闭开启后才会输出按队列拆分的指标。rabbitmq-qq-env.conf 则通过-ra wal_max_size_bytes 536870912将 Ra WAL 上限显式设为 512MB。第 2 步启动 Prometheus 抓取指标prometheus.yml 中scrape_interval: 15srabbitmq-server抓取任务覆盖所有:15692指标端点包括rmq0-qq–rmq2-qq另有一个rabbitmq-server-detailed任务抓取/metrics/detailed端点并按family: [queue_coarse_metrics]过滤。抓取间隔与 rabbitmq-qq.conf 中collect_statistics_interval 10000的配合关系是理解rate()曲线平滑度的关键。第 3 步导入 Grafana 仪表盘仪表盘 JSON 位于 RabbitMQ-Quorum-Queues-Raft.jsonuid 为f1Mee9nZz需要 Prometheus 数据源DS_PROMETHEUS。仓库还提供了 Grafana provisioning 配置 dashboards.yml通过 file 类型 provider 指向/dashboards目录把 JSON 放入该目录即可实现自动加载Grafana 首次导入时会要求绑定 Prometheus 数据源随后即可选择RabbitMQ Cluster对应cluster_name rabbitmq-qq查看五大面板。六、生产环境诊断实践与注意事项结合原文档、面板描述与源码给出几条可直接落地的运维建议先看 Uncommitted log entries再看 5k entries。面板描述给出的组合判读是日志大量积压但能够持续提交说明是正常的大积压吞吐瓶颈积压与未提交同时走高则指向多数派成员不可用的真实可用性问题应优先检查集群节点连通性与磁盘状态。Leader elections 允许非零警惕持续高值。term 增长速率持续超过每秒数次并伴随提交吞吐下滑优先排查网络分区、节点重启与频繁的队列声明queue churn。fsync 决定了延迟下限。Quorum Queue 提交前强制落盘因此 commit latency 天然高于普通内存队列若该值异常升高结合 WAL 指标rabbitmq_raft_wal_files、rabbitmq_raft_bytes_written见 prometheus_rabbitmq_raft_metrics_collector.erl判断磁盘性能是否为瓶颈。正确设置统计刷新间隔与抓取间隔。参考 rabbitmq-qq.conf 的做法collect_statistics_interval10s应低于 Prometheusscrape_interval15s保证每次抓取拿到的是最新刷新后的指标rate()结果才平滑可信。按需开启 per-object 指标。默认聚合模式不带 queue 标签指标基数小、适合长期运行需要按队列定位如「5k entries」面板按 queue 分组时再设置prometheus.return_per_object_metrics true并注意随之增长的指标基数与存储开销。七、相关资源索引仪表盘发布文档rabbitmq-quorum-queues-raft-11340.md仪表盘定义PromQL 与面板配置RabbitMQ-Quorum-Queues-Raft.jsonRaft 指标采集器源码prometheus_rabbitmq_raft_metrics_collector.erl插件说明rabbitmq_prometheus/README.md演示环境编排docker-compose-qq.yml、rabbitmq-qq.conf、prometheus.yml、dashboards.yml同目录其他仪表盘文档rabbitmq-overview-10991.md、rabbitmq-stream-14798.md这张仪表盘把 Raft 共识层「黑盒」透明化提交速率反映吞吐、提交延迟反映开销、未提交条目与日志积压反映健康度、选举速率反映稳定性。将它与 RabbitMQ-Overview 等仪表盘配合使用即可对 Quorum Queue 集群形成从队列层到共识层的完整可观测闭环。赞分享后端消息队列消息路由【免费下载链接】rabbitmq-serverOpen source RabbitMQ: core server and tier 1 (built-in) plugins项目地址https://gitcode.com/gh_mirrors/ra/rabbitmq-server点击查看免费下载相关推荐Satellizer监控告警Prometheus指标与Grafana仪表盘Satellizer监控告警Prometheus指标与Grafana仪表盘 Satellizer作为Token based AngularJS Authent前端应用安全Apache Pulsar 监控指南Grafana 官方仪表盘与 Prometheus 指标解析Apache Pulsar 监控指南Grafana 官方仪表盘与 Prometheus 指标解析 导读 本指南基于 Apache Pulsar 仓库中 gra消息队列后端Astral网络加速5分钟打造稳定P2P连接的终极指南Astral网络加速5分钟打造稳定P2P连接的终极指南 你是否经常遇到远程办公时视频会议卡顿、游戏延迟过高、或文件传输缓慢的问题Astral是一款基于Eas创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考