版本：4.0

监控

概述

本文档概述了与 RabbitMQ 监控相关的主题。监控 RabbitMQ 及其使用的应用程序至关重要。监控有助于在问题影响其余环境并最终影响最终用户之前检测到问题。

强烈建议将 Prometheus 和 Grafana 组合用于 RabbitMQ 监控。

监控是一个广泛的主题。本指南涵盖了几个

什么是监控、为什么它很重要以及存在的常用方法
可用的监控选项
- 兼容 Prometheus 的用于生产集群的外部抓取器
- Kubernetes 运算符监控 Kubernetes 用户的功能
- 交互式命令行工具用于集中式故障排除
- 管理插件的 HTTP API 用于开发环境
哪些基础设施和内核指标对于监控很重要
哪些 RabbitMQ 指标可用
监控会引入多少开销以及应多久执行一次监控检查？
应用程序级指标
如何处理节点健康检查以及为什么它比单个 CLI 命令更复杂
在部署或升级期间将健康检查用作节点就绪探针
日志聚合在所有节点和应用程序之间与监控密切相关

许多流行的工具（开源和商业工具）都可用于监控 RabbitMQ。如上所述，RabbitMQ 团队建议大多数用户使用 Prometheus 和 Grafana 的组合。在 Kubernetes 上，Prometheus 插件由 Kubernetes RabbitMQ 运算符自动启用。

什么是监控？

在本指南中，我们将监控定义为一个过程，该过程通过一段时间内的健康检查和指标来捕获系统的行为。这有助于检测异常情况：当系统不可用、遇到异常负载、某些资源耗尽或以其他方式超出其正常（预期）参数时。监控涉及长期收集和存储指标，这不仅对于异常检测很重要，而且对于根本原因分析、趋势检测和容量规划也很重要。

监控系统通常与警报系统集成。当监控系统检测到异常时，通常会将某种警报传递到警报系统，警报系统会通知相关方，例如技术运营团队。

拥有监控意味着更容易检测到系统行为中的重要偏差（从某些区域的服务降级到完全不可用），并且查找根本原因所需的时间大大减少。在没有监控数据的情况下操作分布式系统就像试图在没有 GPS 导航设备或指南针的情况下走出森林一样。无论这个人多么聪明或经验丰富，拥有相关信息对于获得良好的结果都非常重要。

健康检查在监控中的作用

健康检查是监控的另一个重要方面。健康检查涉及一个命令或一组命令，这些命令会一段时间内收集被监控系统的一些基本指标，并根据该指标断言系统的状态（健康状况）。

例如，RabbitMQ 的 Erlang VM 是否正在运行就是一个这样的检查。在这种情况下，指标是“操作系统进程是否正在运行？”。正常运行参数是“进程必须正在运行”。最后，还有一个评估步骤。

当然，还有更多种类的健康检查。哪种检查最合适取决于所使用的“健康节点”的定义。因此，这是一个特定于系统和团队的决策。RabbitMQ CLI 工具提供可作为有用健康检查的命令。它们将在本指南后面讨论。

虽然健康检查是一个有用的工具，但它们只能提供对系统状态的有限了解，因为它们在设计上专注于一个或少数几个指标，通常检查单个节点，并且只能推断该节点在特定时间点的状态。为了进行更全面的评估，请一段时间内收集更多指标。这可以检测更多类型的异常情况，因为有些异常情况只能在较长时间内识别出来。这通常由称为监控工具的工具完成，这些工具种类繁多。本指南介绍了一些用于 RabbitMQ 监控的工具。

系统和 RabbitMQ 指标

某些指标是 RabbitMQ 特定的：它们是由 RabbitMQ 节点收集和报告的。在本指南中，我们将其称为“RabbitMQ 指标”。例如，使用的套接字描述符数量、已排队消息的总数或节点间通信流量速率。其他指标是由操作系统内核收集和报告的。此类指标通常称为系统指标或基础设施指标。系统指标不是特定于 RabbitMQ 的。例如，CPU 利用率、进程使用的内存量、网络数据包丢失率等。这两种类型都非常重要。单个指标并不总是很有用，但当一起分析时，它们可以提供对系统状态更全面的了解。然后，操作员可以形成关于正在发生的事情以及需要解决的问题的假设。

