Here we discuss some of the ways to monitor and analyze IBM MQ and some of the event metrics. First, here are some definitions and concept to refresh or enhance your understanding of IBM MQ.
MQ is way to transfer objects between programs. It replaces something that requires a persistent connection between two points to transmit data, like ftp or even tcp, with something that does not. MQ is said to be decoupled, meaning it can queue up a message and send it when the receiving side is ready to receive it or the sending side is ready to release that message. Because messages lineup for transmission, this is called a queue.
MQ is not completely decoupled, as the two sides have to communicate. To illustrate email is a good analogy. People often believe that email is completely decoupled, it is not. Intuitively, it would seem that when you send a message it is sort of tossed onto the network and then delivered as a self-contained bundle like regular snail mail. But email uses SMTP, which requires a persistent connection between two email servers and a back-and-forth communication.
MQ has the following definitions:
- A message is some kind of object or data, like a Java object or a SOAP message.
- A channel handles communications between queue managers.
- The queue manager is a container for the message queue.
- Message queues are objects that store messages.
As with anything else, making sure that MQ is working requires monitoring it and then tuning it to fix performance issues. Making sure that it is working at proper speed means monitoring with performance as one of the metric that you monitor.
MQ monitoring can help with capacity planning, detect problems in the queue manager, and improve the efficiency of the queue manager network. To do this, you turn on monitoring and tracing features that are themselves MQ messages. You retrieve the messages and look at the metrics in the messages.
Here we review some of IBM’s recommendations given here http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.mon.doc/q036140_.htm?lang=en
MQ monitoring is divided into events, messages, accounting and statistics, application activity trace, and real-time monitoring.
Events are divided into the following types:
Instrumentation events are a combination of events that create an event message. The event message gives information, warning, or error messages about the queue manager.
Performance events relate to a particular queue.
Used for an audit trail as to who changed what and when plus to generate reports to show the system layout.
A command event means an MQSC (keyed in by an other) or PCF (programmable command format) command.
Means that a queue manager has started to write a new log extent. This means the log has rolled over.
The route that a message takes through the queue manager network can be determined three ways:
- MQ display route application
- activity recording
- traceroute messaging
Accounting and Statistics Messages
A statistics message is a PCF message with different PCF structures inside. You configure the interval to send them to the system queue. These are channel messages, MQI (Message Queue Interface) statistics, and channel stats.
Application Activity Trace
This gives information about applications connected to a queue manager, by showing the sequence of MQI calls. You turn this on when event monitoring does not provide enough detail for the problem you are trying to work by using the queue and queue manager attributes. Tracing is enabled by configuring a tracing file. Trace messages are written after the timeout, maximum memory used, or maximum number of messages for the application is reached. Turning on tracing will cause a performance hit to the server.
Real-time monitoring can be enabled for individual queues and channels or all of them. To do this you set the MONG or MONCHL attribute. You set the monitoring level to low, medium, or high depending on the volume of stats you want.
Turning on queue monitoring provides a look into the queue so that if the queue depth increases, so can there is a problem with the queue. The troubleshooting procedure is to:
- Determine whether you application has the queue open.
- Check that messages on the queue are available.
- Check that you application is pulling messages off the queue.
- Determine whether you application is capable of processing messages fast enough.
Here are just a few ideas for how to monitor MQ series for performance, tracing, and statics information.