版本: 4.1

监控

概述

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

Prometheus 和 Grafana 的组合是 RabbitMQ 监控的高度推荐选项。

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

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

许多流行的工具，包括开源和商业工具，都可以用于监控 RabbitMQ。如上所述，Prometheus 和 Grafana 的组合是 RabbitMQ 团队会向大多数用户推荐的。在 Kubernetes 上，Kubernetes RabbitMQ Operator 会自动启用 Prometheus 插件。

什么是监控？

在本指南中，我们将监控定义为通过健康检查和指标随时间推移捕获系统行为的过程。这有助于检测异常情况：系统不可用、遇到异常负载、资源耗尽或行为不符合其正常（预期）参数。监控包括长期收集和存储指标，这对于异常检测以及根本原因分析、趋势检测和容量规划非常重要。

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

拥有监控意味着可以更容易地检测到系统行为的重要偏差，从某些区域的服务降级到完全不可用，并且可以大大缩短查找根本原因的时间。在没有监控数据的情况下运行分布式系统有点像在没有 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的专门指南中介绍。

交互式命令行 Observer 工具

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

运行时版本信息
CPU 和调度统计信息
内存分配和使用统计信息
按 CPU（规约）和内存使用量排名的前几个进程
网络链路统计信息
详细的进程信息，例如基本 TCP 套接字统计信息

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

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

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

内存分配器统计信息

客户端连接进程指标

监控的资源使用和开销

监控可能会具有侵入性，并增加被监控系统的负载。这取决于被监控集群中有多少实体（连接、队列等），还取决于其他因素：监控频率、监控工具请求多少数据等等。

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

过于频繁的轮询可能会对被监控的系统产生负面影响。例如，过多的负载均衡器检查（打开到节点的测试 TCP 连接）可能会导致高连接 churn。对 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`
节点间通信链路	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 是这种环境的一个流行示例，在 Kubernetes 中，当使用就绪探针时，operator 定义的 OrderedReady pod 管理策略（不建议与 RabbitMQ 一起使用！）或执行滚动重启时，可以阻止部署继续进行。

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

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

RabbitMQ Kubernetes Operator 将 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 long deprecated and in modern versions it is a no-op
rabbitmq-diagnostics node_health_check

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

上述检查强制系统中的每个连接、队列 leader 副本和通道发出某些指标。对于大量的并发连接和队列，这可能会非常消耗资源，并且很可能产生误报。

上述检查也不适合用作就绪探针，因为它隐含地假设节点已完全启动。

监控工具

以下是常用第三方工具的字母顺序列表，这些工具用于收集 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	Zabbix 通过 HTTP, Zabbix 通过 Agent, 博客文章
Zenoss	RabbitMQ ZenPack, 教学视频

日志聚合

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

概述​

什么是监控？​

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

系统和 RabbitMQ 指标​

基础设施和内核指标​

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

如何启用它​

HTTP API 端点​

使用管理插件进行监控​

如何启用它​

HTTP API 端点​

监控 Kubernetes Operator 部署的集群​

交互式命令行 Observer 工具​

监控的资源使用和开销​

监控频率​

RabbitMQ 指标​

集群范围指标​

节点指标​

单个队列指标​

应用程序级别指标​

健康检查​

单个节点检查​

阶段 1​

阶段 2​

阶段 3​

阶段 4​

阶段 5​

健康检查作为就绪探针​

集群监控​

Prometheus​

管理插件​

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

旧版侵入式健康检查​

监控工具​

日志聚合​

概述

什么是监控？

健康检查在监控中的作用

系统和 RabbitMQ 指标

基础设施和内核指标

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

如何启用它

HTTP API 端点

使用管理插件进行监控

如何启用它

HTTP API 端点

监控 Kubernetes Operator 部署的集群

交互式命令行 Observer 工具

监控的资源使用和开销

监控频率

RabbitMQ 指标

集群范围指标

节点指标

单个队列指标

应用程序级别指标

健康检查

单个节点检查

阶段 1

阶段 2

阶段 3

阶段 4

阶段 5

健康检查作为就绪探针

集群监控

Prometheus

管理插件

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

旧版侵入式健康检查

监控工具

日志聚合