基础设施和内核指标

构建有用的监控系统的第一步是从基础设施和内核指标开始。它们有很多，但有些比其他的更重要。在运行 RabbitMQ 节点或应用程序的所有主机上收集以下指标

CPU 统计信息（用户、系统、iowait、空闲百分比）
内存使用情况（使用、缓冲、缓存和空闲百分比）
内核页面缓存，尤其是在使用流的集群中
虚拟内存统计信息（脏页面刷新、回写量）
磁盘 I/O（操作频率、每单位时间传输的数据量、长时间 I/O 操作完成的统计分布、I/O 操作失败率）
用于节点数据目录的挂载点的可用磁盘空间
beam.smp 使用的文件描述符与最大系统限制的对比
按状态划分的 TCP 连接（ESTABLISHED、CLOSE_WAIT、TIME_WAIT）
网络吞吐量（接收到的字节、发送的字节）和最大网络吞吐量
网络延迟（集群中所有 RabbitMQ 节点之间以及到/来自客户端的延迟）

现有的工具（例如 Prometheus 或 Datadog）可以收集基础设施和内核指标，并在一段时间内存储和可视化它们，这些工具并不少。

使用兼容 Prometheus 的工具进行监控

RabbitMQ 带有一个内置插件，该插件以 Prometheus 格式公开指标：rabbitmq_prometheus。该插件公开了一些 RabbitMQ 指标，用于节点、连接、队列、消息速率等。此插件开销低，非常适合生产环境。

Prometheus 与 Grafana 或 ELK 堆栈相比其他监控选项具有许多优势

监控系统与被监控系统的解耦
较低的开销
长期指标存储
访问其他相关指标，例如运行时的指标
更强大且可自定义的用户界面
指标数据共享的便利性：指标状态和仪表板
指标访问权限不是特定于 RabbitMQ 的
节点特定指标的收集和聚合，这使得监控系统更能抵御单个节点故障

如何启用它

要启用 Prometheus 插件，请使用

rabbitmq-plugins enable rabbitmq_prometheus

或预配置插件。

HTTP API 端点

该插件默认在端口 15692 上为兼容 Prometheus 的抓取器提供服务

curl {hostname}:15692/metrics

请参阅 Prometheus 插件指南以了解更多信息。

使用管理插件进行监控

内置的管理插件也可以收集指标并在 UI 中显示它们。这对于开发环境来说是一个便捷的选项。

该插件还可以为监控工具提供指标。但是，与使用 Prometheus 进行监控相比，它有一些明显的局限性

监控系统与被监控系统交织在一起
使用管理插件进行监控往往会产生更多的开销，尤其是在节点 RAM 使用方面
它仅存储最近的数据（考虑小时，而不是天或月）
它只有一个基本的用户界面
其设计强调易用性而非最佳可用性。
管理 UI 访问通过 RabbitMQ 权限标签系统（或 JWT 令牌范围的约定）进行控制

如何启用它

要启用管理插件，请使用

rabbitmq-plugins enable rabbitmq_management

或预配置插件。

HTTP API 端点

该插件默认在端口 15672 上通过 HTTP API 提供指标，并使用基本 HTTP 身份验证

curl -u {username}:{password} {hostname}:15672/api/overview

请参阅管理插件指南以了解更多信息。

监控 Kubernetes Operator 部署的集群

使用 RabbitMQ Kubernetes Operator 部署到 Kubernetes 的 RabbitMQ 集群可以使用 Prometheus 或兼容工具进行监控。

这在专门的指南在 Kubernetes 中监控 RabbitMQ 中有介绍。

基于交互式命令行的观察工具

rabbitmq-diagnostics observer 是一个类似于 top、htop、vmstat 的命令行工具。它是 Erlang 的 Observer 应用程序的命令行替代方案。它提供了许多指标的访问权限，包括各个运行时进程的详细状态

