如何使用 rabbitmqctl 监控 RabbitMQ 节点状态和连接

RabbitMQ 通常只有在队列积压、消费者停止确认消息或部署创建了数百个额外连接时才会受到关注。rabbitmqctl 仍然是快速查看代理从节点内部看到的内容的最快方法之一。它不会取代 Prometheus、管理 UI 或日志审查，但当您在服务器上需要快速答案时，它提供了一个可靠的命令行视图。

理解 rabbitmqctl

rabbitmqctl 脚本是与 RabbitMQ 节点交互的主要命令行界面。它允许管理员执行各种任务，从启动和停止代理到管理用户、权限、交换器、队列，以及本文重点关注的监控节点运行状态和网络活动。

检查 RabbitMQ 节点状态

在深入连接之前，验证 RabbitMQ 节点是否正常运行至关重要。status 命令提供了节点当前状态的全面概览。

rabbitmqctl status 命令

此命令输出大量信息，包括：

• 节点名称：RabbitMQ 节点的名称。
• 运行中的应用程序：列出正在运行的 Erlang 应用程序，其中 RabbitMQ 本身是一个关键指标。
• 内存使用情况：内存分配和使用的详细信息，对性能调优至关重要。
• 磁盘空间：可用磁盘空间的信息，可能影响消息持久化。
• 文件描述符：打开的文件描述符数量，这是一个重要的系统资源。
• 网络信息：网络接口和端口的详细信息。
• 集群状态：节点是否属于集群及其连接性的信息。
• 监听器：RabbitMQ 监听各种协议（AMQP、管理 UI 等）的端口。

使用示例：

rabbitmqctl status

解读输出： 查找资源耗尽的迹象（高内存、低磁盘空间、高文件描述符使用率），并确认 rabbit 等关键应用程序正在运行。listeners 部分对于确保 RabbitMQ 在预期端口上可访问至关重要。

监控连接、通道和消费者

了解客户端如何与 RabbitMQ 节点交互是故障排除和性能分析的关键。rabbitmqctl 提供了列出和检查这些实体的命令。

列出连接 (rabbitmqctl list_connections)

此命令显示所有与 RabbitMQ 节点的活动客户端连接。每个连接代表一个已成功连接的客户端应用程序（生产者或消费者）。

命令：

rabbitmqctl list_connections

输出列（常见）：

• pid：连接的 Erlang 进程标识符。
• node：连接建立的节点。
• name：连接的名称（通常反映客户端属性）。
• port：客户端连接的端口。
• host：客户端连接的主机。
• user：用于认证的用户名。
• vhost：连接关联的虚拟主机。
• ssl：指示连接是否使用 SSL/TLS。
• protocol：使用的协议（例如 amqp0-9-1）。

示例：

rabbitmqctl list_connections name host port user vhost protocol

这允许您查看哪些用户已连接、从何处连接以及他们正在使用哪些虚拟主机。

列出通道 (rabbitmqctl list_channels)

每个连接可以有多个通道。通道是单个 TCP 连接上的轻量级多路复用连接，用于 AMQP 操作。

命令：

rabbitmqctl list_channels

输出列（常见）：

• connection：父连接的 pid。
• node：通道所在的节点。
• channel_pid：通道的 Erlang 进程标识符。
• vhost：通道关联的虚拟主机。
• name：通道的名称（如果由客户端设置）。
• consumer_count：此通道上活动的消费者数量。
• messages_unacknowledged：此通道上未确认的消息数量。
• messages_ready：此通道上准备投递的消息数量。

示例：

rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged

监控 messages_unacknowledged 和 messages_ready 对于识别消费者可能难以跟上的潜在瓶颈至关重要。

列出消费者 (rabbitmqctl list_consumers)

消费者是订阅队列以接收和处理消息的进程。

命令：

rabbitmqctl list_consumers

输出列（常见）：

• vhost：消费者所在的虚拟主机。
• queue：消费者附加到的队列名称。
• consumer_tag：消费者的唯一标识符（由客户端设置）。
• delivery_tag：当前正在处理的消息的投递标签。
• redelivered：消息是否已重新投递。
• message_count：等待投递给此消费者的消息数量。
• ack_required：指示投递给此消费者的消息是否需要确认。

示例：

rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required

此命令帮助您了解哪些队列有活动消费者、有多少消息等待投递给他们，以及确认是否配置正确。

检查特定组件（可选参数）

大多数 list_* 命令接受参数来指定要显示的字段，使输出更易于管理。您还可以使用标准 shell 实用程序（如 grep 和 sort）过滤和排序输出。

示例：查找来自特定用户的连接：

rabbitmqctl list_connections | grep 'my_user'

示例：仅显示具有未确认消息的队列：

rabbitmqctl list_channels | awk '$4 > 0 { print }'

监控最佳实践

• 定期检查：实施对 rabbitmqctl status 的定期检查，以在潜在问题影响生产之前发现它们。
• 自动化：考虑使用脚本自动化这些检查，并将其集成到监控系统（例如 Prometheus、Nagios）中以进行主动警报。
• 上下文是关键：了解您环境的典型值。未确认消息的突然激增或新的意外连接值得调查。
• 与管理 UI 结合：虽然 rabbitmqctl 对于脚本编写和直接访问非常强大，但 RabbitMQ 管理 UI 提供了可视化和交互式的方式来监控相同的信息。
• 资源监控：始终将 rabbitmqctl 输出与系统级资源监控（CPU、RAM、磁盘 I/O）相关联，以获得完整的图景。

