DX Application Performance Management

Hello team, 

I would like to ask you about the following, if it is possible to detect with CA APM in the monitoring of these components. And if you can, as CA APM does.

1. Visualize at what point the transaction failed: in the flow, in the queue. If it is a flow that in turn calls others, we can identify in which of them it fails.

2. Connection errors of a flow to BD.

3. Transaction queuing display
4. Notification when a queue is about to be filled, the message exceeds the defined size or when it exceeds the maximum number of messages accepted by the queue.

Thanks for the help, it is the first time that I would be monitoring these components.

RB

Hi Richard,

We have IBM MQ 9 with IIB 10.0, but we have also had MQ 6, 7, 8 with MB 6, 7, 8 and only recently moved to IIB 10.0.

Message Broker / IIB

1. Visualize at what point the transaction failed: in the flow, in the queue. If it is a flow that in turn calls others, we can identify in which of them it fails.

2. Connection errors of a flow to BD.

3. Transaction queuing display

The MQ agent can see the message flows

To understand the scope of metrics in context of the broker/IIB, it might help to understand how APM, namely the MQ agent queries for data.  The agent will use the MQ Explorer API to poll for metrics and, in case of Broker, will poll for performance metrics that Broker will publish to an MQ Queue.  In the case of IIB, the IIB agent will use either the web or API interfaces to request performance data.  That is key in this discussion on which and type of metrics can the agent gather/request, performance data.  

Now, within a broker flow, (application or transaction), there is a way to have Broker generate a XML document and send it to the agent/collector with the business transaction metrics.  This is very specialized and have seen a third party offer a solution that would allow you to add a node to your broker flow to publish transaction metrics.  Depending on the level of details that are defined within the broker flow node, you might be able to see the failure point.  You might want to check in with the CA Services team to contract with them to help you with the integration details.

Message Queue 

4. Notification when a queue is about to be filled, the message exceeds the defined size or when it exceeds the maximum number of messages accepted by the queue.

Yes, the MQ agent is able to poll for current queue depth and you can create a metric grouping/alert based on the metrics.  Mind you, don't wild card within the metric expression where the metric expression returns more than 100 matches.  So don't do (.*)Request where you have hundreds of request queues.  

Hope this helps,

Billy

Hi Billy,

I presume you have to enable metrics on the IIB side to get that level of per-metric information.  I have created the queues using the runmqsc script, and see the applications (about a dozen in our case) but under each one the "Statistics Reported" is set to False.

I am receiving concerns from our IIB Middleware folks about the impact of enabling statistics, both in the short term, and the potential memory implications also of leaving them on permanently/long term.

Have you noticed much/any impact to perform from enabling statistics, and is this the only step I am missing to complete my component monitoring if I already have the queues there?

Thanks!
Lee

Hi Lee,

I worked with the middleware admin to balance out the frequency (delaytime) and the statistics being polled (minimum) and then described the alert behavior.  Basically if we are polling every 5 minutes, and an issue arises and then resolves before the polling period, there won't be any alerts.

There might be other settings/steps since it took us a bit to get all of the connections (SSL) configured, the user permission sorted out and then the communication jars sorted out to get the metrics.

Hope this helps,

Billy