使用 Prometheus 和 Grafana 监控
概述
本指南介绍了使用两个流行工具监控 RabbitMQ：Prometheus，一个监控工具包；以及 Grafana，一个指标可视化系统。
这两个工具一起构成了一个强大的工具包，用于长期收集指标并监控 RabbitMQ 集群。虽然 RabbitMQ 管理 UI 也提供了对部分指标的访问权限，但它在设计上不尝试成为长期指标收集解决方案。
请先阅读 关于监控的主要指南。当使用 Prometheus 和 Grafana 时，监控原则和可用指标大多是相关的。
本指南涵盖的一些关键主题是
- Prometheus 支持基础知识
- Grafana 支持基础知识
- 快速入门，用于本地实验
- 安装步骤，用于生产系统
- 两种类型的抓取端点响应：聚合指标与个体实体指标
Grafana 仪表盘遵循一些约定，以使系统更易于观察，并更容易发现反模式。其设计决策在若干部分中进行了说明
- RabbitMQ 概述仪表盘
- 概述仪表盘上的运行状况指标
- 图表颜色标签 约定
- 图表阈值
- 每个图表的相关文档（指标）
- 发现反模式
- 其他可用仪表盘
- TLS 支持，用于 Prometheus 抓取端点
内置 Prometheus 支持
RabbitMQ 附带内置的 Prometheus & Grafana 支持。
对 Prometheus 指标收集器的支持包含在 rabbitmq_prometheus 插件中。该插件在专用的 TCP 端口上以 Prometheus 文本格式公开所有 RabbitMQ 指标。
这些指标提供了对 RabbitMQ 节点和 运行时 状态的深入了解。它们使对 RabbitMQ、使用它的应用程序和各种基础设施元素的行为的推理更加明智。
Grafana 支持
除非可视化收集的指标，否则它们没有太大用处。RabbitMQ 团队提供了一套 预构建的 Grafana 仪表盘，以上下文特定方式可视化大量可用的 RabbitMQ 和 运行时 指标。
有许多仪表盘可用
等等。每个仪表盘旨在提供对系统特定部分的洞察。当一起使用时，它们能够详细解释 RabbitMQ 和应用程序行为。
请注意，Grafana 仪表盘是有见地的，并使用了一些约定，例如，更快地发现系统运行状况问题 或使 跨图表引用 成为可能。与所有 Grafana 仪表盘一样，它们也高度可定制。它们假设的约定被认为是最佳实践，因此建议使用它们。
示例
当 RabbitMQ 与 Prometheus 和 Grafana 集成时，RabbitMQ 概述仪表盘如下所示
快速入门
开始之前
本节说明如何设置 RabbitMQ 集群以及 Prometheus 和 Grafana 仪表盘，以及一些将产生一些活动和有意义指标的应用程序。
通过这种设置，您将能够与本地运行的 RabbitMQ、Prometheus & Grafana 进行交互。您还将能够尝试不同的负载配置文件，以了解它们如何组合在一起，了解仪表盘、面板等等。
这只是一个示例；rabbitmq_prometheus 插件和我们的 Grafana 仪表盘不需要使用下面演示的 Docker Compose。
先决条件
以下说明假设主机已安装某些工具
- 一个用于运行命令的终端
- Git，用于克隆存储库
- Docker Desktop，用于在本地使用 Docker Compose
- 一个用于浏览仪表盘的 Web 浏览器
它们的安装不在本指南的范围之内。使用
git version
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://127.0.0.1:3000/dashboards。它将显示一个登录页面。对于用户名和密码都使用 admin。在第一次登录时，Grafana 会建议您更改密码。为了本示例的方便，建议您跳过此步骤。
导航到看起来像这样的 RabbitMQ-Overview 仪表盘
恭喜！您现在有一个与本地运行的 Prometheus & Grafana 集成的 3 节点 RabbitMQ 集群。现在是学习更多关于可用仪表盘的好时机。
RabbitMQ 概述仪表盘
管理 UI 概述页面中可用的所有指标都可以在概述 Grafana 仪表盘中找到。它们按对象类型分组，重点关注 RabbitMQ 节点和消息速率。
运行状况指标
仪表盘顶部的 单个统计指标 捕获单个 RabbitMQ 集群的运行状况。在本例中，只有一个 RabbitMQ 集群，即 rabbitmq-overview，如仪表盘标题正下方的 集群 下拉菜单所示。
所有 RabbitMQ Grafana 仪表盘上的面板使用不同的颜色来捕获以下指标状态
- 绿色 表示指标的值在健康范围内
- 蓝色 表示利用率不足或某种形式的降级
- 红色 表示指标的值低于或高于被认为健康的范围
对 单个统计指标 的默认范围 不会对所有 RabbitMQ 部署都是最优的。例如，在具有许多消费者和/或高预取值的部署环境中，拥有超过 1,000 条未确认的消息可能完全没问题。可以轻松调整默认阈值以适合手头的负载和系统。鼓励用户重新审视这些范围，并根据自己的负载、监控和操作实践以及对误报的容忍度进行调整。
指标和图表
大多数 RabbitMQ 和运行时指标在 Grafana 中以图表形式表示：它们是随时间变化的值。这是可视化系统某些方面如何变化的最简单、最清晰的方法。基于时间绘制图表可以轻松了解关键指标的变化：消息速率、集群中每个节点使用的内存或并发连接数。除运行状况指标外，所有指标都是 特定于节点 的，即它们表示单个节点上指标的值。
一些指标，例如 连接 下的分组面板，是堆叠的，以捕获 整个集群的状态。这些指标是在各个节点上收集的，并在视觉上进行分组，这使得很容易注意到例如一个节点为多少连接提供服务时，其他节点所占比例过低的情况。
我们将此类 RabbitMQ 集群称为 不平衡 的，这意味着至少在某些方面，少数节点承担了大部分工作。
在下面的示例中，连接在大多数情况下均匀分布在所有节点上
图表中的颜色标签
所有图表上的所有指标都与特定节点名称相关联。例如，所有以绿色绘制的指标都属于名称中包含 0 的节点，例如 rabbit@rmq0。这使得跨图表关联特定节点的指标变得容易。第一个节点的指标（假定其名称中包含 0）始终以绿色显示在所有图表中。
在使用 RabbitMQ 概览仪表盘时，请务必牢记这一点。如果使用不同的节点命名约定，图形中的颜色将显得不一致：绿色可能代表一个图形中的 rabbit@foo，而另一个图形中则代表 rabbit@bar。
在这种情况下，必须更新面板以使用不同的节点命名方案。
图形中的阈值
大多数指标都具有预先配置的阈值。它们定义了指标的预期运行边界。在图形中，它们显示为半透明的橙色或红色区域，如下面的示例所示。
处于橙色区域的指标值表示某些预定义阈值已被超过。这可能是可以接受的，尤其是当指标恢复时。接近橙色区域的指标被认为处于健康状态。
处于红色区域的指标值需要关注，可能表明某种形式的服务降级。例如，红色区域的指标可能表明警报生效或节点已用完文件描述符，无法再接受任何连接或打开新文件。
在上面的示例中，我们有一个 RabbitMQ 集群，它以最佳内存容量运行，这略高于警告阈值。如果发布的消息出现峰值，这些消息应该存储在 RAM 中，节点使用的内存量会增加，图形上的指标会下降（因为它指示可用内存量）。
由于系统拥有比分配给托管 RabbitMQ 节点的内存更多的可用内存，我们注意到低于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 共识算法（由仲裁队列和其他功能使用）相关的指标，以及更多细节的运行时指标，例如节点间通信缓冲区。
这些仪表盘具有相应的 RabbitMQ 集群和 PerfTest 实例，它们与概览仪表盘一样启动和停止。随意尝试 相同 docker 目录 中包含的其他工作负载。
例如，docker-compose-dist-tls.yml Compose 清单旨在对节点间通信链路进行压力测试。此工作负载使用大量系统资源。docker-compose-qq.yml 包含一个仲裁队列工作负载。
要停止和删除工作负载使用的所有容器，请运行 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。
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 ms（5 秒）。
要确认 Prometheus 是否正在从所有节点抓取 RabbitMQ 指标，请确保 Prometheus 目标页面上的所有 RabbitMQ 端点都处于正常状态，如下所示
网络接口和端口
端口使用 prometheus.tcp.port 键配置
prometheus.tcp.port = 15692
可以配置 Prometheus 插件 API 端点将使用哪个接口，类似于消息协议监听器，使用 prometheus.tcp.ip 键
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 资源来序列化数据以进行输出。
指标聚合对于大型部署来说是一个更可预测和实用的选择。它在系统中发出指标的对象数量（连接、通道、队列、消费者等）方面扩展得很好，通过保持响应大小和时间较小。它也易于可视化。
指标聚合的缺点是会丢失数据保真度。聚合后无法进行按对象指标和告警。单个对象指标虽然在某些情况下非常有用，但也很难可视化。考虑一下包含 200K 个连接的图表会是什么样子，以及操作员是否能够理解它。
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 进程。在大多数系统中这不成问题，但在大型部署中会变得相对昂贵。在拥有数万（或更多）连接和/或队列的系统中（每个连接和队列至少是一个进程），建议要么完全不使用此端点，要么以较低的频率抓取它。
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）将只返回提供的虚拟主机中的队列。
返回的指标使用不同的前缀：rabbitmq_detailed_（而不是其他端点使用的 rabbitmq_）。这意味着此端点可以与 GET /metrics 一起使用，并且依赖于其他端点的工具不会受到影响。
由于它几乎在所有情况下都查询和提供较少的数据，因此此端点对系统的负载较小。例如，
GET /metrics/detailed?family=queue_coarse_metrics&family=queue_consumer_count
仅提供足够的指标来确定有多少消息已入队以及这些队列有多少消费者。在某些环境中，此查询比查询 GET /metrics/per-object 以从响应中获取几个指标效率高出 60 倍。
通用指标
这些是一些通用指标，它们不引用任何特定的队列/连接/等。
连接/通道/队列 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/磁盘 I/O
归类于 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_term_total | 当前 Raft 学期号 |
| rabbitmq_detailed_raft_log_snapshot_index | Raft 日志快照索引 |
| rabbitmq_detailed_raft_log_last_applied_index | Raft 日志最后应用索引 |
| rabbitmq_detailed_raft_log_commit_index | Raft 日志提交索引 |
| rabbitmq_detailed_raft_log_last_written_index | Raft 日志最后写入索引 |
| rabbitmq_detailed_raft_entry_commit_latency_seconds | 日志条目提交所花费的时间 |
身份验证指标
归类于 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 | 队列进程减少的总数 |
队列交付指标
这些指标类似于 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 | 作为强制性消息发布到交换机并作为不可路由返回给发布者的消息总数 |
| rabbitmq_detailed_exchange_messages_unroutable_dropped_total | 作为非强制性消息发布到交换机并作为不可路由丢弃的消息总数 |
队列-交换机指标
此组中的每个指标都通过其标签指向单个队列-交换机对。
这些指标类似于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 | 连接进程减少的总数 |
分组在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 | 通道进程减少的总数 |
具有队列/交换机细分的通道指标
分组在channel_exchange_metrics下
| 指标 | 描述 |
|---|---|
| rabbitmq_detailed_channel_messages_published_total | 通道上发布到交换机的消息总数 |
| rabbitmq_detailed_channel_messages_confirmed_total | 通道上发布到交换机并确认的消息总数 |
| rabbitmq_detailed_channel_messages_unroutable_returned_total | 作为强制性消息发布到交换机并作为不可路由返回给发布者的消息总数 |
| rabbitmq_detailed_channel_messages_unroutable_dropped_total | 作为非强制性消息发布到交换机并作为不可路由丢弃的消息总数 |
分组在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 | 给定虚拟主机是否正在运行 |
分组在exchange_names下
| 指标 | 描述 |
|---|---|
| rabbitmq_cluster_exchange_name | 枚举交换机，不包含任何其他信息。此值是集群范围的。比exchange_bindings更便宜的替代方案 |
分组在exchange_bindings下
| 指标 | 描述 |
|---|---|
| rabbitmq_cluster_exchange_bindings | 交换机的绑定数量。此值是集群范围的。 |
抓取端点超时
在某些环境中，没有很多发出统计信息的实体（队列、连接、通道），而在其他环境中，抓取 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 仪表板。
- 单击下载 JSON 链接或复制仪表板 ID。
- 在 Grafana 中复制粘贴文件内容，然后单击加载，如下所示
- 或者，将仪表板 ID 粘贴到Grafana.com 仪表板字段中。
对要与该 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