运行时版本信息
CPU 和调度统计信息
内存分配和使用情况统计信息
按 CPU（减少次数）和内存使用情况排序的前置进程
网络链路统计信息
详细的进程信息，例如基本的 TCP 套接字统计信息

以及更多，在一个带有定期更新的交互式 ncurses 类似的命令行界面中。

以下是一些屏幕截图，演示了该工具提供的哪些信息。

包含关键运行时指标的概述页面

内存分配器统计信息

客户端连接进程指标

监控的资源使用和开销

监控可能会对被监控的系统造成干扰并增加其负载。这取决于被监控集群中实体（连接、队列等）的数量，但也取决于其他因素：监控频率、监控工具请求的数据量等等。

许多监控系统会定期轮询其监控的服务。轮询的频率因工具而异，但通常可以由操作员配置。

过于频繁的轮询可能会对被监控的系统产生负面影响。例如，过度的负载均衡器检查会打开到节点的测试 TCP 连接，这可能导致连接震荡过高。对 RabbitMQ 中通道和队列的过度检查会增加其 CPU 消耗。当节点上有许多（例如，数万个）此类检查时，差异可能会很大。

监控工具的另一个常见问题是它们从 RabbitMQ 节点请求的数据量。某些监控工具会查询整个页面或所有队列，仅仅是为了获取一个队列的单个指标值。这会显著增加监控的 CPU 负载占用。

可以使用 rabbitmq_top 插件或 rabbitmq-diagnostics observer 识别此类情况。按减少次数（运行时调度程序时间的单位）排序的前置进程通常是以下进程之一

rabbit_mgmt_db_cache_connections
rabbit_mgmt_external_stats
queue_metrics_metrics_collector
以及其他名称以 _metrics_collector 结尾的进程

要减少监控的占用，请降低监控频率并确保监控工具仅查询其所需的数据。

监控频率

生产环境中推荐的指标收集间隔为 **30 秒**，或 30 到 60 秒范围内的其他合适值。Prometheus 导出程序 API 旨在每 15 到 30 秒抓取一次，包括生产系统。

在开发环境中，为了以更接近实时的间隔收集，请使用 5 秒——但不要低于此值！

对于速率指标，请使用跨越四个或更多指标收集间隔的时间范围，以便它能够容忍竞争条件并能够抵御抓取失败。

RabbitMQ 指标

本节将介绍监控的多个 RabbitMQ 特定方面。本节中提到的大多数指标都由 Prometheus 插件和管理 UI 公开。

集群范围内的指标

集群范围内的指标提供了集群状态的高级视图。其中一些描述了节点之间的交互。此类指标的示例包括集群链路流量和检测到的网络分区。其他指标则组合了所有集群成员的指标。所有节点的完整连接列表就是一个例子。这两种类型都与基础设施和节点指标相辅相成。

GET /api/overview 是返回集群范围内的指标的 HTTP API 端点。

指标	JSON 字段名称
集群名称	`cluster_name`
集群范围内的消息速率	`message_stats`
连接总数	`object_totals.connections`
通道总数	`object_totals.channels`
队列总数	`object_totals.queues`
消费者总数	`object_totals.consumers`
消息总数（已准备好和未确认的消息）	`queue_totals.messages`
已准备好投递的消息数	`queue_totals.messages_ready`
未确认消息数	`queue_totals.messages_unacknowledged`
最近发布的消息	`message_stats.publish`
消息发布速率	`message_stats.publish_details.rate`
最近投递给消费者的消息	`message_stats.deliver_get`
消息投递速率	`message_stats.deliver_get_details.rate`
其他消息统计信息	`message_stats.*`（请参阅 HTTP API 参考）

节点指标

有两个 HTTP API 端点可用于访问节点特定的指标

GET /api/nodes/{node} 返回单个节点的统计信息
GET /api/nodes 返回所有集群成员的统计信息

后一个端点返回一个对象数组。支持（或可以支持）将其作为输入的监控工具应该优先使用该端点，因为它可以减少请求数量。在不满足此条件的情况下，请使用前一个端点依次检索每个集群成员的统计信息。这意味着监控系统知道集群成员列表。

