使用 Prometheus 和 Grafana 进行监控
概述
本指南涵盖了使用两款流行工具对 RabbitMQ 进行监控的方法：监控工具包 Prometheus；以及指标可视化系统 Grafana。
这些工具共同构成了用于 RabbitMQ 集群长期指标收集和监控的强大工具包。虽然 RabbitMQ 管理 UI 也提供对部分指标的访问，但它在设计上并非旨在成为长期指标收集解决方案。
请首先阅读主要的监控指南。当使用 Prometheus 和 Grafana 时，监控原则和可用指标大都与之相关。
本指南涵盖的一些关键主题包括：
- Prometheus 支持基础
- Grafana 支持基础
- 快速入门，用于本地实验
- 生产系统的安装步骤
- 两种类型的抓取端点响应：聚合指标与单个实体指标
Grafana 仪表盘遵循一系列约定，以使系统更具可观测性，并更容易发现反模式。其设计决策在多个章节中进行了说明
内置 Prometheus 支持
RabbitMQ 附带内置的 Prometheus 和 Grafana 支持。
Prometheus 指标收集器支持包含在 rabbitmq_prometheus 插件中。该插件以 Prometheus 文本格式在专用 TCP 端口上公开所有 RabbitMQ 指标。
这些指标为 RabbitMQ 节点和运行时的状态提供了深入的见解。它们使对 RabbitMQ、使用它的应用程序以及各种基础设施元素行为的推断更加明智。
Grafana 支持
收集到的指标如果不进行可视化，用处不大。RabbitMQ 团队提供了一套预构建的 Grafana 仪表盘，以特定于上下文的方式可视化大量可用的 RabbitMQ 和运行时指标。
有多个仪表盘可用：
以及其他。每个仪表盘都旨在提供对系统特定部分的见解。当一起使用时，它们能够详细解释 RabbitMQ 和应用程序的行为。
请注意，Grafana 仪表盘具有主观性并使用了一系列约定，例如，为了更快地发现系统健康问题或使跨图表引用成为可能。像所有 Grafana 仪表盘一样，它们也是高度可定制的。它们所采用的约定被认为是最佳实践，因此受到推荐。
示例
当 RabbitMQ 与 Prometheus 和 Grafana 集成时，RabbitMQ 概览仪表盘看起来是这样的
快速入门
开始之前
本节说明如何设置一个带有 Prometheus 和 Grafana 仪表盘的 RabbitMQ 集群，以及一些将产生一定活动和有意义指标的应用程序。
通过此设置，您将能够与本地运行的 RabbitMQ、Prometheus 和 Grafana 进行交互。您还将能够尝试不同的负载配置文件，以了解它们是如何结合在一起的，并理解仪表盘、面板等。
这仅仅是一个示例；rabbitmq_prometheus 插件和我们的 Grafana 仪表盘并不要求必须使用下面演示的 Docker Compose。
先决条件
以下说明假定主机已安装了特定的工具集：
- 运行命令的终端
- Git 用于克隆仓库
- Docker Desktop 用于在本地使用 Docker Compose
- 用于浏览仪表盘的 Web 浏览器
它们的安装超出了本指南的范围。请使用
git version
docker-compose CLI 已弃用，请改用
docker compose
docker info && docker compose version
在命令行上验证是否具备必要的工具。
克隆包含清单的仓库
第一步是克隆一个 Git 仓库 rabbitmq-server，其中包含运行 RabbitMQ 集群、Prometheus 和一组应用程序所需的清单和其他组件。
git clone https://github.com/rabbitmq/rabbitmq-server.git
cd rabbitmq-server/deps/rabbitmq_prometheus/docker
运行 Docker Compose
接下来，使用 Docker Compose 清单运行预配置的 RabbitMQ 集群、Prometheus 实例以及一个将产生 RabbitMQ 概览仪表盘中显示指标的基本工作负载。
docker compose -f docker-compose-metrics.yml up -d
docker compose -f docker-compose-overview.yml up -d
上面的 docker compose 命令也可以通过 make 目标执行。
make metrics overview
当上述命令成功运行后，将在一组容器中运行一个功能正常的 RabbitMQ 集群和一个从其收集指标的 Prometheus 实例。
访问 RabbitMQ 概览 Grafana 仪表盘
现在在 Web 浏览器中导航到 https://:3000/dashboards。它将打开登录页面。用户名和密码均使用 admin。首次登录时，Grafana 会建议更改密码。为了本示例的目的，我们建议跳过此步骤。
导航到 RabbitMQ-Overview 仪表盘，它看起来像这样：
恭喜！您现在拥有了一个在本地运行的、与 Prometheus 和 Grafana 集成的 3 节点 RabbitMQ 集群。现在是学习有关可用仪表盘更多信息的最佳时机。
RabbitMQ 概览仪表盘
管理 UI 概览页面中提供的所有指标均可在概览 Grafana 仪表盘中使用。它们按对象类型分组，重点关注 RabbitMQ 节点和消息速率。
健康指标
仪表盘顶部的单值指标 (Single stat metrics) 捕获了单个 RabbitMQ 集群的健康状况。在此示例中，只有一个 RabbitMQ 集群，即 rabbitmq-overview，正如仪表盘标题下方的 Cluster 下拉菜单中所示。
所有 RabbitMQ Grafana 仪表盘上的面板使用不同的颜色来捕获以下指标状态：
- 绿色 表示指标的值在健康范围内。
- 蓝色 表示利用率不足或某种形式的性能下降。
- 红色 表示指标的值低于或高于被认为是健康的范围。
单值指标 的默认范围对所有 RabbitMQ 部署来说并非最优。例如，在具有许多消费者和/或高预取值的环境中，拥有超过 1,000 条未确认消息可能完全正常。默认阈值可以轻松调整以适应手头的工作负载和系统。我们鼓励用户根据自己的工作负载、监控和操作实践以及对误报的容忍度，重新评估这些范围并进行微调。
指标和图表
大多数 RabbitMQ 和运行时指标在 Grafana 中表现为图表：它们是随时间变化的值。这是可视化系统某些方面如何变化的最简单、最清晰的方法。基于时间的图表使理解关键指标的变化变得容易：消息速率、集群中每个节点使用的内存或并发连接数。除健康指标外，所有指标均为节点特定的，即它们代表单个节点上的指标值。
一些指标，例如分组在 CONNECTIONS 下的面板，是堆叠起来以捕获整个集群的状态。这些指标在单个节点上收集并进行视觉分组，这使得当例如一个节点服务了不成比例的连接数时，很容易注意到。
我们将这样的 RabbitMQ 集群称为不平衡的，这意味着至少在某些方面，少数节点执行了大部分工作。
在下面的示例中，连接在大多数时间里均匀地分布在所有节点上。
图表中的颜色标签
所有图表上的所有指标都与特定的节点名称相关联。例如，所有绘制为绿色的指标都属于名称中包含 0 的节点，例如 rabbit@rmq0。这使得在跨图表时关联特定节点的指标变得容易。对于假设名称中包含 0 的第一个节点，其指标在所有图表中将始终显示为绿色。
在使用 RabbitMQ 概览仪表盘时，记住这一点很重要。如果使用了不同的节点命名约定，颜色在图表间将显得不一致：绿色在某个图表中可能代表 rabbit@foo，而在另一个图表中可能代表 rabbit@bar。
如果是这种情况，必须更新面板以使用不同的节点命名方案。
图表中的阈值
大多数指标都有预配置的阈值。它们定义了指标的预期操作边界。在图表上，它们显示为半透明的橙色或红色区域，如下例所示。
橙色 区域中的指标值表示已超过了某个预定义的阈值。这可能是可以接受的，特别是如果指标恢复的话。接近橙色区域的指标被认为是处于健康状态。
红色 区域中的指标值需要注意，并可能识别出某种形式的服务降级。例如，红色区域中的指标可能表明生效了警报，或者节点缺少文件描述符，无法再接受更多连接或打开新文件。
在上面的示例中，我们有一个 RabbitMQ 集群，它在最佳内存容量下运行，略高于警告阈值。如果已发布的消息出现峰值并需要存储在 RAM 中，节点使用的内存量就会上升，图表上的指标就会下降（因为它表示可用内存量）。
由于系统可用的内存多于分配给其托管的 RabbitMQ 节点的内存，我们注意到 dip 低于 0 B。这强调了为操作系统、导致短期内存使用峰值的日常维护任务以及其他进程留出可用内存的重要性。当 RabbitMQ 节点耗尽了所有允许其使用的内存时，会触发内存警报，整个集群的发布者都将被阻塞。
在图表的右侧，我们可以看到消费者赶上进度，使用的内存量下降。这清除了节点上的内存警报，结果是发布者被解除阻塞。此指标以及集群中相关的指标随后应恢复到其最佳状态。
许多指标没有“正确”的阈值
请注意，Grafana 仪表盘使用的阈值必须有默认值。无论仪表盘开发者选择了什么值，它们都不会适用于所有环境和工作负载。
某些工作负载可能需要更高的阈值，而另一些工作负载可能选择降低阈值。虽然默认值在许多情况下应该足够，但操作员必须审查并调整阈值以满足其特定要求。
图表的相关文档
大多数指标在面板的左上角都有一个帮助图标。
有些指标（如可用磁盘空间指标）会链接到 RabbitMQ 文档中的专用页面。这些页面包含与指标相关的信息。强烈建议熟悉这些链接的指南，这将帮助操作员更好地理解指标的含义。
使用图表发现反模式
任何绘制为红色的指标都暗示系统中存在反模式。此类图表试图突出 RabbitMQ 的非最优使用。应该调查带有非零指标的红色图表。此类指标可能表明 RabbitMQ 配置中存在问题，或客户端（发布者或消费者）的操作非最优。
在下面的示例中，我们可以看到使用极其低效的轮询消费者，它们不断轮询，即使大多数甚至所有轮询操作都没有返回消息。像任何基于轮询的算法一样，它是浪费的，应尽可能避免。
让 RabbitMQ 将消息推送给消费者要高效得多。
示例工作负载
Prometheus 插件仓库包含示例工作负载，这些工作负载使用 PerfTest 来模拟不同的工作负载。它们的目标是练习 RabbitMQ 概览仪表盘中的所有指标。这些示例旨在由开发者和操作员在探索各种指标、其阈值和行为时，根据需要进行编辑和扩展。
要部署工作负载应用程序，请运行 docker compose -f docker-compose-overview.yml up -d。同一命令将在文件更新后重新部署应用程序。
要删除所有工作负载容器，请运行 docker compose -f docker-compose-overview.yml down 或
gmake down
更多仪表盘：节点间连接（链接）、Raft 和 Erlang 运行时
还有两个 Grafana 仪表盘可用：RabbitMQ-Raft 和 Erlang-Distribution。它们收集并可视化与 Raft 共识算法（由 Quorum 队列和其他功能使用）相关的指标，以及更细致的运行时指标，例如节点间连接（通信链接）的状态，例如它们的缓冲区。
这些仪表盘有相应的 RabbitMQ 集群和 PerfTest 实例，它们的启动和停止方式与概览仪表盘相同。欢迎尝试包含在同一个 docker 目录中的其他工作负载。
例如，docker-compose-dist-tls.yml Compose 清单旨在对节点间通信链接施加压力。此工作负载使用大量系统资源。docker-compose-qq.yml 包含一个 Quorum 队列工作负载。
要停止并删除工作负载使用的所有容器，请运行 docker compose -f [file] down 或
make down
安装
与上面的快速入门不同，本节涵盖了针对生产用途的监控设置。
我们假设已经配置并运行了以下工具：
- 一个 3 节点 RabbitMQ 3.11 集群
- Prometheus，包括与所有 RabbitMQ 集群节点的网络连接
- Grafana，包括将上述 Prometheus 实例列为数据源之一的配置
RabbitMQ 配置
集群名称
第一步是给 RabbitMQ 集群一个描述性名称，以便将其与其他集群区分开来。
要查找集群的当前名称，请使用
rabbitmq-diagnostics -q cluster_status
此命令可以在任何集群节点上执行。如果当前集群名称独特且合适，请跳过本段的其余部分。要更改集群名称，请运行以下命令（此处使用的名称仅为示例）：
rabbitmqctl -q set_cluster_name testing-prometheus
启用 rabbitmq_prometheus
接下来，在所有节点上启用 rabbitmq_prometheus 插件：
rabbitmq-plugins enable rabbitmq_prometheus
输出将类似如下：
rabbitmq-plugins enable rabbitmq_prometheus
Enabling plugins on node rabbit@ed9618ea17c9:
rabbitmq_prometheus
The following plugins have been configured:
rabbitmq_management_agent
rabbitmq_prometheus
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@ed9618ea17c9...
The following plugins have been enabled:
rabbitmq_management_agent
rabbitmq_prometheus
rabbitmq_web_dispatch
started 3 plugins.
要确认 RabbitMQ 现在以 Prometheus 格式公开指标，请使用 curl 或类似工具获取前几行：
curl -s localhost:15692/metrics | head -n 3
# TYPE erlang_mnesia_held_locks gauge
# HELP erlang_mnesia_held_locks Number of held locks.
erlang_mnesia_held_locks{node="rabbit@65f1a10aaffa",cluster="rabbit@65f1a10aaffa"} 0
请注意，RabbitMQ 默认在专用 TCP 端口 15692 上公开这些指标。
启用身份验证（可选）
（可选）您可以为指标端点启用 HTTP 身份验证。如果您想这样做，请添加
prometheus.authentication.enabled = true
到 RabbitMQ 配置文件中。
Prometheus 配置
一旦配置 RabbitMQ 将指标公开给 Prometheus，就应该让 Prometheus 知道它应该从哪里抓取 RabbitMQ 指标。有多种方法可以做到这一点。请参阅官方的 Prometheus 配置文档。还有一个针对初学者的 Prometheus 第一步指南。
指标收集和抓取间隔
Prometheus 将周期性地抓取（读取）其监控系统中的指标，默认每 60 秒一次。RabbitMQ 指标也周期性更新，默认每 5 秒一次。由于此值是可配置的，请通过在任何节点上运行以下命令来检查指标更新间隔：
rabbitmq-diagnostics environment | grep collect_statistics_interval
# => {collect_statistics_interval,5000}
返回的值将以毫秒为单位。
对于生产系统，我们建议 Prometheus 抓取间隔最小值为 15s，RabbitMQ 的 collect_statistics_interval 值为 10000（10s）。使用这些值，Prometheus 不会抓取 RabbitMQ 过频，RabbitMQ 也不会不必要地更新指标。如果您为 Prometheus 抓取间隔配置了不同的值，请记住在使用 rate() 在 Grafana 中可视化指标时设置适当的间隔 - 抓取间隔的 4 倍被认为是安全的。
当使用 RabbitMQ 管理 UI 默认的 5 秒自动刷新时，保持默认的 collect_statistics_interval 设置是最佳的。出于这个原因，两个间隔默认为 5000 毫秒（5 秒）。
要确认 Prometheus 正在从所有节点抓取 RabbitMQ 指标，请确保 Prometheus Targets 页面上的所有 RabbitMQ 端点都为 Up，如下所示：
网络接口和端口
端口是使用 prometheus.tcp.port 键配置的：
prometheus.tcp.port = 15692
与消息传递协议监听器类似，可以使用 prometheus.tcp.ip 键来配置 Prometheus 插件 API 端点将使用哪个接口：
prometheus.tcp.ip = 0.0.0.0
要检查运行中的节点使用什么接口和端口，请使用 rabbitmq-diagnostics
rabbitmq-diagnostics -s listeners
# => Interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
聚合指标与按对象指标
RabbitMQ 可以以两种模式返回 Prometheus 指标：
- 聚合：指标按名称聚合。这种模式性能开销较低，且输出大小恒定，即使对象（例如连接和队列）的数量增加时也是如此。
- 按对象：每个对象-指标对的单独指标。对于大量的统计信息发出实体（例如大量的连接和队列），这可能导致非常大的有效负载，并消耗大量的 CPU 资源来序列化数据输出。
对于较大的部署，指标聚合是一个更可预测且实用的选项。它在 metric 发出对象的数量（连接、通道、队列、消费者等）方面扩展性非常好，因为它可以保持响应大小和时间较小。它也很容易进行可视化。
指标聚合的缺点是它失去了数据保真度。使用聚合无法进行按对象指标监控和告警。单个对象指标虽然在某些情况下非常有用，但也难以可视化。试想一下，图表上绘制 20 万个连接会是什么样子，操作员是否能够看懂它。
Prometheus 端点：/metrics
默认情况下，Prometheus（以及其他 Prometheus 兼容的解决方案）期望指标在 /metrics 路径上可用。RabbitMQ 默认在此端点上返回聚合指标。
如果您更喜欢在 /metrics 端点上返回按对象（未聚合）指标，请将 prometheus.return_per_object_metrics 设置为 true：
# can result in a really excessive output produced,
# only suitable for environments with a relatively small
# number of metrics-emitting objects such as connections and queues
prometheus.return_per_object_metrics = true
Prometheus 端点：/metrics/memory-breakdown
此端点提供类似于 rabbitmq-diagnostics memory_breakdown 输出的指标。它通过不同的组件聚合内存使用情况，以提供内存分配位置的更详细视图。
内存分解是一个单独的端点，因为提供此信息需要遍历所有的 Erlang 进程。这在大多数系统中不是问题，但在大型部署中会变得相对昂贵。在拥有数万（或更多）连接和/或队列的系统中（每个连接和队列至少是 1 个进程），建议要么根本不使用此端点，要么不频繁地抓取它。
Prometheus 端点：/metrics/per-object
RabbitMQ 提供了一个专用端点：
GET /metrics/per-object
它始终返回按对象指标，无论 prometheus.return_per_object_metrics 的值如何。因此，您可以保持 prometheus.return_per_object_metrics 的默认值为 false，并在需要时通过在 Prometheus 目标配置中设置 metrics_path = /metrics/per-object 来抓取按对象指标（有关更多信息，请查阅 Prometheus 文档）。
Prometheus 端点：/metrics/detailed
如前所述，在具有许多实体的环境中使用按对象指标的计算成本非常高。例如，/metrics/per-object 会返回系统中所有实体的所有指标，即使其中许多对于大多数客户端（例如监控工具）来说是不需要的。
这就是为什么有一个单独的按对象指标端点，允许调用者仅查询他们需要的指标：
GET /metrics/detailed
默认情况下，它不返回任何指标。所有必需的指标组和过滤器必须作为查询参数提供。例如，
GET /metrics/detailed?vhost=vhost-1&vhost=vhost-2&family=queue_coarse_metrics&family=queue_consumer_count
只会返回请求的指标，并遗漏例如此客户端不感兴趣的所有通道指标。
此端点支持以下参数：
- 零个或多个
family值。只会返回请求的指标系列。完整列表记录在下面。 - 零个或多个
vhost值：提供时，队列和交换机相关指标（queue_coarse_metrics、queue_consumer_count、queue_metrics、queue_delivery_metrics、exchange_metrics、queue_exchange_metrics和ra_metrics）将仅返回所提供虚拟主机中的队列。 - 零个或一个
queue值：一个正则表达式。提供时，只有名称与正则表达式匹配的队列才会包含在响应中。这适用于所有与队列相关的指标系列。仅接受一个queue参数。
返回的指标使用不同的前缀：rabbitmq_detailed_（代替其他端点使用的 rabbitmq_）。这意味着该端点可以与 GET /metrics 一起使用，依赖于其他端点的工具不会受到影响。
由于它在几乎所有情况下查询和提供的数据都较少，因此该端点给系统带来的负载更小。例如，
GET /metrics/detailed?family=queue_coarse_metrics&family=queue_consumer_count
提供的信息足以确定队列中有多少消息以及这些队列有多少消费者。在某些环境中，此查询比查询 GET /metrics/per-object 以仅从响应中获取几个指标的效率高出多达 60 倍。
按队列名称过滤
queue 参数接受正则表达式，并可与 vhost 参数结合使用。
要仅返回名称以 orders- 开头的队列的指标：
GET /metrics/detailed?family=queue_coarse_metrics&queue=^orders-
要组合队列名称和虚拟主机过滤：
GET /metrics/detailed?family=queue_coarse_metrics&vhost=production&queue=^orders-
通用指标
这些是一些通用指标，它们不指代任何特定队列/连接等。
连接/通道/队列流失（Churn）
分组在 connection_churn_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_connections_opened_total | 打开的连接总数 |
| rabbitmq_detailed_connections_closed_total | 关闭或终止的连接总数 |
| rabbitmq_detailed_channels_opened_total | 打开的通道总数 |
| rabbitmq_detailed_channels_closed_total | 关闭的通道总数 |
| rabbitmq_detailed_queues_declared_total | 声明的队列总数 |
| rabbitmq_detailed_queues_created_total | 创建的队列总数 |
| rabbitmq_detailed_queues_deleted_total | 删除的队列总数 |
通过 RabbitMQ 的 Erlang VM/磁盘 IO
分组在 node_coarse_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_process_open_fds | 打开的文件描述符 |
| rabbitmq_detailed_process_open_tcp_sockets | 打开的 TCP 套接字 |
| rabbitmq_detailed_process_resident_memory_bytes | 以字节为单位的内存使用量 |
| rabbitmq_detailed_disk_space_available_bytes | 以字节为单位的可用磁盘空间 |
| rabbitmq_detailed_erlang_processes_used | 已使用的 Erlang 进程 |
| rabbitmq_detailed_erlang_gc_runs_total | Erlang 垃圾回收运行总数 |
| rabbitmq_detailed_erlang_gc_reclaimed_bytes_total | Erlang 垃圾回收回收的内存字节总数 |
| rabbitmq_detailed_erlang_scheduler_context_switches_total | Erlang 调度器上下文切换总数 |
分组在 node_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_process_max_fds | 文件描述符限制 |
| rabbitmq_detailed_process_max_tcp_sockets | TCP 套接字限制 |
| rabbitmq_detailed_resident_memory_limit_bytes | 以字节为单位的内存高水位标记 |
| rabbitmq_detailed_disk_space_available_limit_bytes | 以字节为单位的磁盘剩余空间低水位标记 |
| rabbitmq_detailed_erlang_processes_limit | Erlang 进程限制 |
| rabbitmq_detailed_erlang_scheduler_run_queue | Erlang 调度器运行队列 |
| rabbitmq_detailed_erlang_net_ticktime_seconds | 节点间心跳间隔 |
| rabbitmq_detailed_erlang_uptime_seconds | 节点正常运行时间 |
分组在 node_persister_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_io_read_ops_total | I/O 读取操作总数 |
| rabbitmq_detailed_io_read_bytes_total | I/O 读取字节总数 |
| rabbitmq_detailed_io_write_ops_total | I/O 写入操作总数 |
| rabbitmq_detailed_io_write_bytes_total | I/O 写入字节总数 |
| rabbitmq_detailed_io_sync_ops_total | I/O 同步操作总数 |
| rabbitmq_detailed_io_seek_ops_total | I/O 查找操作总数 |
| rabbitmq_detailed_io_reopen_ops_total | 文件被重新打开的次数总计 |
| rabbitmq_detailed_schema_db_ram_tx_total | Schema DB 内存事务总数 |
| rabbitmq_detailed_schema_db_disk_tx_total | Schema DB 磁盘事务总数 |
| rabbitmq_detailed_msg_store_read_total | 消息存储读取操作总数 |
| rabbitmq_detailed_msg_store_write_total | 消息存储写入操作总数 |
| rabbitmq_detailed_queue_index_read_ops_total | 队列索引读取操作总数 |
| rabbitmq_detailed_queue_index_write_ops_total | 队列索引写入操作总数 |
| rabbitmq_detailed_io_read_time_seconds_total | I/O 读取总时间 |
| rabbitmq_detailed_io_write_time_seconds_total | I/O 写入总时间 |
| rabbitmq_detailed_io_sync_time_seconds_total | I/O 同步总时间 |
| rabbitmq_detailed_io_seek_time_seconds_total | I/O 查找总时间 |
Raft 相关（Quorum 队列、流）指标
分组在 ra_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_raft_bytes_written | 写入的字节数 |
| rabbitmq_detailed_raft_entries | 写入的条目数 |
| rabbitmq_detailed_raft_mem_tables | 处理的内存表数 |
| rabbitmq_detailed_raft_segments | 写入的段数 |
| rabbitmq_detailed_raft_wal_files | 创建的预写日志文件数 |
| rabbitmq_detailed_raft_segments | 写入的段数 |
| rabbitmq_detailed_raft_forced_gcs | 强制垃圾回收运行次数 |
| rabbitmq_detailed_raft_commit_index | 当前的提交索引。 |
| rabbitmq_detailed_raft_wal_files | 创建的预写日志文件数 |
| rabbitmq_detailed_raft_commands | 领导者接收到的命令总数 |
| rabbitmq_detailed_raft_term_and_voted_for_updates | 任期（Term）和投票对象更新总数 |
| rabbitmq_detailed_raft_aux_commands | 接收到的辅助命令总数 |
| rabbitmq_detailed_raft_num_segments | 非空段文件数。 |
| rabbitmq_detailed_raft_read_segment | 读取段总数 |
| rabbitmq_detailed_raft_last_written_index | 日志中最后完全写入并 fsync 的索引。 |
| rabbitmq_detailed_raft_read_ops | 读取操作总数 |
| rabbitmq_detailed_raft_term | 当前任期。 |
| rabbitmq_detailed_raft_snapshot_bytes_written | 写入的快照字节数（未安装） |
| rabbitmq_detailed_raft_command_flushes | 写入的低优先级命令批次总数 |
| rabbitmq_detailed_raft_commit_latency_seconds | 从条目写入日志到其被提交所经历的大致时间。 |
| rabbitmq_detailed_raft_local_queries | 本地查询总数 |
| rabbitmq_detailed_raft_aer_received_follower_empty | 追随者接收到的空追加条目总数 |
| rabbitmq_detailed_raft_msgs_sent | 发送的所有消息（发往 wal 的消息除外） |
| rabbitmq_detailed_raft_aer_replies_success | 接收到的成功追加条目响应总数 |
| rabbitmq_detailed_raft_write_ops | 写入操作总数 |
| rabbitmq_detailed_raft_checkpoint_bytes_written | 写入的检查点字节数 |
| rabbitmq_detailed_raft_read_mem_table | 从内存表读取总数 |
| rabbitmq_detailed_raft_read_cache | 未使用。缓存读取总数 |
| rabbitmq_detailed_raft_bytes_written | 写入的字节数 |
| rabbitmq_detailed_raft_open_segments | 打开的段数 |
| rabbitmq_detailed_raft_snapshots_written | 写入的快照总数 |
| rabbitmq_detailed_raft_last_applied | 最后应用的索引。如果 ra 服务器重启，可能会倒退。 |
| rabbitmq_detailed_raft_invalid_reply_mode_commands | 收到无效回复模式的命令总数 |
| rabbitmq_detailed_raft_snapshots_sent | 发送的快照总数 |
| rabbitmq_detailed_raft_checkpoints_written | 写入的检查点总数 |
| rabbitmq_detailed_raft_send_msg_effects_sent | 执行的 send_msg 效果总数 |
| rabbitmq_detailed_raft_write_resends | 写入重发总数 |
| rabbitmq_detailed_raft_last_index | 日志的最后一个索引。 |
| rabbitmq_detailed_raft_entries | 写入的条目数 |
| rabbitmq_detailed_raft_checkpoint_index | 当前的检查点索引。 |
| rabbitmq_detailed_raft_read_closed_mem_tbl | 未使用。关闭的内存表总数 |
| rabbitmq_detailed_raft_rpcs_sent | RPC 总数，包括 append_entries_rpcs |
| rabbitmq_detailed_raft_dropped_sends | 返回 noconnect 或 nosuspend 的消息发送总数（已丢弃） |
| rabbitmq_detailed_raft_effective_machine_version | 机器当前有效的版本号。 |
| rabbitmq_detailed_raft_batches | 写入的批次数量 |
| rabbitmq_detailed_raft_release_cursors | 释放游标更新总数 |
| rabbitmq_detailed_raft_checkpoints | 执行的检查点效果数量 |
| rabbitmq_detailed_raft_snapshot_installed | 安装的快照总数 |
| rabbitmq_detailed_raft_pre_vote_elections | 预投票选举总数 |
| rabbitmq_detailed_raft_aer_replies_fail | 失败的追加条目总数 |
| rabbitmq_detailed_raft_snapshot_index | 当前的快照索引。 |
| rabbitmq_detailed_raft_mem_tables | 处理的内存表数 |
| rabbitmq_detailed_raft_fetch_term | 获取的任期总数 |
| rabbitmq_detailed_raft_reserved_2 | 保留计数器 |
| rabbitmq_detailed_raft_reserved_1 | 保留计数器 |
| rabbitmq_detailed_raft_consistent_queries | 一致性查询请求总数 |
| rabbitmq_detailed_raft_checkpoints_promoted | 升级为快照的检查点数量 |
| rabbitmq_detailed_raft_writes | 写入的条目数 |
| rabbitmq_detailed_raft_aer_received_follower | 追随者接收到的追加条目总数 |
| rabbitmq_detailed_raft_elections | 选举总数 |
认证指标
分组在 auth_attempt_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_auth_attempts_total | 授权尝试总数 |
| rabbitmq_detailed_auth_attempts_succeeded_total | 成功的认证尝试总数 |
| rabbitmq_detailed_auth_attempts_failed_total | 失败的认证尝试总数 |
分组在 auth_attempt_detailed_metrics 下。聚合时，这些加起来与 auth_attempt_metrics 的数字相同。
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_auth_attempts_detailed_total | 带有源信息的授权尝试总数 |
| rabbitmq_detailed_auth_attempts_detailed_succeeded_total | 带有源信息的成功授权尝试总数 |
| rabbitmq_detailed_auth_attempts_detailed_failed_total | 带有源信息的失败授权尝试总数 |
队列指标
此组中的每个指标都通过其标签指向单个队列。因此，这里的响应大小直接与节点上托管的队列数量成正比。
下面的指标按照从收集成本最低到成本最高的顺序排列。
队列粗略指标
分组在 queue_coarse_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_messages_ready | 准备好交付给消费者的消息 |
| rabbitmq_detailed_queue_messages_unacked | 已交付给消费者但尚未确认的消息 |
| rabbitmq_detailed_queue_messages | 准备好和未确认消息的总和 - 总队列深度 |
| rabbitmq_detailed_queue_process_reductions_total | 队列进程规约（reductions）总数 |
队列交付指标
这些指标类似于分组在 channel_queue_metrics 下的指标，但不包含通道 ID。它们对于单独监控每个队列的状态很有用。
分组在 queue_delivery_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_get_ack_total | 在手动确认模式下，通过 basic.get 从队列获取的消息总数 |
| rabbitmq_detailed_queue_get_total | 在自动确认模式下，通过 basic.get 从队列获取的消息总数 |
| rabbitmq_detailed_queue_messages_delivered_ack_total | 在手动确认模式下，从队列交付给消费者的消息总数 |
| rabbitmq_detailed_queue_messages_delivered_total | 在自动确认模式下，从队列交付给消费者的消息总数 |
| rabbitmq_detailed_queue_messages_redelivered_total | 从队列重新交付给消费者的消息总数 |
| rabbitmq_detailed_queue_messages_acked_total | 消费者在队列上确认的消息总数 |
| rabbitmq_detailed_queue_get_empty_total | basic.get 操作在队列上未获取到消息的总次数 |
按队列消费者计数
分组在 queue_consumer_count 下。这是 queue_metrics 的子集，如果请求了 queue_metrics，则会跳过此项。
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_consumers | 队列上的消费者 |
此指标对于快速检测消费者的问题（例如没有在线消费者时）很有用。这就是为什么它是单独公开的原因。
详细队列指标
分组在 queue_metrics 下。该组包含每个队列的所有指标，生成成本可能相对较高。
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_consumers | 队列上的消费者 |
| rabbitmq_detailed_queue_consumer_capacity | 消费者容量 |
| rabbitmq_detailed_queue_consumer_utilisation | 与消费者容量相同 |
| rabbitmq_detailed_queue_process_memory_bytes | Erlang 队列进程使用的内存字节数 |
| rabbitmq_detailed_queue_messages_ram | 存储在内存中的准备好和未确认的消息 |
| rabbitmq_detailed_queue_messages_ram_bytes | 存储在内存中的准备好和未确认消息的大小 |
| rabbitmq_detailed_queue_messages_ready_ram | 存储在内存中的准备好消息 |
| rabbitmq_detailed_queue_messages_unacked_ram | 存储在内存中的未确认消息 |
| rabbitmq_detailed_queue_messages_persistent | 持久化消息 |
| rabbitmq_detailed_queue_messages_persistent_bytes | 持久化消息的字节大小 |
| rabbitmq_detailed_queue_messages_bytes | 准备好和未确认消息的字节大小 |
| rabbitmq_detailed_queue_messages_ready_bytes | 准备好消息的字节大小 |
| rabbitmq_detailed_queue_messages_unacked_bytes | 所有未确认消息的字节大小 |
| rabbitmq_detailed_queue_messages_paged_out | 分页到磁盘的消息 |
| rabbitmq_detailed_queue_messages_paged_out_bytes | 分页到磁盘的消息的字节大小 |
| rabbitmq_detailed_queue_head_message_timestamp | 队列中第一条消息的时间戳（如果有） |
| rabbitmq_detailed_queue_disk_reads_total | 队列从磁盘读取消息的总次数 |
| rabbitmq_detailed_queue_disk_writes_total | 队列向磁盘写入消息的总次数 |
| rabbitmq_detailed_stream_segments | 流分段文件总数 |
交换机指标
此组中的每个指标都通过其标签指向单个交换机。因此，这里的响应大小直接与节点上托管的交换机数量成正比。
这些指标类似于分组在 channel_exchange_metrics 下的指标，但不包含通道 ID。它们对于单独监控每个交换机的状态很有用。
分组在 exchange_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_exchange_messages_published_total | 发布到交换机的消息总数 |
| rabbitmq_detailed_exchange_messages_confirmed_total | 发布到交换机并得到确认的消息总数 |
| rabbitmq_detailed_exchange_messages_unroutable_returned_total | 作为 mandatory 发布到交换机并作为不可路由退回给发布者的消息总数 |
| rabbitmq_detailed_exchange_messages_unroutable_dropped_total | 作为非 mandatory 发布到交换机并作为不可路由丢弃的消息总数 |
队列-交换机指标
此组中的每个指标都通过其标签指向单个队列-交换机对。
这些指标类似于分组在 channel_queue_exchange_metrics 下的指标，但不包含通道 ID。它们对于单独监控每个队列-交换机对的状态很有用。
分组在 queue_exchange_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_exchange_messages_published_total | 通过交换机发布到队列的消息总数 |
连接/通道指标
所有这些指标都在其标签中包含了通道的 Erlang 进程 ID。此数据用处不大，仅用于区分不同通道的指标。
这些指标是生成成本最高的。
连接指标
分组在 connection_coarse_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_connection_incoming_bytes_total | 连接上接收的总字节数 |
| rabbitmq_detailed_connection_outgoing_bytes_total | 连接上发送的总字节数 |
| rabbitmq_detailed_connection_process_reductions_total | 连接进程规约（reductions）总数 |
分组在 connection_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_connection_incoming_packets_total | 连接上接收的数据包总数 |
| rabbitmq_detailed_connection_outgoing_packets_total | 连接上发送的数据包总数 |
| rabbitmq_detailed_connection_pending_packets | 等待在连接上发送的数据包数量 |
| rabbitmq_detailed_connection_channels | 连接上的通道数量 |
常规通道指标
分组在 channel_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_channel_consumers | 通道上的消费者数量 |
| rabbitmq_detailed_channel_messages_unacked | 已交付但尚未确认的消息 |
| rabbitmq_detailed_channel_messages_unconfirmed | 已发布但尚未确认的消息 |
| rabbitmq_detailed_channel_messages_uncommitted | 事务中已收到但尚未提交的消息 |
| rabbitmq_detailed_channel_acks_uncommitted | 事务中尚未提交的消息确认 |
| rabbitmq_detailed_consumer_prefetch | 每个消费者的未确认消息限制 |
| rabbitmq_detailed_channel_prefetch | 通道上所有消费者的未确认消息总限制 |
分组在 channel_process_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_channel_process_reductions_total | 通道进程规约（reductions）总数 |
带有队列/交换机分解的通道指标
分组在 channel_exchange_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_channel_messages_published_total | 在通道上发布到交换机的消息总数 |
| rabbitmq_detailed_channel_messages_confirmed_total | 在通道上发布到交换机并得到确认的消息总数 |
| rabbitmq_detailed_channel_messages_unroutable_returned_total | 作为 mandatory 发布到交换机并作为不可路由退回给发布者的消息总数 |
| rabbitmq_detailed_channel_messages_unroutable_dropped_total | 作为非 mandatory 发布到交换机并作为不可路由丢弃的消息总数 |
分组在 channel_queue_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_channel_get_ack_total | 在手动确认模式下，通过 basic.get 获取的消息总数 |
| rabbitmq_detailed_channel_get_total | 在自动确认模式下，通过 basic.get 获取的消息总数 |
| rabbitmq_detailed_channel_messages_delivered_ack_total | 在手动确认模式下，交付给消费者的消息总数 |
| rabbitmq_detailed_channel_messages_delivered_total | 在自动确认模式下，交付给消费者的消息总数 |
| rabbitmq_detailed_channel_messages_redelivered_total | 重新交付给消费者的消息总数 |
| rabbitmq_detailed_channel_messages_acked_total | 消费者确认的消息总数 |
| rabbitmq_detailed_channel_get_empty_total | basic.get 操作未获取到消息的总次数 |
分组在 channel_queue_exchange_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_queue_messages_published_total | 发布到队列的消息总数 |
虚拟主机和交换机指标
当在共享集群中创建虚拟主机或交换机时，这些附加指标可能会很有用。这些指标是集群范围的，而不是节点局部的。因此，这些指标不得在集群节点之间进行聚合。
分组在 vhost_status 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_cluster_vhost_status | 给定的 vhost 是否正在运行 |
分组在 exchange_names 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_cluster_exchange_name | 枚举交换机，不包含任何额外信息。此值是集群范围的。比 exchange_bindings 更便宜的替代方案 |
分组在 exchange_bindings 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_cluster_exchange_bindings | 交换机的绑定数量。此值是集群范围的。 |
流（Stream）消费者指标
分组在 stream_consumer_metrics 下：
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_stream_consumer_max_offset_lag | 给定流的最高消费者偏移延迟 |
抓取端点超时
在某些环境中，没有多少发出统计信息的实体（队列、连接、通道），而在另一些环境中，抓取 HTTP 端点可能必须向客户端返回一个相当大的数据集（例如成千上万行）。在这种情况下，处理请求所需的时间可能会超过嵌入式 HTTP 服务器和 Prometheus 使用的 HTTP 客户端中的某些超时限制。
可以使用 prometheus.tcp.idle_timeout、prometheus.tcp.inactivity_timeout、prometheus.tcp.request_timeout 设置来增加插件端 HTTP 请求超时时间。
prometheus.tcp.inactivity_timeout控制 HTTP(S) 客户端的 TCP 连接非活动超时时间。当达到此值时，连接将被 HTTP 服务器关闭。prometheus.tcp.request_timeout控制客户端必须发送 HTTP 请求的时间窗口。prometheus.tcp.idle_timeout控制客户端在 HTTP 请求上下文中发送更多数据（如果有）的时间窗口。
如果在 Prometheus 节点和它抓取的 RabbitMQ 节点之间使用了负载均衡器或代理，inactivity_timeout 和 idle_timeout 的值应至少与负载均衡器使用的超时和非活动值一样大，通常应该更大。
以下是修改超时时间的配置片段示例：
prometheus.tcp.idle_timeout = 120000
prometheus.tcp.inactivity_timeout = 120000
prometheus.tcp.request_timeout = 120000
Grafana 配置
此设置中的最后一个组件是 Grafana。如果这是您第一次将 Grafana 与 Prometheus 集成，请按照官方集成指南进行操作。
将 Grafana 与读取和存储 RabbitMQ 指标的 Prometheus 实例集成后，就可以导入 Team RabbitMQ 维护的 Grafana 仪表盘了。请参阅关于如何在 Grafana 中导入仪表盘的官方 Grafana 教程。
用于 RabbitMQ 和 Erlang 的 Grafana 仪表盘是开源的，可以从 rabbitmq-server GitHub 仓库中公开获取。
要将 RabbitMQ-Overview 仪表盘导入 Grafana：
- 前往 Grafana 网站查看官方 RabbitMQ Grafana 仪表盘列表。
- 选择 RabbitMQ-Overview 仪表盘。
- 点击 Download JSON 链接或复制仪表盘 ID。
- 将文件内容复制粘贴到 Grafana 中，然后点击 Load，如下所示：
- 或者，将仪表盘 ID 粘贴到 Grafana.com Dashboard 字段中。
对您希望与此 RabbitMQ 部署一起使用的所有其他 Grafana 仪表盘重复此过程。
最后，将 Grafana 使用的默认数据源切换为 prometheus。
恭喜！您的 RabbitMQ 现在已由 Prometheus 和 Grafana 进行监控！
使用 TLS 保护 Prometheus 抓取端点
Prometheus 指标可以像其他监听器一样通过 TLS 进行保护。例如，在配置文件中：
prometheus.ssl.port = 15691
prometheus.ssl.cacertfile = /full/path/to/ca_certificate.pem
prometheus.ssl.certfile = /full/path/to/server_certificate.pem
prometheus.ssl.keyfile = /full/path/to/server_key.pem
prometheus.ssl.password = password-if-keyfile-is-encrypted
## To enforce TLS (disable the non-TLS port):
# prometheus.tcp.listener = none
要使用对等验证启用 TLS，请使用类似于以下的配置：
prometheus.ssl.port = 15691
prometheus.ssl.cacertfile = /full/path/to/ca_certificate.pem
prometheus.ssl.certfile = /full/path/to/server_certificate.pem
prometheus.ssl.keyfile = /full/path/to/server_key.pem
prometheus.ssl.password = password-if-keyfile-is-encrypted
prometheus.ssl.verify = verify_peer
prometheus.ssl.depth = 2
prometheus.ssl.fail_if_no_peer_cert = true
## To enforce TLS (disable the non-TLS port):
# prometheus.tcp.listener = none