Detecting/Alerting on poisoned queues for IBM MQ

One of our top 4 banking customers in Australia had a Sev 1 incident last week, where their Internet Banking was down for 1 hour due to a poisoned queue. This was not detected by any monitoring tool and took some time to get to the root cause and repair. 

Upon investigating into the matter I understood that Instana would have been able to alert on such incidents based on the message attribute BackoutCount, keeps track of the number of times the message was backed out to the queue. According to this article, Each time a message is backed out to the queue, the message attribute BackoutCount field (in the MQMD) is incremented by MQ itself. This means that the next time the message is GOT from the queue the BackoutCount field will be greater than zero (default value is 0).

Upon checking with the (issue detection team; link to the slack threat provided), it was determined that the message attributes are extracted as text fields, hence checking for BackoutCount > 0 condition is not possible. Speaking to MQ SMEs, I learned that BackoutCount “does not equal" 0 should not implicate a poisoned queues as some times on the second attempt the message is retrieved. Hence the recommendation was to let the customer decide what the threshold should be for BackoutCount. 

So the ask here is for the BackoutCount field to be extracted as an numeric/integer field so the numeric operators could be applied in event conditions.