大多数指标表示时间点的绝对值。有些指标表示最近一段时间内的活动（例如，GC 运行和回收的字节）。当与这些指标的先前值以及历史平均值/百分位数值进行比较时，后者指标最有用。

指标	JSON 字段名称
使用的内存总量	`mem_used`
内存使用高水位线	`mem_limit`
是否启用了内存警报？	`mem_alarm`
剩余磁盘空间低水位线	`disk_free_limit`
是否启用了磁盘警报？	`disk_free_alarm`
可用的文件描述符	`fd_total`
已使用的文件描述符	`fd_used`
文件描述符打开尝试次数	`io_file_handle_open_attempt_count`
可用的套接字	`sockets_total`
已使用的套接字	`sockets_used`
节点间通信链路	cluster_links
GC 运行次数	`gc_num`
GC 回收的字节数	`gc_bytes_reclaimed`
Erlang 进程限制	`proc_total`
已使用的 Erlang 进程	`proc_used`
运行时运行队列	`run_queue`

各个队列指标

各个队列指标可通过 HTTP API 通过 GET /api/queues/{vhost}/{qname} 端点获取。

下表列出了一些可用于监控队列状态的关键指标。其他一些指标（例如队列状态和“空闲时间段”）应被视为 RabbitMQ 贡献者使用的 **内部指标**。

指标	JSON 字段名称
内存	`memory`
消息总数（已准备好和未确认的消息）	`messages`
已准备好投递的消息数	`messages_ready`
未确认消息数	`messages_unacknowledged`
最近发布的消息	`message_stats.publish`
消息发布速率	`message_stats.publish_details.rate`
最近投递的消息	`message_stats.deliver_get`
消息投递速率	`message_stats.deliver_get_details.rate`
其他消息统计信息	`message_stats.*`（请参阅 HTTP API 参考）

应用程序级指标

使用消息传递的系统几乎总是分布式的。在这样的系统中，通常无法立即清楚哪个组件行为异常。系统的每个部分，包括应用程序，都应进行监控和调查。

一些基础设施级和 RabbitMQ 指标可以显示异常系统行为或问题的存在，但无法查明根本原因。例如，很容易看出节点是否即将耗尽磁盘空间，但并不总是容易看出原因。这就是应用程序指标的作用：它们可以帮助识别失控的发布者、重复失败的消费者、无法跟上速率的消费者，甚至正在经历速度下降的下游服务（例如，消费者使用的数据库中缺少索引）。

一些客户端库和框架提供了注册指标收集器或开箱即用地收集指标的方法。RabbitMQ Java 客户端、Spring AMQP 和 NServiceBus 就是一些示例。对于其他情况，开发人员必须在其应用程序代码中跟踪指标。

应用程序跟踪哪些指标可能因系统而异，但有些指标与大多数系统相关

连接打开速率
通道打开速率
连接故障（恢复）速率
发布速率
投递速率
正向投递确认速率
负向投递确认速率
平均/第 95 百分位投递处理延迟

运行状况检查

运行状况检查是一个命令，用于测试 RabbitMQ 服务的某个方面是否按预期运行。运行状况检查由机器定期执行或由操作员交互式执行。

运行状况检查既可以用于评估节点的状态和活性，也可以用作部署自动化和编排工具（包括在升级期间）的就绪探测。

可以执行一系列运行状况检查，从最基本且很少产生误报的检查开始，到越来越全面、侵入性和主观的检查，这些检查产生误报的可能性更高。换句话说，运行状况检查越全面，结果就越不确定。

运行状况检查可以验证单个节点（节点运行状况检查）或整个集群（集群运行状况检查）的状态。

单个节点检查

本节介绍了几个节点运行状况检查的示例。它们按阶段组织。较高级别阶段执行更全面和主观的检查。此类检查产生误报的可能性更高。某些阶段有专用的 RabbitMQ CLI 工具命令，其他阶段可能涉及其他工具。

虽然健康检查是有序的，但数量越多并不意味着检查就“更好”。

