版本：4.3

监控

概述

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

Prometheus 和 Grafana 的组合是 RabbitMQ 监控强烈推荐的方案。

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

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

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

什么是监控？

在本指南中，我们将监控定义为一个通过健康检查和指标来持续捕获系统行为的过程。这有助于检测异常：例如当系统不可用、经历异常负载、耗尽某些资源或表现不符合正常（预期）参数时。监控涉及长期收集和存储指标，这对异常检测以及根本原因分析、趋势检测和容量规划都很重要。

监控系统通常会与告警系统集成。当监控系统检测到异常时，通常会向告警系统发送某种形式的警报，该系统会通知相关人员，例如技术运营团队。

实施监控意味着更容易检测到系统行为的重大偏差（从局部服务降级到完全不可用），并且排查根本原因所需的时间会大大缩短。在没有监控数据的情况下运行分布式系统，就像在没有 GPS 导航仪或指南针的情况下试图走出森林。无论个人多么出色或经验丰富，拥有相关信息对于获得良好的结果都非常重要。

健康检查在监控中的作用

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

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

当然，还有多种健康检查方式。哪种方式最合适取决于所定义的“健康节点”。因此，这是一个特定于系统和团队的决策。RabbitMQ CLI 工具提供了可用作有用健康检查的命令。这些内容将在本指南稍后部分介绍。

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

系统和 RabbitMQ 指标

有些指标是 RabbitMQ 特有的：它们由 RabbitMQ 节点收集并报告。在本指南中，我们将其称为“RabbitMQ 指标”。示例包括已使用的套接字描述符数量、入队消息总数或节点间通信流量速率。其他指标由 OS 内核收集并报告。此类指标通常被称为系统指标或基础设施指标。系统指标并非 RabbitMQ 所特有。示例包括 CPU 利用率、进程使用的内存量、网络丢包率等。这两类指标都非常重要。单独的指标并不总是有用，但当综合分析时，它们可以提供对系统状态更完整的洞察。这样，操作人员就可以针对正在发生且需要解决的问题形成假设。

基础设施和内核指标

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

CPU 统计信息（用户态、系统态、iowait、空闲百分比）
内存使用情况（已使用、缓冲区、缓存和剩余百分比）
内核页缓存，特别是在使用流 (streams) 的集群中
虚拟内存统计信息（脏页刷新、回写量）
磁盘 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 堆栈相比其他监控选项具有许多优势：

监控系统与被监控系统解耦
更低的开销
长期的指标存储
访问额外的相关指标，例如运行时 (runtime) 的指标
更强大且可自定义的用户界面
易于共享指标数据：包括指标状态和仪表板
指标访问权限不绑定于 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 端点

该插件默认通过 HTTP API 在端口 15672 上提供指标，并使用 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 应用的命令行替代方案。它提供对许多指标的访问，包括单个运行时 (runtime) 进程的详细状态：

运行时版本信息
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`
节点间通信链路	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_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 服务某个方面是否按预期运行的命令。健康检查由机器定期执行或由操作员交互式执行。

健康检查既可用于评估节点的状态和存活度，也可由部署自动化和编排工具用作就绪探针（包括在升级期间）。

可以执行一系列健康检查，从最基本且极少产生误报 (false positives) 的检查，到越来越全面、具有侵入性和主观性的检查（这些检查产生误报的概率更高）。换句话说，健康检查越全面，结果就越不确定。

健康检查可以验证单个节点的状态（节点健康检查），或者验证整个集群（集群健康检查）。

单个节点检查

本节涵盖了几个节点健康检查的例子。它们按阶段组织。高级阶段执行更全面和主观的检查。此类检查产生误报的概率更高。有些阶段有专门的 RabbitMQ CLI 工具命令，有些则可能涉及额外的工具。

虽然健康检查是有顺序的，但数字较高并不意味着检查一定“更好”。

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

早期版本的 RabbitMQ 使用了一种侵入性健康检查，现已被弃用，应避免使用。请使用本节介绍的检查方法（或它们的组合）。

阶段 1

最基本的检查确保运行时 (runtime) 正在运行，并且（间接）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，其中操作员定义的就绪探针 (readiness probe) 可以防止部署在使用了 OrderedReady Pod 管理策略（不建议与 RabbitMQ 一起使用！）时继续进行，或者在执行滚动重启时阻止部署。

鉴于节点重启期间的对等同步行为，这样的健康检查可能会导致集群范围的重启无法及时完成。那些明确或隐含地假设节点完全启动并重新加入集群对等体的检查将会失败，并阻塞后续的节点部署。

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

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

集群监控

监控单个节点既容易又直观。

监控集群时，了解所使用 API 端点提供的保证很重要。在集群环境中，每个节点都可以处理指标端点请求。此外，有些指标是节点特定的，而另一些是集群范围的。

每个节点都提供对其自身节点特定指标的访问。与基础设施和 OS 指标一样，必须为每个集群节点收集节点特定指标。

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

Prometheus

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

管理插件

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

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

使用管理插件时，节点间连接问题将影响 HTTP API 的行为。为监控请求选择一个随机的在线节点。例如，使用负载均衡器或轮询 DNS (round-robin 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 的 未来版本中移除，应避免使用。使用它的系统应改为采用细粒度的现代健康检查之一。

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

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

监控工具

以下是按字母顺序排列的第三方工具列表，通常用于收集 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

管理插件

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

传统的侵入性健康检查

监控工具

日志聚合