Our event, accounting and statistics monitoring program, MQEV has a feature to raise alerts. They were initially designed to allow you to notify an MQ administrator of something untoward that has been discovered through an event message or with accounting and statistics data, but they actually serve a number of other purposes. This blog post is going to look at the various different ways you can make use of MQEV alerts.
- Notification to the MQ Administrator
This is the first, and perhaps most obvious use of alerts in MQEV. For example, upon receiving a Queue Full event, you might raise an alert to notify the MQ administrator of the problem. This could be accompanied by sending an email or text message, for example. In addition, MQEV publishes an MQ message when an alert is raised so that other programs can subscribe to them for speedy notification.**************************************************************** * Function for processing an event **************************************************************** func MQEVEvent() @objname = event.evobjname @objtype = event.evobjtype if (event.evreason = PERQDPFULL) ************************************************************ * Alert the MQ Administrator ************************************************************ ADD EVALERT TEXT('Queue High') CATEGORY(VIP) + EVOBJNAME('<@objname>') EVOBJTYPE(<@objtype>) + SEVERITY(SEVERE) REPLACE endif endfunc - Driving a script after some time passes
This example is something that is also shown in the MQEV manual. In this case you have noticed a situation that, if it remains for too long, is a problem. However, if it clears up quickly, there is no need to trouble the MQ Administrator. The example uses the receipt of a Queue High event. It raises an informational alert with a short expiry time, and if the Queue High status is still present, and has not been cleared with a subsequent Queue Low event, the expiration of the alert will drive code to notify the MQ administrator of the problem.**************************************************************** * Function for processing an event **************************************************************** func MQEVEvent() @objname = event.evobjname @objtype = event.evobjtype if (event.evreason = PERQDPHI) ************************************************************ * Add a temporary alert that will expire in 60 seconds ************************************************************ ADD EVALERT TEXT('Queue High') CATEGORY(QHIGHTEMP) + EVOBJNAME('<@objname>') EVOBJTYPE(<@objtype>) + SEVERITY(INFO) RETINTVL(60) REPLACE endif if (event.evreason = PERQDPLO) ************************************************************ * Remove both alert types, temp & final, wildcarded CATEGORY ************************************************************ REMOVE EVALERT TEXT('Queue High') CATEGORY(QHIGH*) + EVOBJNAME('<@objname>') EVOBJTYPE(<@objtype>) endif endfunc **************************************************************** * Function called when an alert expires **************************************************************** func MQEVAlertExpire() if (alert.category = 'QHIGHTEMP') @objname = alert.evobjname @objtype = alert.evobjtype ADD EVALERT TEXT('Queue High') CATEGORY(QHIGH) + EVOBJNAME('<@objname>') EVOBJTYPE(<@objtype>) + SEVERITY(WARN) REPLACE endif endfunc - Drive Code repeatedly
An extension of the above idea, is to use expiring alerts to drive code on a regular basis to check on something, perhaps a behaviour in MQ that isn’t able to be monitored by event messages. After checking the attribute, a new expiring alert, based on the one that just expired, is created, and round it goes again. The MonitorFunction() might also create alerts of the first type.**************************************************************** * Function: addEVAlert **************************************************************** func addEVAlert(Text, Category, RetIntvl) =mqev ADD EVALERT TEXT('<@Text>') CATEGORY('<@Category>') + RETINTVL(<@RetIntvl>) EVQMGR(<_qmgr>) + SEVERITY(INFO) REPLACE =mqsc endfunc **************************************************************** * Function called when we connect **************************************************************** func MQEVConnected() ************************************************************** * Initialise the expiring alerts that drive the monitoring fns ************************************************************** addEVAlert("Delay: 2 Hours", "DELAY.2HRS", 2 * 60 * 60) endfunc **************************************************************** * Function called when we an alert expires **************************************************************** func MQEVAlertExpire() if (alert.CATEGORY = 'DELAY.2HRS') MonitorSomething(...) * Now remake the same alert * addEVAlert(alert.TEXT, alert.CATEGORY, alert.RETINTVL) endif endfunc - Drive some code in an ad hoc manner
Again, in an extension to the above model, you could have code to run that is driven by an expiring alert, and could be driven in an ad hoc manner by an administrative command creating an alert with a very short expiry.**************************************************************** * Function called when we an alert expires **************************************************************** func MQEVAlertExpire() if (alert.CATEGORY = 'DRIVE.NOW') CheckSomething(...) endif endfuncThis code could be driven by an MQ administrator using the following command:
ADD EVALERT TEXT('Drive code') CATEGORY(DRIVE.NOW) + RETINTVL(1) SEVERITY(INFO) REPLACE - State Variable
When monitoring for situations using event messages or even issuing direct MQ commands, you can raise an alert for an MQ Administrator to take notice of what has been discovered. If the same situation is seen again, and the MQ Administrator has not yet noticed the previous alert, you may decide that you don’t need to contact him again. The existence of the alert in the system marks that he has already been notified. Once the MQ Administrator deals with the alert, he can delete it. The lack of an alert in the system would then mean that the script would notify him again if the situation subsequently arose.**************************************************************** * Function: AlertUser * Purpose: This function will alert the user in whichever way is * needed, for example, raise an alert, or send an email **************************************************************** func AlertUser(objname, objtype, category, alert_text) =mqev DIS EVALERT CATEGORY('<@category>') + EVOBJTYPE(<@objtype>) EVOBJNAME('<@objname>') + EVQMGR(<_qmgr>) if (_matches = 0) ************************************************************ * Send email to notify MQ Administrator * ************************************************************ system('email.bat "' + @alert_text + '"') else @id = EVALERT REMOVE EVALERT(<@id>) endif ************************************************************** * Always add a new replacing alert so that the date, and any * new text in the alert, is updated ************************************************************** ADD EVALERT TEXT('<@alert_text>') CATEGORY('<@category>') + EVOBJTYPE(<@objtype>) EVOBJNAME('<@objname>') + EVQMGR(<_qmgr>) =mqsc endfunc
As you can see, MQEV and its alerts are very flexible. Alerts can notify an MQ Administrator of an event within your MQ estate, and in addition can be used to control when those alerts might be raised.
The MQEV product is free for you to download and try out until June 30th 2020. You don’t even need to register any details to play with it. You can download it from our website.
All we ask in return is that in a week or two when you’ve played with it you send us an email telling us what you liked and what you didn’t like about it and perhaps what features you’d like to see in the future.
We look forward to hearing your comments. Please send them to support@mqgem.com.
Some event messages tell you something that you might like to act upon immediately. Others you might just want to keep an eye on, for example channel problems where channel retry will probably cover it.
How long should you keep event messages for?