Устранение неполадок RabbitMQ: Диагностика проблем с очередями и сообщениями с помощью команд

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

Это руководство использует команды RabbitMQ для сужения круга поиска из терминала. Я полагаюсь на rabbitmqctl для состояния на стороне брокера и rabbitmqadmin, когда вам нужны операции API управления, такие как безопасная выборка сообщения. Примеры предполагают использование виртуального хоста по умолчанию, если не указана опция -p <vhost>. В реальных системах всегда указывайте vhost; многие ложные диагнозы возникают из-за того, что кто-то проверяет /, в то время как приложение использует payments или prod.

Понимание rabbitmqctl

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

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

Диагностика завалов в очередях и зависших сообщений

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

Начните с очереди, но запрашивайте правильные столбцы

Вывод list_queues по умолчанию слишком скуден для устранения неполадок. Запрашивайте столбцы, которые разделяют «ожидающие доставки» и «доставленные, но не подтвержденные».

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged messages consumers state

Читайте это так:

Симптом	Вероятное значение
messages_ready растет, consumers равно 0	Нет активного потребителя, подписанного на очередь. Проверьте развертывания, учетные данные, vhost и имя очереди.
messages_ready растет, потребители присутствуют	Потребители слишком медленные, заблокированы или предварительная выборка слишком мала для рабочей нагрузки.
messages_unacknowledged высокое и стабильное	Потребители получили сообщения, но не подтверждают их. Ищите зависшие обработчики или слишком высокое значение предварительной выборки.
state не running	Очередь может быть недоступна, синхронизироваться или затронута проблемой узла. Проверьте состояние кластера и лидера очереди.

Для кворумных очередей добавьте столбцы лидера и членства:

rabbitmqctl -p / list_queues name type leader members online messages_ready messages_unacknowledged consumers state

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

Если список длинный, отфильтруйте его с помощью стандартных инструментов оболочки:

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged consumers state \
  | awk '$2 > 0 || $3 > 0 || $4 == 0'

Проверьте, не блокирует ли брокер издателей

rabbitmqctl status
rabbitmq-diagnostics alarms

Сигналы тревоги по памяти и диску не означают, что очередь настроена неправильно, но они объясняют многие инциденты, когда «ничего не движется». Когда RabbitMQ поднимает сигнал тревоги по памяти или свободному месту на диске, он может блокировать соединения издателей. Потребители все еще могут потреблять сообщения, поэтому видимый симптом может быть неравномерным: некоторые очереди уменьшаются, другие перестают получать новую работу, а издатели получают тайм-аут.

Также проверьте слушателей и работоспособность узла:

rabbitmq-diagnostics ping
rabbitmq-diagnostics listeners
rabbitmq-diagnostics check_running
rabbitmq-diagnostics check_local_alarms

Проверьте потребителей без догадок

list_connections сообщает вам, кто подключен. list_channels сообщает, открыли ли эти соединения каналы и какой объем работы они удерживают.

rabbitmqctl list_connections name user peer_host peer_port state channels recv_oct send_oct
rabbitmqctl list_channels connection name number consumer_count messages_unacknowledged prefetch_count state

Полезные шаблоны просты:

• Нет соединения с ожидаемого хоста: приложение не работает, не может разрешить брокера, не может аутентифицироваться или подключается к другому окружению.
• Соединение существует, но нет каналов: клиент подключился, а затем завершился сбоем до объявления или потребления.
• Каналы существуют, но consumer_count равно 0: приложение может только публиковать, или подписка потребителя не удалась.
• messages_unacknowledged высокое на одном канале: этот потребитель имеет работу в памяти и не возвращает подтверждения быстро.

Если вы используете именованные соединения, включите connection_name в конфигурацию вашего клиента. Строка вида 10.42.8.17:52344 -> 10.42.1.20:5672 менее полезна, чем billing-worker-7.

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

Когда очередь пуста, но приложение сообщает, что опубликовало сообщения, маршрутизация — это следующее место для поиска.

rabbitmqctl -p / list_exchanges name type durable auto_delete internal arguments
rabbitmqctl -p / list_bindings source_name source_kind destination_name destination_kind routing_key arguments

Прямой обменник требует точного совпадения ключа маршрутизации. Тематический обменник использует * для одного слова и # для нуля или более слов. Обменник типа fanout игнорирует ключи маршрутизации. Если у обменника нет соответствующей привязки и нет альтернативного обменника, сообщение не маршрутизируется. Оно не ждет где-то тайно.

Для подтверждения на стороне издателя используйте обязательную публикацию и обрабатывайте возвращенные сообщения в клиенте. На стороне брокера пользовательский интерфейс управления и метрики обычно лучше, чем rabbitmqctl для скоростей, но list_bindings достаточно, чтобы выявить распространенные ошибки: неправильный vhost, неправильный обменник, неправильно написанный ключ маршрутизации или очередь, привязанная к старому обменнику после развертывания.

Выберите сообщение безопасно

В современном RabbitMQ нет общей команды rabbitmqctl queue_get. Используйте плагин управления через rabbitmqadmin или HTTP API. Делайте это осторожно: в зависимости от режима подтверждения получение сообщений может удалить или вернуть их в очередь.

rabbitmqadmin -V / get queue=orders.pending count=3 ackmode=ack_requeue_true

Используйте это для ответа на узкие вопросы: является ли полезная нагрузка валидным JSON, соответствует ли тип сообщения ожиданиям потребителя, отсутствует ли обязательный заголовок, является ли ключ маршрутизации тем, который указала команда производителя? Не используйте это как инструмент массовой проверки в загруженной производственной очереди.

Ищите движение недоставленных сообщений

Задержка обработки часто проявляется в виде тихо растущей очереди недоставленных сообщений.

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged arguments policy
rabbitmqctl -p / list_bindings source_name destination_name routing_key arguments \
  | grep -E 'dead|dlx|retry|parking'

Аргументы очереди, такие как x-dead-letter-exchange, x-dead-letter-routing-key, x-message-ttl, x-max-length и x-overflow, изменяют то, куда сообщения попадают, когда они истекают, отклоняются или достигают ограничений длины. Если приложение повторяет попытки, отправляя недоставленные сообщения через очереди задержки, неправильная привязка может создать цикл. Симптом выглядит как «задержанные сообщения», но реальная проблема в том, что сообщения циркулируют между очередями вместо того, чтобы достичь финальной очереди обработки или очереди для припаркованных сообщений.

Практическая последовательность команд

Когда кто-то сообщает, что «заказы зависли», я обычно выполняю эту последовательность:

rabbitmq-diagnostics ping
rabbitmq-diagnostics check_local_alarms
rabbitmqctl -p orders list_queues name type messages_ready messages_unacknowledged consumers state
rabbitmqctl list_connections name user peer_host state channels
rabbitmqctl list_channels connection consumer_count messages_unacknowledged prefetch_count state
rabbitmqctl -p orders list_bindings source_name destination_name routing_key arguments

Если messages_ready высокое, а consumers равно нулю, переходите к развертыванию потребителя. Если messages_unacknowledged высокое, переходите к журналам потребителя и настройкам предварительной выборки. Если очередь пуста, но издатели сообщают об успехе, проверьте привязки и подтверждения издателя. Если активны сигналы тревоги, исправьте давление на ресурсы брокера, прежде чем разбираться с логикой приложения. Это удерживает расследование на основе того, что брокер на самом деле делает.