Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
Introduction to Monitoring Tools
Configuring and Using Broker Logging
Changing the Logging Configuration
To Change the Logger Configuration for a Broker
Changing Log File Rollover Criteria
Sending Metrics Data to Log Files
Using the Command Utility to Display Metrics Interactively
Metrics Outputs: imqcmd metrics
Using the JMX Administration API
Using the Java ES Monitoring Console
Using the Message-Based Monitoring API
Setting Up Message-Based Monitoring
To Set Up Message-based Monitoring
14. Analyzing and Tuning a Message Service
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
Message Queue provides a Metrics Message Producer, which receives information from the Metrics Generator at regular intervals and writes the information into metrics messages,. The Metrics Message Producer then sends these messages to one of a number of metric topic destinations, depending on the type of metric information contained in the messages.
You can access this metrics information by writing a client application that subscribes to the metrics topic destinations, consumes the messages in these destinations, and processes the metrics information contained in the messages. This allows you to create custom monitoring tools to support messaging applications. For details of the metric quantities reported in each type of metrics message, see Chapter 4, Using the Metrics Monitoring API, in Oracle GlassFish Server Message Queue 4.5 Developer’s Guide for Java Clients
There are five metrics topic destinations, whose names are shown in Table 13-6, along with the type of metrics messages delivered to each destination.
Table 13-6 Metrics Topic Destinations
|
The broker properties imq.metrics.topic.enabled and imq.metrics.topic.interval control, respectively, whether messages are sent to metric topic destinations and how often. The imq.metrics.topic.timetolive and imq.metrics.topic.persist properties specify the lifetime of such messages and whether they are persistent.
Besides the information contained in the body of a metrics message, the header of each message includes properties that provide the following additional information:
The message type
The address (host name and port number) of the broker that sent the message
The time the metric sample was taken
These properties are useful to client applications that process metrics messages of different types or from different brokers.
This section describes the procedure for using the message-based monitoring capability to gather metrics information. The procedure includes both client development and administration tasks.
See the Message Queue Developer’s Guide for Java Clients for instructions on programming clients that subscribe to metrics topic destinations, consume metrics messages, and extract the metrics data from these messages.
Set imq.metrics.topic.enabled=true
The default value is true.
Set imq.metrics.topic.interval=interval .
The default is 60 seconds.
Set imq.metrics.topic.persist .
The default is false.
Set imq.metrics.topic.timetolive .
The default value is 300 seconds.
See the discussion in Security and Access Considerations below.
When consumers subscribe to a metrics topic, the metrics topic destination will automatically be created. Once a metrics topic has been created, the broker’s metrics message producer will begin sending metrics messages to the metrics topic.
There are two reasons to restrict access to metrics topic destinations:
Metrics data might include sensitive information about a broker and its resources.
Excessive numbers of subscriptions to metrics topic destinations might increase broker overhead and negatively affect performance.
Because of these considerations, it is advisable to restrict access to metrics topic destinations.
Monitoring clients are subject to the same authentication and authorization control as any other client. Only users maintained in the Message Queue user repository are allowed to connect to the broker.
You can provide additional protections by restricting access to specific metrics topic destinations through an access control file, as described in User Authorization.
For example, the following entries in an accesscontrol.properties file will deny access to the mq.metrics.broker metrics topic to everyone except user1 and user 2.
topic.mq.metrics.broker.consume.deny.user=* topic.mq.metrics.broker.consume.allow.user=user1,user2
The following entries will only allow users user3 to monitor topic t1.
topic.mq.metrics.destination.topic.t1.consume.deny.user=* topic.mq.metrics.destination.topic.t1.consume.allow.user=user3
Depending on the sensitivity of metrics data, you can also connect your metrics monitoring client to a broker using an encrypted connection. For information on using encrypted connections, see Message Encryption.
The metrics data outputs you get using the message-based monitoring API is a function of the metrics monitoring client you write. You are limited only by the data provided by the metrics generator in the broker. For a complete list of this data, see Chapter 21, Metrics Information Reference.