Как отслеживать статус узла RabbitMQ и соединения с помощью rabbitmqctl

RabbitMQ обычно привлекает внимание только после того, как очередь переполняется, потребитель перестает подтверждать сообщения или развертывание создает сотни дополнительных соединений. rabbitmqctl по-прежнему является одним из самых быстрых способов узнать, что брокер видит изнутри узла. Он не заменит Prometheus, веб-интерфейс управления или просмотр журналов, но предоставляет надежный вид из командной строки, когда вы находитесь на сервере и вам нужны быстрые ответы.

Понимание rabbitmqctl

Скрипт rabbitmqctl является основным интерфейсом командной строки для взаимодействия с узлом RabbitMQ. Он позволяет администраторам выполнять широкий спектр задач, от запуска и остановки брокера до управления пользователями, разрешениями, обменниками, очередями и, что важно для этой статьи, мониторинга рабочего состояния узла и его сетевой активности.

Проверка статуса узла RabbitMQ

Прежде чем углубляться в соединения, важно убедиться, что ваш узел RabbitMQ работает. Команда status предоставляет всесторонний обзор текущего состояния узла.

Команда rabbitmqctl status

Эта команда выводит множество информации, включая:

• Имя узла: Имя узла RabbitMQ.
• Запущенные приложения: Список запущенных приложений Erlang, где ключевым индикатором является сам RabbitMQ.
• Использование памяти: Детали распределения и использования памяти, важные для настройки производительности.
• Дисковое пространство: Информация о доступном дисковом пространстве, которое может повлиять на сохранность сообщений.
• Файловые дескрипторы: Количество открытых файловых дескрипторов, важный системный ресурс.
• Сетевая информация: Детали о сетевых интерфейсах и портах.
• Статус кластера: Информация о том, является ли узел частью кластера, и его связность.
• Прослушиватели: Порты, которые RabbitMQ прослушивает для различных протоколов (AMQP, веб-интерфейс управления и т.д.).

Пример использования:

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_* принимают аргументы для указания отображаемых полей, что делает вывод более управляемым. Вы также можете фильтровать и сортировать вывод с помощью стандартных утилит оболочки, таких как grep и sort.

Пример: Поиск соединений от конкретного пользователя:

rabbitmqctl list_connections | grep 'my_user'

Пример: Отображение только очередей с неподтвержденными сообщениями:

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

Лучшие практики мониторинга

• Регулярные проверки: Внедрите регулярные проверки rabbitmqctl status для выявления потенциальных проблем до того, как они повлияют на производство.
• Автоматизация: Рассмотрите возможность автоматизации этих проверок с помощью скриптов и интеграции их с системами мониторинга (например, Prometheus, Nagios) для упреждающего оповещения.
• Контекст имеет значение: Понимайте типичные значения для вашей среды. Внезапный всплеск неподтвержденных сообщений или новое неожиданное соединение требуют расследования.
• Сочетание с веб-интерфейсом управления: Хотя rabbitmqctl мощен для написания скриптов и прямого доступа, веб-интерфейс управления RabbitMQ предоставляет визуальный и интерактивный способ мониторинга той же информации.
• Мониторинг ресурсов: Всегда сопоставляйте вывод rabbitmqctl с мониторингом системных ресурсов (ЦП, ОЗУ, дисковый ввод-вывод) для получения полной картины.

Полезный процесс триажа при переполнении очередей

Когда очередь начинает расти, не начинайте с перезапуска 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 означает, что сообщения были доставлены потребителям, но еще не подтверждены. Высокое количество неподтвержденных сообщений часто указывает на медленные обработчики, длительные вызовы базы данных внутри потребителей, слишком высокое значение prefetch или потребителей, которые вышли из строя после получения сообщений.

В-четвертых, не слишком ли много соединений или каналов?

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 активно. Большое количество соединений, застрявших в состоянии управления потоком или заблокированных, заслуживает внимания. Если ssl имеет значение false там, где вы ожидаете TLS, возможно, клиенты используют неправильный прослушиватель или старую конфигурацию.

Имена клиентов также стоит задавать в коде приложения. Многие клиентские библиотеки RabbitMQ позволяют задать имя соединения. Без этого вы можете видеть только хост и порт, что затрудняет идентификацию службы, вызывающей нагрузку. Имя типа billing-worker-prod-3 гораздо полезнее, чем анонимное TCP-соединение.

Проблемы с каналами и prefetch

