Monitoring Overview

Message Queue includes an internal client that is enabled by default to produce different types of metrics messages. Production is actually enabled when a client subscribes to a topic destination whose name matches one of the metrics message types. For example, if a client subscribes to the topic mq.metrics.jvm, the client receives information about JMV memory usage.

The metrics topic destinations (metric message types) are described in Table 4–1.

A metrics message that is produced to one of the destinations listed in Table 4–1 is a normal JMS message; its header and body are defined to hold the following information:

• The message header has several properties, one that specifies the metrics message type, one that records the time the message was produced (timestamp), and a collection of properties identifying the broker that sent the metric message (broker host, port, and address/URL).

• The message body contains name-value pairs that vary with the message type.

  The section Format of Metrics Messages provides complete information about the types of metrics messages and their content (name-value pairs).

To receive metrics messages, the consuming client must be subscribed to the destination of interest. Otherwise, consuming a metrics message is exactly the same as consuming any JMS message. The message can be consumed synchronously or asynchronously, and then processed as needed by the client.

Message-based monitoring is concerned solely with obtaining metrics information. It does not include methods that you can call to work with physical destinations, configure or update the broker, or shutdown and restart the broker.

Administrative Tasks

By default the Message Queue metrics-message producing client is enabled to produce nonpersistent messages every sixty seconds. The messages are allowed to remain in their respective destinations for 5 minutes before being automatically deleted. To persist metrics messages, to change the interval at which they are produced, or to change their time-to-live interval, the administrator must set the following properties in the config.properties file: imq.metrics.topic.persist , imq.metrics.topic.interval, and imq.metrics.topic.timetolive .

In addition, the administrator might want to set access controls on the metrics destinations. This restricts access to sensitive metrics data and helps limit the impact of metrics subscriptions on overall performance. For more information about administrative tasks in enabling message-based monitoring and access control, see Configuring and Using Broker Logging in Sun Java System Message Queue 4.1 Administration Guide.

Implementation Summary

The following task list summarizes the steps required to implement message based monitoring:

To Implement Message-Based Monitoring

1. The developer designs and writes a client that subscribes to one or more metrics destinations.

2. The administrator sets those metrics-related broker properties whose default values are not satisfactory.

3. (Optional) The administrator sets entries in the access.control.properties file to restrict access to metrics information.

4. The developer or the administrator starts the metrics monitoring client.

   When consumers subscribe to a metrics topic, the topic’s physical destination is automatically created. After the metrics topic has been created, the broker’s metrics message producer begins to send metrics messages to the appropriate destination.