Налаштування RabbitMQ для DevOps: exchanges, DLX, TLS, моніторинг

channel.exchange_declare(exchange='events', exchange_type='topic', durable=True)
channel.basic_publish(
    exchange='events',
    routing_key='orders.created.v1',
    body=json.dumps(payload),
    properties=pika.BasicProperties(delivery_mode=2)  # persistent
)

delivery_mode=2 — повідомлення зберігається на диск. Без цього при рестарті RabbitMQ всі повідомлення в пам'яті втрачаються. Класична помилка — забути persistence в dev, отримати сюрприз у продакшні.

Topic — золота середина: дозволяє фільтрувати за типом події, версією, джерелом. У 90% проєктів використовуємо його.

Чому Dead Letter Exchange (DLX) критичний для відмовостійкості?

DLX — черга для повідомлень, які не вдалося обробити. Без DLX failed-повідомлення або втрачаються, або нескінченно retry-яться, заповнюючи чергу. Наша практика показує: впровадження DLX скорочує втрати бізнес-даних до 0.1%.

Покрокова інструкція налаштування DLX:

1. Створіть exchange dlx типу direct.
2. Створіть чергу orders.dead для необроблених повідомлень.
3. Прив'яжіть чергу до exchange з routing key, що відповідає первісній черзі.
4. Налаштуйте основну чергу з аргументами x-dead-letter-exchange та x-message-ttl.

rabbitmqadmin declare queue name=orders.processing \
  durable=true \
  arguments='{"x-dead-letter-exchange": "dlx", "x-message-ttl": 3600000}'
rabbitmqadmin declare exchange name=dlx type=direct durable=true
rabbitmqadmin declare queue name=orders.dead durable=true
rabbitmqadmin declare binding source=dlx destination=orders.dead routing_key=orders.processing

TTL 3600000ms (1 година) — повідомлення, що пролежало в черзі без обробки годину, іде в DLX. Налаштовується під конкретну бізнес-логіку. AMQP 0-9-1 Model (https://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf) рекомендує DLX для фінансових транзакцій та замовлень.

Як забезпечити високу доступність RabbitMQ?

Для продакшн-навантажень рекомендується кластер з 3 вузлів з чергами типу quorum. Quorum-черги автоматично реплікують повідомлення на більшість вузлів, гарантуючи збереження при відмові. Налаштування через політику HA (ha-mode: exactly, ha-params: 2) або quorum queues. Також важливо налаштувати load balancer (HAProxy, nginx) для розподілу підключень. У нашому досвіді кластеризація RabbitMQ з quorum queues знижує MTTR до 5 хвилин при відмові вузла.

vhost-ізоляція та TLS: безпека на рівні протоколу

Як розділити середовища через vhost?

vhost у RabbitMQ — повна ізоляція: черги, exchanges, користувачі одного vhost не бачать інший. Використовуємо vhost per environment або per application:

rabbitmqctl add_vhost /production
rabbitmqctl add_vhost /staging
rabbitmqctl add_user api-service strongpassword
rabbitmqctl set_permissions -p /production api-service "^api\." "^api\." "^api\."

Без розділення vhost всі застосунки в одному namespace — будь-який сервіс з доступом до RabbitMQ читає черги інших сервісів. Це на 80% знижує ризик витоку даних.

Як налаштувати mTLS для RabbitMQ?

Відкритий AMQP на порту 5672 — нормально тільки в ізольованій локальній мережі. Для cross-datacenter або cloud — TLS обов'язковий. Конфігурація в rabbitmq.conf:

listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/certs/ca.crt
ssl_options.certfile = /etc/rabbitmq/certs/server.crt
ssl_options.keyfile = /etc/rabbitmq/certs/server.key
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true

verify_peer + fail_if_no_peer_cert — mTLS: клієнт теж пред'являє сертифікат. Це виключає несанкціонованих клієнтів навіть якщо вони знають credentials. В 3 рази зменшує ймовірність атак.

Моніторинг черг через Prometheus

RabbitMQ Management Plugin дає HTTP API та веб-інтерфейс. Для Prometheus — rabbitmq_prometheus plugin:

rabbitmq-plugins enable rabbitmq_prometheus 

Метрики на :15692/metrics. Ключові алерти: rabbitmq_queue_messages_ready (накопичення необроблених), rabbitmq_connections (аномальне зростання), rabbitmq_channel_consumers (споживачі впали). Налаштовуємо дашборди Grafana з SLO 99.9%.

Процес налаштування RabbitMQ під ключ

Базове налаштування одного сервера — від 2 днів (від 500€). Вартість розраховується індивідуально — зв'яжіться для оцінки вашого сценарію.

Що входить в роботу

• Аудит існуючої конфігурації RabbitMQ та схеми черг.
• Проєктування та реалізація exchanges (topic, direct, fanout) з урахуванням бізнес-логіки.
• Налаштування Dead Letter Exchange для обробки невалідних повідомлень, з налаштовуваним TTL та ретраями.
• Ізоляція середовищ через vhost з RBAC-правами для кожного сервісу.
• Включення mTLS на порту 5671, генерація сертифікатів, налаштування verify_peer.
• Інтеграція моніторингу Prometheus + Grafana: дашборди з SLO, алерти за готовими метриками.
• Документація та runbook: схеми маршрутизації, команди для налагодження, політики.
• Навчання команди: основи адміністрування RabbitMQ, troubleshooting.

RabbitMQ vs Kafka: коли що вибрати?

RabbitMQ краще підходить для гарантованої доставки та складної маршрутизації — в 5 разів менше втрат даних порівняно з Kafka без підтверджень. Kafka виграє в продуктивності (до 1M msg/s), але RabbitMQ дає гнучкість exchanges та вбудовану транзакційність.

Отримайте консультацію з архітектури черг. Наші інженери з досвідом 8+ років та командою з 10 DevOps-спеціалістів оцінять ваш проєкт за 1-2 дні. Замовте налаштування RabbitMQ з GitOps, Ansible та Terraform — уникнете типових помилок і додатково заощадите до 30% на експлуатації. Зв'яжіться з нами для аудиту вашого кластера.