Context

Tool mentors explain how a tool can perform tasks, which are part of ITUP processes and activities. The tasks are listed as Related Elements in the Relationships section.

You can see the details of how processes and activities are supported by this tool mentor, by clicking the links next to the icons:

•   Service Execution
  •   Deliver Service

Details

As an example to discuss the use of OMEGAMON® to monitor a service, this mentor presents a concrete example about monitoring IBM® WebSphere® MQ.

Although WebSphere MQ is generally very reliable, problems can occur that could compromise the integrity of messages that are being processed. These problems could take the form of messages being delivered to the wrong queue or not being delivered at all. Common causes for such situations include Queue Manager failures, communication link failures between Queue Managers, application code with misspelled queue names, queues becoming full, and infrastructure design errors leading to messages being delivered to the wrong queue.

The OMEGAMON monitoring agent for MQ allows interested parties to keep track of potential problems and, in many cases, affect repairs to the system in order to maintain system continuity.

Assuming that the OMEGAMON base infrastructure is installed and working, all that is needed to implement MQ monitoring is to install an OMEGAMON MQ Agent and configure it to work with a specific Queue Manager. This process is explained in the manual, Using IBM Tivoli® OMEGAMON XE for WebSphere MQ Monitoring, which can be found here: http://publibfp.boulder.ibm.com/epubs/pdf/c3168880.pdf

The OMEGAMON Agent for MQ comes with a set of predefined Situations that raise alerts when certain conditions occur. It is recommended that these Situations be enabled in order to report on common problems. This enablement is done using the Situation Editor through the IBM Tivoli CandleNet Portal user interface. Let's assume that you want to be notified when a message is sent to the Dead Letter Queue.

The steps needed to enable this Situation are as follows:

1. Run the Situation Editor (Choose it from the Edit menu pick list, or click the Situation Editor icon in the tool bar.)
2. Use the Situation Filter button to show Situations that are associated with the monitored application (MQ, in this case).
3. Click the MQSeries_Dead_Letter Situation and its properties will be displayed in the right panel.
4. Click the Distribution tab. This will allow you to specify which Queue Managers this Situation will be allocated to. Highlight the Queue Manager name in the right panel and click the left arrow button to move its name across to the "Assigned" panel on the left.
5. Click the Conditions tab to return to the main display.
6. Check the Run at Startup box to enable the Situation to start automatically whenever the OMEGAMON MQ Agent is started.
7. Look at the values in the Sampling Interval fields at the lower left of the panel. Reset these to a realistic value that suits your environment. (Note that the sampling interval should not be less than the sampling rate of the Agent itself.)
8. Change the State in the pick list to the lower right to reflect the severity level that you would like this Event to be reported at: Critical, Warning, or Informational.
9. Click OK to save and enable the Situation.

Assuming that a message is placed on your Dead Letter Queue, an Event will be raised as a result of your Situation becoming true. When this situation occurs, an icon reflecting the severity level will be superimposed over the Queue Manager icon in the IBM Tivoli CandleNet Portal navigator panel:

• Critical: Red triangle containing a white '!'.
• Warning: Yellow square containing a black '!'.
• Informational: Pink circle containing a blue '!'.

Figure 1: The CandleNet Portal Navigator panel

You can now "drill down" to find out more information about the problem. The quickest way to do this is to hover the mouse cursor over the Event icon. A "flyover popup" window will appear and gives the name of the Situation that caused the Event to be reported. In this case, it will say "MQSeries_Dead_Letter."

The popup will also show the name of the Queue Manager and will include a link button that contains an icon consisting of two blue chain links connected together. Click on the link button to be taken to the Event workspace, where more detail will be available.

Depending on the logon privileges you have, you might be able to do a variety of different things from the Event workspace:

• View the Message Descriptor of the message on the Dead Letter Queue
• View the Dead Letter Header of the message on the Dead Letter Queue
• View the application data of the message on the Dead Letter Queue
• Re-queue the message to the queue it was supposed to go to
• Issue any MQ command to the Queue Manager

One of the features of the OMEGAMON system is the ability to incorporate "reflex automation" within a Situation. This ability means that the Situation can issue commands on your behalf when an Event is raised. When you are comfortable using OMEGAMON to monitor your MQ system, you might want to enable this feature using the Situation Editor and clicking the Action tab.

The Action command can be:

• A "System Command" that is executed by the operating system on which the Agent is running. This command could include running a script.
• An MQSC command as though being entered using RUNMQSC or CSQUTIL. In order to signify an MQSC command, enter a prefix of "MQ:" into the System Command field in the Action panel.

Although this mentor has used only the Dead Letter Queue Situation as an example, other Situations can be handled in a similar way. If you want to create a custom Situation for your own purposes, existing Situations can be copied and renamed to suit your environment.

For More Information

For more information about this tool, click on the link for this tool at the top of this page.