使用 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 概览仪表板看起来是这样的
快速入门
开始之前
本节介绍如何设置一个包含 Prometheus 和 Grafana 仪表板的 RabbitMQ 集群，以及一些将产生一些活动和有意义指标的应用程序。
通过此设置，您将能够与本地运行的 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 浏览器中导航到 http://localhost: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 共识算法（由 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 上公开指标。
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 抓取间隔配置了不同的值，请记住在使用 Grafana 中的 rate() 可视化指标时设置适当的间隔 - 抓取间隔的 4 倍被认为是安全的。
当使用 RabbitMQ 管理 UI 默认的 5 秒自动刷新时，保持默认的 collect_statistics_interval 设置是最佳的。出于这个原因，这两个间隔默认值均为 5000 毫秒（5 秒）。
要确认 Prometheus 正在从所有节点抓取 RabbitMQ 指标，请确保 Prometheus Targets 页面上的所有 RabbitMQ 端点都为 Up，如下所示
网络接口和端口
端口使用 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 资源用于序列化数据以输出。
对于较大的部署，指标聚合是一种更可预测且实用的选择。通过保持响应大小和时间较小，它在系统中的指标发射对象（连接、通道、队列、消费者等）的数量方面具有良好的可伸缩性。它也出乎意料地易于可视化。
指标聚合的缺点是它会丢失数据保真度。聚合无法实现按对象指标和警报。个体对象指标虽然在某些情况下非常有用，但也难以可视化。考虑一下图表上绘制了 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）将仅针对提供的虚拟主机中的队列返回
返回的指标使用不同的前缀：rabbitmq_detailed_（而不是其他端点使用的 rabbitmq_）。这意味着该端点可以与 GET /metrics 一起使用，并且依赖于其他端点的工具不会受到影响。
由于它在几乎所有情况下都查询和服务较少的数据，因此此端点对系统的负载较小。例如，
GET /metrics/detailed?family=queue_coarse_metrics&family=queue_consumer_count
提供了足够的指标来确定有多少消息入队以及这些队列有多少消费者。在某些环境中，此查询的效率比查询 GET /metrics/per-object 仅从响应中获取几个指标高出 60 倍。
通用指标
这些是一些通用指标，它们不引用任何特定的队列/连接/等等。
连接/通道/队列流失
在 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 | 删除的队列总数 |
Erlang VM/磁盘 IO（通过 RabbitMQ）
在 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 term 编号 |
| 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 | 队列进程 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，则跳过此指标子集
| 指标 | 描述 |
|---|---|
| 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 | 作为 non-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 | 作为 non-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_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 实例集成后，就可以导入 RabbitMQ 团队维护的 Grafana 仪表板了。请参考 官方 Grafana 教程，了解如何在 Grafana 中导入仪表板。
RabbitMQ 和 Erlang 的 Grafana 仪表板是开源的，并且可以从 rabbitmq-server GitHub 存储库公开获取。
要将 RabbitMQ-Overview 仪表板导入到 Grafana
- 转到 Grafana 网站以查看官方 RabbitMQ Grafana 仪表板列表。
- 选择 RabbitMQ-Overview 仪表板。
- 单击 Download JSON 链接或复制仪表板 ID。
- 将文件内容复制粘贴到 Grafana 中，然后单击 Load，如下所示
- 或者，在字段 Grafana.com Dashboard 中粘贴仪表板 ID。
对您想要与此 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