队列积压时的有用分类流程

当队列开始增长时，不要立即重启 RabbitMQ。重启可能会使恢复变慢，并可能隐藏您需要的证据。从回答四个问题开始。

首先，节点是否健康到足以服务客户端？

rabbitmqctl status

查看内存警报、磁盘警报、文件描述符使用情况和监听器。RabbitMQ 具有内存和磁盘可用空间安全机制。如果节点进入警报状态，发布者可能会被阻止。从外部看，这看起来可能像应用程序问题，即使代理正在保护自己。

其次，消费者是否已连接？

rabbitmqctl list_consumers vhost queue consumer_tag ack_required active

如果队列没有消费者，则队列深度不是 RabbitMQ 性能问题。应该消费队列的应用程序已关闭、配置错误、连接到错误的虚拟主机，或者消费的队列名称与发布者使用的不同。

第三，消费者是否正在接收消息但不确认它们？

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

messages_ready 表示消息正在队列中等待。messages_unacknowledged 表示消息已投递给消费者但尚未确认。高未确认计数通常指向慢速处理程序、消费者内部的长数据库调用、过高的预取值或消费者在接收消息后崩溃。

第四，连接或通道是否过多？

rabbitmqctl list_connections name user host state channels send_pend recv_cnt send_cnt
rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

健康的客户端通常会重用连接并打开可控数量的通道。如果每个请求都打开一个新连接，代理可能会在连接周转上花费大量时间。如果单个连接有大量通道，请检查客户端库行为和部署规模。

解读连接状态

当您请求特定列时，list_connections 更有用。在事件期间，紧凑的命令更容易扫描：

rabbitmqctl list_connections name user host state channels protocol ssl

state 列有助于将正常流量与可疑行为分开。处于 running 状态的连接是活动的。大量连接卡在流控制或阻塞状态值得关注。如果您期望 TLS 但 ssl 为 false，则客户端可能使用了错误的监听器或旧配置。

在应用程序代码中设置客户端名称也很有价值。许多 RabbitMQ 客户端库允许您设置连接名称。如果没有，您可能只能看到主机和端口详细信息，这使得更难识别导致负载的服务。像 billing-worker-prod-3 这样的名称比匿名 TCP 连接有用得多。

通道和预取问题

与 TCP 连接相比，通道成本较低，但它们不是免费的。一个常见的生产问题是工作进程创建通道但从不关闭它们。另一个是预取值高的消费者接收许多消息，处理缓慢，并使其他消费者空闲。

使用：

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

如果一个通道有大量的 messages_unacknowledged 计数，请检查该消费者。也许它正在执行缓慢的 HTTP 调用、等待数据库锁，或者一次处理一条消息，而预取允许它保留更多消息。降低预取可以提高公平性，但它不是神奇的性能修复。如果处理程序很慢，您仍然需要修复处理程序。

与连接检查并列的队列检查

尽管本文重点介绍节点状态和连接，但队列状态完善了图景：

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

具有持久消息的持久队列可能会给磁盘带来压力。consumers 设置为 0 的队列需要应用程序检查。具有许多就绪消息和活动消费者的队列指向吞吐量不匹配。具有许多未确认消息的队列指向消费者端处理或确认行为。

当您使用 shell 过滤器时，请注意列位置。如果您更改了请求的字段，旧的 awk 片段可能会静默地过滤错误的列。对于可重复的检查，最好使用请求固定字段并标记其输出的脚本。

集群说明

在集群中，针对您关心的节点运行命令，或在支持的地方指定节点：

rabbitmqctl -n rabbit@node1 status

检查集群成员和分区：

rabbitmqctl cluster_status

网络分区和节点分歧可能会产生令人困惑的症状：客户端成功连接到一个节点，而队列或元数据在其他地方不健康。如果问题仅影响一个可用区或一个代理主机，请在更改集群范围设置之前比较各节点的 status、list_connections 和 list_queues。

自动化什么

对于小型环境，一些脚本化的检查可以捕获明显的问题：节点宕机、磁盘警报、内存警报、重要队列上没有消费者、就绪消息超过正常阈值、未确认消息持续上升以及连接数远高于基线。

对于大型系统，使用 RabbitMQ Prometheus 插件或其他指标管道，并保留 rabbitmqctl 用于直接调查。警报应与用户关心的行为相关联。队列在批处理作业期间短暂上升可能是正常的。队列上升十五分钟，而消费者已连接且未确认消息也在上升，这是一个更好的告警条件。

节省时间的操作习惯

以正确的操作系统用户或通过安装期望的服务帐户运行 rabbitmqctl。权限问题在您匆忙时可能看起来像代理问题。如果命令无法联系节点，请检查节点名称、Erlang cookie 以及 RabbitMQ 服务是否实际在该主机上运行。

保留一个重要的队列及其预期消费者的小列表。在事件期间，“队列有零个消费者”只有在您知道该队列是否应该始终有消费者时才有用。一些延迟、死信或批处理队列预计会长时间空闲。

最后，不要仅仅为了让仪表盘变绿而清除队列。清除队列意味着数据丢失，除非消息在设计上是可丢弃的。如果消息卡住，首先找出它们是等待、未确认、拒绝、死信还是被缺少消费者阻塞。

rabbitmqctl status、list_connections、list_channels、list_consumers 和 list_queues 为您提供了一条实用的命令行路径，从“消息延迟”到可能的原因。诀窍是将它们一起阅读：节点资源、客户端连接、通道行为、消费者存在和队列深度都讲述了同一个故事的不同部分。