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

На этой странице:

• Сбор метрик RabbitMQ
  • Конфигурация RabbitMQ
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
  • Собираемые метрики
    • Лейблы
      • Общие (на всех метриках)
      • Специфичные для RabbitMQ
    • Метрики соединений
    • Метрики узла
    • Метрики кластера (overview)
      • Сводка по объектам
      • Сводка по очередям кластера
      • Поток сообщений (cluster)
    • Метрики exchange
    • Метрики очереди
      • Состояние очереди
      • Поток сообщений per-queue
  • Ключевые метрики для дашбордов и алертов
• Сбор логов RabbitMQ
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик 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 — утечка клиентских ресурсов.

Сбор логов RabbitMQ

Логи RabbitMQ собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для RabbitMQ настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

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

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

При установке RabbitMQ из пакета или вручную брокер пишет логи в файл <RABBITMQ_LOG_BASE>/rabbit@<hostname>.log (по умолчанию /var/log/rabbitmq/rabbit@<hostname>.log). Каталог можно переопределить переменной окружения RABBITMQ_LOGS или директивой log.dir в /etc/rabbitmq/rabbitmq.conf.

Дополните уже существующий /etc/protoobp-agent/conf.d/rabbitmq.d/conf.yaml (тот же файл, в котором лежит instances: для management API) блоком logs::

logs:
  - type: file
    path: /var/log/rabbitmq/*.log
    source: rabbitmq
    service: rabbitmq
    log_processing_rules:
      - type: multi_line
        name: log_start_with_date
        pattern: \d{4}-\d{2}-\d{2}

Маска *.log подхватывает основной лог брокера и *_upgrade.log, который RabbitMQ пишет при миграции схемы между версиями.

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

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

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — добавьте лейбл com.protoobp.ad.logs к контейнеру брокера. Агент подхватит stdout/stderr контейнера и пометит записи указанными source и service:

services:
  rabbitmq:
    labels:
      com.protoobp.ad.logs: '[{"source": "rabbitmq", "service": "rabbitmq", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_date", "pattern": "\\d{4}-\\d{2}-\\d{2}"}]}]'

Проверка

В выводе agent status должен быть раздел Logs Agent со статусом running и хотя бы один источник rabbitmq с ненулевым BytesRead:

docker exec protoobp-agent agent status \
  | sed -n '/^==== Logs Agent ====/,/^====/p'