Many customers manage the performance of their MQ environments based on requirements from the application development community. These requirements are often as simple as monitoring the current depth of the queues used by the application. When the current queue depth of a queue exceeds the threshold specified for the application, an alert must be raised. This relatively straight forward process can become an administrative nightmare in an environment where thousands of queues need to be monitored with this level of granularity. In this case, an OMEGAMON XE for Messaging situation would be required to monitor each queue. This design results in a high cost of collection, along with a high cost of ownership, as the administrative burden of implementing this scheme is prohibitive.
A better way to approach the problem is to group queues into queue depth threshold brackets. For example, queues A, B, C; are all evaluated against a current depth threshold of 10 of more. Queues D, E, F are evaluated against the next higher threshold bracket, perhaps current depth greater than 50. Bracket thresholds are determined based on the current depth requirements specified by the application owners. As many brackets as needed can be defined.
The key to the solution lies in the assignment of a queue to a threshold bracket. Customers will seldom have a queue naming standard based on their queue depth monitoring needs. However, OMEGAMON XE for Messaging provides a creative solution to the problem. OMEGAMON is sensitive to the queue definitions description field. The description field, typically a comment, can be modified to indicate which queue depth threshold bracket the queue should be evaluated against. Then, a single OMEGAMON XE situation can be constructed, reflective of multiple (perhaps all) queue depth threshold brackets. This situation would use an 'OR' construct, essentially checking for combination of Current Depth < threshold AND description field == queue bracket threshold limit, across the multiple specified brackets.