ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

RabbitMQ-Overview:用 Grafana 仪表盘替代 Management Overview 的集群监控实战指南

RabbitMQ-Overview:用 Grafana 仪表盘替代 Management Overview 的集群监控实战指南 后端消息队列消息路由【免费下载链接】rabbitmq-serverOpen 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.mdAn 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 Start3 步在本机跑通 Prometheus Grafana RabbitMQ。在仓库内这套流程已经被封装成 Docker Compose 编排一键即可复现第一步启用 Prometheus 插件rabbitmq_prometheus是内置插件需要先启用依据 README.mdrabbitmq-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映射 Management15693~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_infoRabbitMQ 与 Erlang/OTP 版本信息rabbitmq_identity_infoRabbitMQ 节点与集群身份信息标签rabbitmq_cluster、rabbitmq_noderabbitmq_erlang_uptime_seconds节点运行时长。仪表盘 NODES 区域正是用这些指标渲染出每节点一行的表格含rabbitmq_version、erlang_version标签并在此区域实现按集群过滤。2. 资源余量阻断发布前的可用容量对应 Management Overview 上内存/磁盘/文件描述符可用量的展示是判断是否触发 alarmpublisher 被阻断的关键内存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 / srabbitmq_global_messages_received_total从发布者收到的消息总数Messages routed to queues / srabbitmq_global_messages_routed_total路由到队列或流的消息总数Messages confirmed to publishers / srabbitmq_global_messages_confirmed_total向发布者确认的消息总数Messages unconfirmed to publishers / srabbitmq_global_messages_received_confirm_total期望确认的发布者发来的消息数Unroutable messages dropped returned / srabbitmq_global_messages_unroutable_dropped_total/rabbitmq_global_messages_unroutable_returned_total不可路由被丢弃 / 被退回发布者为什么用rabbitmq_global_*metrics.md 中有一段重要的背景说明在默认的聚合aggregated模式下连接/通道一旦关闭其指标就会被垃圾回收导致rate()/irate()计算出的速率出现虚假尖峰例如每秒 400 万条消息Global counters 正是为修复这一缺陷而引入并为按协议、按队列类型拆分的指标提供了基础。5. 出站消息速率Messages delivered / srabbitmq_global_messages_delivered_totalMessages delivered with manual ack / srabbitmq_global_messages_delivered_consume_manual_ack_totalMessages delivered auto ack / srabbitmq_global_messages_delivered_consume_auto_ack_totalMessages acknowledged / srabbitmq_global_messages_acknowledged_totalMessages redelivered / srabbitmq_global_messages_redelivered_total。面板对速率统一采用rate(metric[$__rate_interval])并乘上rabbitmq_identity_info以保留rabbitmq_cluster/rabbitmq_node标签用于过滤与按节点拆分。6. 轮询操作basic.getPolling operations with auto ack / srabbitmq_global_messages_delivered_get_auto_ack_totalPolling operations with manual ack / srabbitmq_global_messages_delivered_get_manual_ack_totalPolling operations that yield no result / srabbitmq_global_messages_get_empty_totalbasic.get 空轮询次数。7. 队列、通道、连接及其变更速率仪表盘底部分别用 QUEUES、CHANNELS、CONNECTIONS 三个区域展示存量与变更速率区域存量指标变更速率指标QUEUESrabbitmq_queuesrabbitmq_queues_declared_total、rabbitmq_queues_created_total、rabbitmq_queues_deleted_totalCHANNELSrabbitmq_channelsrabbitmq_channels_opened_total、rabbitmq_channels_closed_totalCONNECTIONSrabbitmq_connectionsrabbitmq_connections_opened_total、rabbitmq_connections_closed_total此外还有 Publishersrabbitmq_global_publishers与 Consumersrabbitmq_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.erlalarm 相关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调成1000010s用于演示低于 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 即为示例如familyqueue_coarse_metrics。结语RabbitMQ-Overview 的价值在于把过去只能在 Management UI Overview 页面人工查看的集群状态变成了可归档、可告警、可回溯的时序数据同时保留了按节点的诊断视角。结合本仓库中的 RabbitMQ-Overview.json、docker-compose-overview.yml 与 metrics.md你既可以在几分钟内复现一套完整的演示环境也可以把其中的 PromQL 模式直接移植到自己的监控体系中。赞分享后端消息队列消息路由【免费下载链接】rabbitmq-serverOpen source RabbitMQ: core server and tier 1 (built-in) plugins项目地址https://gitcode.com/gh_mirrors/ra/rabbitmq-server点击查看免费下载相关推荐从0到1kubeasz集群Grafana监控仪表盘实战配置指南从0到1kubeasz集群Grafana监控仪表盘实战配置指南 你是否还在为Kubernetes集群监控数据分散、关键指标难以追踪而困扰本文将带你通过kub云原生集群管理运维Grafana监控仪表盘创建实战指南Grafana监控仪表盘创建实战指南 请基于devops exercises项目撰写一篇关于Grafana监控仪表盘创建的专业文章。要求如下 文章结构要求文档教程DevOps运维Rook Ceph Grafana 仪表盘完全指南集群、OSD 与存储池监控实战Rook Ceph Grafana 仪表盘完全指南集群、OSD 与存储池监控实战 Rook 官方仓库在 deploy/examples/monitoring/云原生存储容器编排运维创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表