Reference · built on requestConnectorStreams, queues & webhooks

RabbitMQ

Messages, queue depths, message rates, and broker health from RabbitMQ over AMQP and the management HTTP API.

About

RabbitMQ is a message broker maintained by Broadcom. It was built for AMQP 0-9-1, and AMQP 1.0 became a core protocol in RabbitMQ 4.0. Plugins add MQTT 3.1, 3.1.1, and 5.0, STOMP, and the RabbitMQ Stream protocol, with STOMP and MQTT also served over WebSockets. Producers publish to exchanges, bindings route to queues, and consumers take from queues inside a virtual host. The management plugin serves an HTTP API on port 15672 that lists and declares exchanges, queues, bindings, users, and virtual hosts and reports queue length, message rates, and node resource use.

Through Fibric, an operator watches queue depth, rates, and consumer counts and reads messages over a binary protocol. It proposes a publish, a declaration, or a policy for your approval.

This is a reference listing. It documents what Fibric would read from RabbitMQ and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Queue length and message rates, globally and per queue, exchange, or channel, from the management HTTP API
  • Connections, channels, and consumers on each queue, from the management HTTP API
  • Node resource use: sockets, file descriptors, and a memory usage breakdown
  • Exchanges, queues, bindings, virtual hosts, users, permissions, parameters, and policies, exported as definitions
  • Messages consumed from queues over AMQP 0-9-1 or AMQP 1.0 on port 5672, or 5671 with TLS
  • Messages arriving over MQTT on 1883, STOMP on 61613, or the RabbitMQ Stream protocol on 5552 when those plugins are enabled
  • Prometheus metrics on port 15692

Proposed actions

  • Target capability: propose publishing a message to an exchange with a routing key over AMQP 0-9-1
  • Target capability: propose declaring a queue, exchange, or binding through the management HTTP API
  • Target capability: propose creating or changing a policy on a virtual host, which needs a user tagged policymaker or administrator
  • Target capability: propose granting a user configure, write, and read permissions on a virtual host

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a queue that is filling with no consumers

    The operator reads queue length and consumer count from the management HTTP API. When a queue grows and its consumer count is zero, it names the queue, the virtual host, and the last connection seen.

    With Integration Health

  • Quiet an alert storm at the source

    A burst of messages on an alerts exchange repeats the same fault. The operator groups them by routing key and proposes one notice with the count instead of hundreds.

    With Alert Noise, Alarm Flood

  • Republish a parked batch

    Messages were parked on a holding queue during a deploy. The operator proposes republishing them to the original exchange once the consumer is back. You approve. The receipt lists each message.

    With Webhook Replay

Requirements

  • A RabbitMQ node with the management plugin enabled, reachable on 15672 or 15671 with TLS
  • A dedicated user. The default guest user can only connect from localhost
  • A management, monitoring, policymaker, or administrator tag on that user, matched to what the operator reads and proposes
  • Configure, write, and read permissions, expressed as regular expressions, on each virtual host the connector touches
  • Network reach to 5672 or 5671 for AMQP, and to the MQTT, STOMP, or Stream ports if those protocols are in use
Authentication
A username and password checked against RabbitMQ's internal database, or an LDAP, OAuth 2.0, or HTTP backend, with per-virtual-host configure, write, and read permissions; X.509 client certificates are accepted when the rabbitmq-auth-mechanism-ssl plugin is enabled.

Limits

  • Publishing and consuming through the HTTP API is discouraged. The docs say to prefer a binary messaging protocol
  • Statistics are collected every 5 seconds by default, and sample retention policies decide how long data points are kept
  • A user with only the management tag sees the virtual hosts it can log into, not the whole broker
  • MQTT, STOMP, and Streams are plugins. A broker without them enabled will not accept those clients

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request RabbitMQ ↗

Questions and answers

Which protocols does RabbitMQ accept?
AMQP 0-9-1 and AMQP 1.0 as core protocols, plus MQTT 3.1, 3.1.1, and 5.0, STOMP, and the RabbitMQ Stream protocol through plugins. STOMP, MQTT, and AMQP 1.0 can also run over WebSockets. The management plugin adds an HTTP API.
What does the management HTTP API expose?
Declaring, listing, and deleting exchanges, queues, bindings, users, virtual hosts, and permissions; queue length and message rates; node memory, sockets, and file descriptors; and definitions export of the whole schema. It can publish and get messages, but the docs discourage that path.
How are permissions scoped?
Per virtual host. Each user gets configure, write, and read permissions written as regular expressions over resource names. Topic permissions add a check on routing keys for topic exchanges. Management UI access is granted through user tags: management, policymaker, monitoring, and administrator.
Ask about RabbitMQ

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.