健康检查可以被选择性地使用和组合。除非另有说明，否则检查应遵循与指标收集相同的监控频率建议。

早期版本的 RabbitMQ 使用了一种侵入式健康检查，该检查现已弃用，应避免使用。请使用本节中介绍的其中一项检查（或其组合）。

阶段 1

最基本的检查确保运行时正在运行，并且（间接地）CLI 工具可以与其进行身份验证。

除了 CLI 工具身份验证部分外，误报的概率可以认为接近0，除了升级和维护窗口外。

rabbitmq-diagnostics ping执行此检查

rabbitmq-diagnostics -q ping
# => Ping succeeded if exit code is 0

阶段 2

稍微更全面的检查是执行rabbitmq-diagnostics status状态

这包括阶段 1 检查，并检索一些基本系统信息，这些信息对其他检查很有用，并且如果 RabbitMQ 在节点上运行，则应始终可用（见下文）。

rabbitmq-diagnostics -q status
# => [output elided for brevity]

这是检查节点可靠性的常用方法。误报的概率可以认为接近0，除了升级和维护窗口外。

阶段 3

包括之前的检查，还验证 RabbitMQ 应用程序是否正在运行（未通过rabbitmqctl stop_app或暂停少数派分区处理策略停止）并且没有资源警报。

# lists alarms in effect across the cluster, if any
rabbitmq-diagnostics -q alarms

rabbitmq-diagnostics check_running是一项检查，确保运行时正在运行，并且其上的 RabbitMQ 应用程序未停止或暂停。

rabbitmq-diagnostics check_local_alarms检查节点上是否启用了任何本地警报。如果存在任何警报，它将以非零状态退出。

这两个命令组合在一起执行阶段 3 检查

rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms
# if both checks succeed, the exit code will be 0

误报的概率很低。在接近其高运行时内存水位线的系统中，误报的概率很高。在升级和维护窗口期间，误报概率可能会显着提高。

特别是对于内存警报，GET /api/nodes/{node}/memory HTTP API 端点可用于其他检查。在以下示例中，其输出被传递给jq

curl --silent -u guest:guest -X GET http://127.0.0.1:15672/api/nodes/rabbit@hostname/memory | jq
# => {
# =>     "memory": {
# =>         "connection_readers": 24100480,
# =>         "connection_writers": 1452000,
# =>         "connection_channels": 3924000,
# =>         "connection_other": 79830276,
# =>         "queue_procs": 17642024,
# =>         "plugins": 63119396,
# =>         "other_proc": 18043684,
# =>         "metrics": 7272108,
# =>         "mgmt_db": 21422904,
# =>         "mnesia": 1650072,
# =>         "other_ets": 5368160,
# =>         "binary": 4933624,
# =>         "msg_index": 31632,
# =>         "code": 24006696,
# =>         "atom": 1172689,
# =>         "other_system": 26788975,
# =>         "allocated_unused": 82315584,
# =>         "reserved_unallocated": 0,
# =>         "strategy": "rss",
# =>         "total": {
# =>             "erlang": 300758720,
# =>             "rss": 342409216,
# =>             "allocated": 383074304
# =>         }
# =>     }
# => }

它生成的细分信息可以使用jq或类似工具简化为单个值

curl --silent -u guest:guest -X GET http://127.0.0.1:15672/api/nodes/rabbit@hostname/memory | jq ".memory.total.allocated"
# => 397365248

rabbitmq-diagnostics -q memory_breakdown提供了对相同按类别数据的访问，并支持各种单位

rabbitmq-diagnostics -q memory_breakdown --unit "MB"
# => connection_other: 50.18 mb (22.1%)
# => allocated_unused: 43.7058 mb (19.25%)
# => other_proc: 26.1082 mb (11.5%)
# => other_system: 26.0714 mb (11.48%)
# => connection_readers: 22.34 mb (9.84%)
# => code: 20.4311 mb (9.0%)
# => queue_procs: 17.687 mb (7.79%)
# => other_ets: 4.3429 mb (1.91%)
# => connection_writers: 4.068 mb (1.79%)
# => connection_channels: 4.012 mb (1.77%)
# => metrics: 3.3802 mb (1.49%)
# => binary: 1.992 mb (0.88%)
# => mnesia: 1.6292 mb (0.72%)
# => atom: 1.0826 mb (0.48%)
# => msg_index: 0.0317 mb (0.01%)
# => plugins: 0.0119 mb (0.01%)
# => mgmt_db: 0.0 mb (0.0%)
# => reserved_unallocated: 0.0 mb (0.0%)

