Мониторинг RabbitMQ с помощью Proto Observability

Сбор метрик RabbitMQ

Интеграция rabbitmq собирает метрики через HTTP management API (/api, порт 15672), а не через JMX — поэтому образ агента можно использовать обычный, без суффикса -jmx.

Чек собирает 59 метрик пятью группами: соединения (connection), узлы (node), кластер (overview), exchange и очередь (queue).

Конфигурация RabbitMQ

1. Включите management plugin (в официальных образах rabbitmq:*-management он уже включён; для самостоятельной установки — rabbitmq-plugins enable rabbitmq_management).

2. Создайте read-only пользователя protoobp с тегом monitoring:

   rabbitmqctl add_user protoobp <PASSWORD>
   rabbitmqctl set_user_tags protoobp monitoring
   rabbitmqctl set_permissions -p / protoobp "^aliveness-test$" "^amq\.default$" ".*"
   

   Те же права можно выставить через management API (удобно из docker-compose, где нет erlang-cookie):

   BASE="http://admin:admin@rabbitmq:15672/api"
   curl -fsS -X PUT "$BASE/users/protoobp" \
     -H "content-type: application/json" \
     -d '{"password":"<PASSWORD>","tags":"monitoring"}'
   curl -fsS -X PUT "$BASE/permissions/%2F/protoobp" \
     -H "content-type: application/json" \
     -d '{"configure":"^aliveness-test$","write":"^amq\\.default$","read":".*"}'
   

healthcheck:
  test: ["CMD-SHELL", "rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_port_listener 15672"]

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Создайте файл /etc/protoobp-agent/conf.d/rabbitmq.d/conf.yaml:

   init_config:
   
   instances:
     - rabbitmq_api_url: http://localhost:15672/api/
       username: protoobp
       password: "<PASSWORD>"
   

2. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Добавьте autodiscovery-лейблы к контейнеру RabbitMQ. В docker-compose.yaml:

labels:
  com.protoobp.ad.check_names: '["rabbitmq"]'
  com.protoobp.ad.init_configs: '[{}]'
  com.protoobp.ad.instances: '[{"rabbitmq_api_url": "http://%%host%%:15672/api/", "username": "protoobp", "password": "<PASSWORD>"}]'

Или в Dockerfile:

LABEL "com.protoobp.ad.check_names"='["rabbitmq"]'
LABEL "com.protoobp.ad.init_configs"='[{}]'
LABEL "com.protoobp.ad.instances"='[{"rabbitmq_api_url": "http://%%host%%:15672/api/", "username": "protoobp", "password": "<PASSWORD>"}]'

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 8 "^    rabbitmq"

Ожидаемый вывод — Total Runs > 0 и Metric Samples ненулевые:

rabbitmq (3.2.0)
  Instance ID: rabbitmq:f69305ac6ed2be42 [OK]
  Total Runs: 2
  Metric Samples: Last Run: 58, Total: 73
  Average Execution Time : 101ms

Собираемые метрики

Чек различает три типа метрик:

• _count — кумулятивные счётчики, монотонно растут от старта брокера. Для дашбордов и алертов применяйте PromQL rate(... [5m]).
• _rate — скорость в секунду, рассчитанная самим RabbitMQ. Используется как есть.
• Без суффикса — мгновенные значения (gauge).

Лейблы

Общие (на всех метриках)

Добавляются агентом и ProtoOBP backend’ом:

Специфичные для RabbitMQ

Метрики соединений

Метрики узла

Несут лейбл rabbitmq_node.

Метрики кластера (overview)

Несут лейбл rabbitmq_cluster (для одиночного узла равен имени node).

Сводка по объектам

Сводка по очередям кластера

Поток сообщений (cluster)

Каждая операция представлена парой _count (cumulative counter) и _rate (rate per second).

Метрики exchange

Несут лейблы rabbitmq_exchange, rabbitmq_vhost. Каждая операция — пара _count / _rate.

Метрики очереди

Несут лейблы rabbitmq_queue, rabbitmq_vhost, rabbitmq_node.

Состояние очереди

Поток сообщений per-queue

Каждая операция — пара _count (cumulative counter) и _rate (rate per second).

Ключевые метрики для дашбордов и алертов

Здоровье узлов и кластера

• rabbitmq_node_running == 0 — алерт: узел недоступен.
• rabbitmq_node_partitions > 0 — алерт: split brain (network partition).
• rabbitmq_node_disk_alarm == 1 или rabbitmq_node_mem_alarm == 1 — алерт: поднята защитная блокировка приёма сообщений.

Ресурсы узла

• rabbitmq_node_mem_used / rabbitmq_node_mem_limit — алерт при > 0.8 (флоу-контроль активируется около vm_memory_high_watermark).
• rabbitmq_node_disk_free — алерт по абсолютному порогу (по умолчанию RabbitMQ начинает блокировку при <50 МБ).
• rabbitmq_node_fd_used — рост FD = утечка соединений или каналов.
• rabbitmq_node_run_queue стабильно высокий (> числа scheduler-ов) — перегрузка CPU.

Накопление сообщений (backlog)

• rabbitmq_queue_messages per rabbitmq_queue / rabbitmq_vhost — основной SLI; алерт по абсолютному порогу или производной.
• rabbitmq_queue_consumers == 0 при ненулевом rabbitmq_queue_messages_publish_rate = некому потреблять.
• rabbitmq_queue_consumer_utilisation < 0.4 — консьюмеры медленные или prefetch неоптимальный.
• rabbitmq_overview_queue_totals_messages_unacknowledged_count растёт — клиенты не подтверждают.

Поток сообщений

• rate(rabbitmq_overview_messages_publish_count[5m]) vs rate(rabbitmq_overview_messages_ack_count[5m]) — публикация против подтверждений (рассинхрон → backlog).
• rate(rabbitmq_overview_messages_redeliver_count[5m]) — растёт = ошибки обработки и nack/reject у консьюмеров.
• rate(rabbitmq_overview_messages_return_unroutable_count[5m]) > 0 — сообщения с mandatory=true не находят очередь (потери при mis-routing).

Соединения и каналы

• rabbitmq_connections_state{rabbitmq_conn_state="blocked"} > 0 или ..."flow" — продюсеров принудительно тормозит (memory/disk alarm или flow control).
• Резкий рост rabbitmq_overview_object_totals_connections / _channels — утечка клиентских ресурсов.