CICS / WebSphere

WebSphere MQ Monitoring and Alerting: A Review

5 Pages

-        How many messages are expected on a queue?

-        How large are the messages?

-        When will the messages be placed on the queue and by what method?

-        How long are the messages expected to remain on the queue?

-        When will the messages expire?

-        How are the messages removed from the queue?

-        What are the consequences of losing one or more messages?

-        Can the contents of the message be recovered if there’s a loss?

With this information, the number of buffers and pageset space can be determined to reduce the risk of not being able to store the messages, and a monitoring process can be evaluated and implemented. For example, if it’s known that 10,000 messages must remain on a queue for processing during daytime business hours, an alert that there are 10,000 messages on the queue at 3 a.m. would be unnecessary, but an alert that 10,000 messages were on the queue at 10 a.m. may indicate an application failure.

A monitor should recognize levels of risk: Most help desk functions have several levels of support. An ideal monitoring system should be able to alert at several levels of danger. Using the aforementioned example, if 10,000 messages are expected on a queue during a certain period, the appearance of 11,000 messages on the queue may generate a level-one warning that something abnormal may be occurring and the queue should be watched more closely. The appearance of 50,000 messages on the queue may generate an error alert and require third-level investigation to determine if there’s a risk to the system. This also indicates the need for the application generating the messages to communicate changes in processing. The risks for known events should be mitigated when identified.

5 Pages