阶段 4

包括阶段 3 中的所有检查，以及对所有启用的侦听器（使用临时 TCP 连接）的检查。

要检查在节点上启用的所有侦听器，请使用rabbitmq-diagnostics listeners

rabbitmq-diagnostics -q listeners --node rabbit@target-hostname
# => Interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
# => Interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
# => Interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
# => Interface: [::], port: 15672, protocol: http, purpose: HTTP API
# => Interface: [::], port: 15671, protocol: https, purpose: HTTP API over TLS (HTTPS)

rabbitmq-diagnostics check_port_connectivity [--address <address>]是一个执行上述基本 TCP 连接检查的命令

# This check will try to open a TCP connection to the discovered listener ports.
# Since nodes can be configured to listen to specific interfaces, an --address should
# be provided, or CLI tools will have to rely on the configured hostname resolver to know where to connect.
rabbitmq-diagnostics -q check_port_connectivity --node rabbit@target-hostname --address <ip-address-to-connect-to>
# If the check succeeds, the exit code will be 0

误报的概率通常很低，但在升级和维护窗口期间可能会显着提高。

阶段 5

包括阶段 4 中的所有检查，以及检查是否存在任何失败的虚拟主机。

rabbitmq-diagnostics check_virtual_hosts是一个命令，检查任何虚拟主机依赖项是否可能失败。这将对所有虚拟主机执行。

rabbitmq-diagnostics -q check_virtual_hosts --node rabbit@target-hostname
# if the check succeeded, exit code will be 0

误报的概率通常很低，除非系统处于高 CPU 负载下。

健康检查作为就绪探测

在某些环境中，节点重启由指定的健康检查控制。这些检查验证一个节点是否已启动，并且部署过程可以继续进行到下一个节点。如果检查未通过，则节点的部署被认为是不完整的，部署过程通常会等待一段时间并重试。此类环境的一个常见示例是 Kubernetes，其中操作员定义的就绪探测可以阻止部署在OrderedReady pod 管理策略使用时继续进行（不建议与 RabbitMQ 一起使用！）或执行滚动重启时。

鉴于节点重启期间的节点同步行为，此类健康检查可能会阻止集群范围内的重启及时完成。明确或隐式地假设已完全启动且已重新加入其集群对等节点的节点的检查将失败并阻止进一步的节点部署。

此外，大多数 CLI 命令（例如rabbitmq-diagnostics）都会对性能产生影响，因为 CLI 会加入Erlang 分布（用于集群 RabbitMQ 节点的相同机制）。在每次探测执行时加入和离开此集群会产生不必要的开销。

RabbitMQ Kubernetes 运算符将 AMQP 端口上的 TCP 端口检查配置为readinessProbe，并且根本不定义livenessProbe。这应被视为最佳实践。

集群监控

监控单个节点既简单又直接。

在监控集群时，了解所用 API 端点提供的保证非常重要。在集群环境中，每个节点都可以服务指标端点请求。此外，某些指标是特定于节点的，而其他指标是集群范围的。

每个节点都提供对特定于节点的指标的访问。与基础设施和操作系统指标一样，必须为每个集群节点收集特定于节点的指标。

Prometheus 和管理插件 API 端点在它们提供的指标以及如何聚合集群范围的指标方面存在重要差异。

Prometheus

使用 Prometheus 插件，每个节点都提供对特定于节点的指标的访问。Prometheus 查询指标端点{hostname}:15692/metrics并存储结果。然后根据这些特定于节点的数据计算集群范围的指标。

管理插件

使用管理插件，每个节点都提供对自身以及其他集群节点的特定于节点的指标的访问。

