Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients |
3. Message Queue Clients: Design and Features
4. Using the Metrics Monitoring API
Creating a Metrics-Monitoring Client
Metrics Monitoring Client Code Examples
A Destination List Metrics Example
6. Embedding a Message Queue Broker in a Java Client
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.
Table 4-1 Metrics Topic Destinations
|
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.
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 Using the Message-Based Monitoring API in Oracle GlassFish Server Message Queue 4.5 Administration Guide.
The following task list summarizes the steps required to implement message based monitoring:
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.