Каналы дешевы по сравнению с TCP-соединениями, но они не бесплатны. Частая проблема в производстве — рабочий процесс, который создает каналы и никогда их не закрывает. Другая — потребитель с высоким значением prefetch, который получает много сообщений, обрабатывает их медленно и оставляет других потребителей бездействующими.

Используйте:

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

Если один канал имеет большое количество messages_unacknowledged, проверьте этого потребителя. Возможно, он выполняет медленные HTTP-вызовы, ожидает блокировку базы данных или обрабатывает сообщения по одному, в то время как prefetch позволяет ему резервировать гораздо больше. Уменьшение prefetch может улучшить справедливость, но это не волшебное исправление производительности. Если обработчики медленные, вам все равно нужно исправить обработчик.

Проверки очередей, которые должны быть рядом с проверками соединений

Хотя эта статья посвящена статусу узла и соединениям, состояние очередей завершает картину:

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

Устойчивая очередь с постоянными сообщениями может создавать нагрузку на диск. Очередь с consumers, установленным в 0, требует проверки приложения. Очередь с большим количеством готовых сообщений и активными потребителями указывает на несоответствие пропускной способности. Очередь с большим количеством неподтвержденных сообщений указывает на проблемы обработки или подтверждения на стороне потребителя.

При использовании фильтров оболочки будьте осторожны с позициями столбцов. Если вы измените запрашиваемые поля, старые фрагменты awk могут молча фильтровать не тот столбец. Для повторяющихся проверок предпочитайте скрипты, которые запрашивают фиксированные поля и маркируют свой вывод.

Заметки о кластере

В кластере выполняйте команды для интересующего вас узла или укажите узел, где это поддерживается:

rabbitmqctl -n rabbit@node1 status

Проверьте членство в кластере и разделы:

rabbitmqctl cluster_status

Сетевые разделы и несогласие узлов могут создавать запутанные симптомы: клиенты успешно подключаются к одному узлу, в то время как очереди или метаданные нездоровы на других. Если проблема затрагивает только одну зону доступности или один хост брокера, сравните status, list_connections и list_queues на разных узлах, прежде чем изменять обще кластерные настройки.

Что автоматизировать

Для небольшой среды несколько скриптовых проверок могут выявить очевидные проблемы: узел не работает, сигнал тревоги по диску, сигнал тревоги по памяти, отсутствие потребителей в важных очередях, количество готовых сообщений выше нормального порога, неподтвержденные сообщения, которые продолжают расти, и количество соединений, значительно превышающее базовый уровень.

Для более крупных систем используйте плагин Prometheus для RabbitMQ или другой конвейер метрик, а rabbitmqctl оставьте для прямого расследования. Оповещения должны быть привязаны к поведению, которое важно для пользователей. Очередь, ненадолго выросшая во время пакетной обработки, может быть нормой. Очередь, растущая в течение пятнадцати минут, в то время как потребители подключены и неподтвержденные сообщения также растут, является более веской причиной для вызова.

Операционные привычки, экономящие время

Запускайте rabbitmqctl от правильного пользователя ОС или через учетную запись службы, которую ожидает ваша установка. Проблемы с разрешениями могут выглядеть как проблемы брокера, когда вы спешите. Если команда не может связаться с узлом, проверьте имя узла, файл cookie Erlang и то, действительно ли служба RabbitMQ запущена на этом хосте.

Ведите небольшой список важных очередей и их ожидаемых потребителей. Во время инцидента «в очереди ноль потребителей» полезно только в том случае, если вы знаете, должна ли эта очередь всегда иметь потребителей. Некоторые очереди задержки, недоставленных сообщений или пакетной обработки могут простаивать в течение длительного времени.

Наконец, не очищайте очереди только для того, чтобы сделать панели мониторинга зелеными. Очистка очереди — это потеря данных, если только сообщения не являются одноразовыми по замыслу. Если сообщения застряли, сначала выясните, ожидают ли они, не подтверждены, отклонены, отправлены в очередь недоставленных сообщений или заблокированы отсутствующим потребителем.

rabbitmqctl status, list_connections, list_channels, list_consumers и list_queues дают вам практический путь командной строки от «сообщения задерживаются» до вероятной причины. Хитрость в том, чтобы читать их вместе: ресурсы узла, клиентские соединения, поведение каналов, наличие потребителей и глубина очередей — все это рассказывает разные части одной и той же истории.