可以从任何可以联系其对等节点的节点获取集群范围的指标。该节点将在生成响应之前根据需要收集并组合来自其对等节点的数据。

使用管理插件，节点间连接问题将影响 HTTP API 行为。为监控请求选择一个随机的在线节点。例如，使用负载均衡器或循环 DNS。

已弃用的健康检查和监控功能

旧版侵入式健康检查

早期版本的 RabbitMQ 提供了一个单一的、武断的、侵入式的健康检查命令（及其相应的 HTTP API 端点）

# DO NOT USE: this health check is very intrusive, resource-intensive, prone to false positives
#             and as such, deprecated
rabbitmq-diagnostics node_health_check

上述命令已弃用，将在 RabbitMQ 的未来版本中删除，应避免使用。使用它的系统应改为采用细粒度的现代健康检查之一。

上述检查强制系统中的每个连接、队列领导者副本和通道发出某些指标。在大量并发连接和队列的情况下，这可能非常占用资源，并且很容易产生误报。

上述检查也不适合用作就绪探测，因为它隐式地假设了一个已完全启动的节点。

监控工具

以下是通常用于收集 RabbitMQ 指标的第三方工具的按字母顺序排列的列表。这些工具的功能各不相同，但通常可以收集基础设施级别和RabbitMQ 指标。

请注意，此列表绝非完整列表。

监控工具	在线资源
AppDynamics	AppDynamics，GitHub
AWS CloudWatch	GitHub
collectd	GitHub
DataDog	DataDog RabbitMQ 集成，GitHub
Dynatrace	Dynatrace RabbitMQ 监控
Ganglia	GitHub
Graphite	与 Graphite 协同工作的工具
Munin	Munin 文档，GitHub
Nagios	GitHub
Nastel AutoPilot	Nastel RabbitMQ 解决方案
New Relic	New Relic RabbitMQ 监控
Prometheus	Prometheus 指南，GitHub
Sematext	Sematext RabbitMQ 监控集成，Sematext RabbitMQ 日志集成
Zabbix	通过 HTTP 的 Zabbix，通过 Agent 的 Zabbix，博文
Zenoss	RabbitMQ ZenPack，教学视频

日志聚合

日志在对分布式系统进行故障排除时也非常重要。与指标一样，日志可以提供重要的线索，帮助识别根本原因。收集所有 RabbitMQ 节点以及所有应用程序（如果可能）的日志。

概述​

什么是监控？​

健康检查在监控中的作用​

系统和 RabbitMQ 指标​

基础设施和内核指标​

使用兼容 Prometheus 的工具进行监控​

如何启用它​

HTTP API 端点​

使用管理插件进行监控​

如何启用它​

HTTP API 端点​

监控 Kubernetes Operator 部署的集群​

基于交互式命令行的观察工具​

监控的资源使用和开销​

监控频率​

RabbitMQ 指标​

集群范围内的指标​

节点指标​

各个队列指标​

应用程序级指标​

运行状况检查​

单个节点检查​

阶段 1​

阶段 2​

阶段 3​

阶段 4​

阶段 5​

健康检查作为就绪探测​

集群监控​

Prometheus​

管理插件​

已弃用的健康检查和监控功能​

旧版侵入式健康检查​

监控工具​

日志聚合​

概述

什么是监控？

健康检查在监控中的作用

系统和 RabbitMQ 指标

基础设施和内核指标

使用兼容 Prometheus 的工具进行监控

如何启用它

HTTP API 端点

使用管理插件进行监控

如何启用它

HTTP API 端点

监控 Kubernetes Operator 部署的集群

基于交互式命令行的观察工具

监控的资源使用和开销

监控频率

RabbitMQ 指标

集群范围内的指标

节点指标

各个队列指标

应用程序级指标

运行状况检查

单个节点检查

阶段 1

阶段 2

阶段 3

阶段 4

阶段 5

健康检查作为就绪探测

集群监控

Prometheus

管理插件

已弃用的健康检查和监控功能

旧版侵入式健康检查

监控工具

日志聚合