Page tree
Skip to end of metadata
Go to start of metadata


The Moogsoft Messaging System (MooMS) is the message bus component of Moogsoft AIOps and shares event data. This is subscribed to by the various Moolets.

The message bus is a publish-subscribe message brokering system implemented with RabbitMQ which uses AMQP, an open standard for message-orientated middleware, over TCP.

Message Handling

The Message Bus handles the data it receives (e.g. raw event data, new alerts, Situation activity etc) by placing it in queues, which are lines of messages waiting to be handled.

Moogsoft AIOps does not enforce any size or time limits on queues, so the maximum number of messages in a queue is limited by the available RAM and disk space on the server. It also depends on the size of the Alerts and Situations being generated. The size limit is 128kb for Alerts and 64kb for Situations.

Once the maximum number of messages has been reached, the broker drops messages from the front of the queue to make room for new messages. By default, Moogsoft applications use exclusive transient queues. For example, if AIOps or the broker shuts down or dies then the queue and all of its messages will be lost. Durable queues can be enabled using the message_persistence setting in $MOOGSOFT_HOME/config/system.conf (see Message Persistance).

For more information see the RabbitMQ docs on queues and queue length.

Default Configuration

By default, AIOps installs with a single RabbitMQ broker running on the same machine as the other AIOps components (LAMs, moog_farmd, the Moolets, etc.).

The out-of-the-box configuration is:

port: 5672
zone: <none>
username: moogsoft
password: m00gs0ft.

The username and password always need to match the Message Bus broker configuration. If commented out, a default "guest" user will be used (guest: guest).

Zones

You can use zones, or virtual hosts, to share a single RabbitMQ broker cluster among multiple instances of AIOps. 

If multiple instances of AIOps share a single RabbitMQ broker then each instance uses a different zone name to prevent message interference. In RabbitMQ, a zone is called a virtual host (vhost). Clients connecting to one vhost cannot see messages sent to a different vhost.

The default deployment does not use zones. If you specify a zone name, you must also configure a vhost with the same name in the RabbitMQ broker.

By default, AIOps clients connect to the vhost specified during moog-init.sh setup with the "moogsoft" username and the password. 

For distributed installations using multiple RabbitMQ brokers, this must be configured. A zone (vhost) name is required by the moog-init.sh setup script. See Message System Deployment.

Message Persistance

You can control and minimize message loss during a shutdown or failure using the following settings in system.conf:

message_persistence

Controls whether MooMS will persist important messages or not in the event of an application or message broker restart. This affects how the message bus handles messages.

Type: Boolean

Default: false

max_retries

The number of attempts to re-send a failed message, used in conjunction with retry_interval.

Type: Number
Default: 100

retry_interval

The time to wait in milliseconds between each re-send attempt. The combination of 100 retries and a 200 msec retry_interval gives a total of 20 seconds, which is typical duration for broker failover in a high availability environment.

Type: Number
Default: 200

cache_on_failure

Controls whether the message is cached internally and resent. If enabled, a message is cached is an initial retry, controlled by max_retry and retry_interval, is a failure. 

Type: Boolean
Default: false

cache_ttl

Specifies how many seconds a cached message lives for in the cache list. The system will attemp to resend any cached messages in the order they were put on the cache until their cache time-to-live (cache_ttl) value has been reached. Any messages not sent sucessfully sent will be discarded. This value will have a direct impact on sender process memory.

Type: Number
Default: 900

confirmation_timeout

Defines the time to wait for confirmation from a RabbitMQ Broker that it has received the sent message.

Moogsoft advises you do not change this value.

Type: Number
Default: 2000

25 Comments

  1. is the message bus component of Moogsoft AIOps (remember to try to mention brand/product) near the beginning.

  2. I don't think that the Bus publishes raw event data.  What happens is that a publisher publishes TO the bus.

  3. docs mention publishing and subscribing in previous 'graf. necessary to repeat? Maybe combining paragraphs

  4. I wonder about why we need to justify the choice of RabbitMQ. The benefits also get into tech detail that may not be appropriate for the introduction. "rest lam, etc.)

  5. revise for active:

    If multiple instances of AIOps share a single RabbitMQ broker

  6. Zones:  vhosts is clear in the body of the section

  7. I wonder what is the "task" here. Do we want to frame this as "You can use zones, or virtual hosts" to share a single RabbitMQ broker cluster among multiple instances of AIOps"? 

  8. What if we move this before zones/vhosts? This is more the "Default Configuration" 

    But after Message Handling

  9. Check style for period usage.

    Then introduce the default settings without repeating the word "default again and a colon. then all you need:


    port: 5672

    zone: <none>

    username: moogsoft

    password: m00gs0ft.


    We need to have a section or a link to a topic that tells you how to change the password.

  10. awkward. consider:

    The RabbitMQ broker listens on port 5672 by default. 

  11. The default deployment does not use zones. 

  12. This information goes with "Zones". If you define a zone for AIOps, you must configure a zone with the same name in RabbitMQ.

  13. host or machine? we should think of this usage. 

  14. This information belongs with the "Zone" section. If you specify a zone name, you must also configure a vhost with the same name in the RabbitMQ broker.

  15. This should be the first section after the Intro

  16. awk. This affects how the message bus handles messages...


  17. what qualifies as  an "important" message.

  18. in the event of an application or message broker restart.

  19. remove based on previous edit.

  20. This section is looking A LOT BETTER! Only question I have is if there are any trade offs for making any of these updates. Performance-wise, disk space wise? other?

    Does "Message Persistance" as a heading convey the true nature of the task – which is to Minimize message loss during a shutdown or failure."

  21. revise for active: the broker drops messages from the front of the queue...

  22. exclusive transient queues?

  23. See "Message Persistance".