IBM MQ alerts
As a Systems Integrator, you can create or update different types of IBM® MQ alerts so that you are notified when, for example, a threshold is reached and you need to act quickly to resolve an issue with any of the queues. Your aim is to minimize the downtime that might arise as a result of issues across an environment.
Queue depth alert
In this alert, a fixed value is defined as a current queue depth threshold. As a result, if a threshold value is breached for a current queue depth, an alert is generated. As a system integrator, it is important to receive notifications when the queue depth is greater than the defined threshold. The issue usually occurs when the consuming application is not running or the consumer is encountering any performance issue. You can then act to ensure that the consumer is up and running or mitigate any ongoing performance issues with the consumer. With complete visibility of the queue depth and alert notifications that are sent when thresholds are reached, you can resolve any issues that emerge.
Queue full percentage alert
In this alert, a fixed percentage is defined as a current queue depth threshold. When the percentage of the queue's current depth has reached to its maximum percentage, an alert is generated. Similar to the current queue depth threshold, you can define the alert condition based on the queue's full percentage. For example, an alert notification is created when the current queue depth percentage is greater than 25%.
Queue messages in alert
This metric shows the number of messages that are dropped into the queue that allows you to detect whether the messages are flowing into the queue. The most common scenario is detecting and alerting the team if the order XMLs are not flowing into the Sterling™ Order Management System queue.
When the messages stop flowing into the queue, it is critical that you are notified. You can then act to ensure that the message-producing system is up and running and resolve any issues.
Queue messages out alert
This metric shows the number of messages that are consumed from the queue during a window. This allows you to detect whether the messages are flowing out of the queue. The most common scenario is detecting and alerting the team if the dropped order XMLs are not consumed from the Sterling Order Management System queue for downstream processing.
When the messages stop flowing out of the queue, it is critical that you are notified. You can then act to ensure that the message-consuming system is up and running and resolve any issues