Co-Authors:

Sunny Tian(tianxing@cn.ibm.com) - Developer for Instana Integration, CP4MCM

YongHu Sun (sunyongh@cn.ibm.com) - Developer for Instana Integration, CP4MCM

Introduction

IBM MQ provides several configurations to enable high-availability solutions. You can set up your queue managers to work either with a high-availability manager, such as PowerHA® for AIX® (formerly HACMP) or the Microsoft Cluster Service (MSCS), or with IBM MQ multi-instance queue managers. On Linux systems, you can also deploy replicated data queue managers (RDQMs), which use a quorum-based group to provide high availability.  

Users need a way to monitor such complex MQ high-availability infrastructure, and current monitoring products don't support native (built-in) monitoring solutions. Instana MQ sensor also uses client-binding mode instead of local binding to monitor queue managers, so it cannot support native monitoring for such high-availability solutions.

However, this blog provides two tolerate support approaches for using Instana to monitor these IBM MQ high-availability solutions. Because all these MQ high-availability solutions have similar concepts and infrastructures, we will take RDQM as an example to explain the two monitoring scenarios.

RDQM Architecture

Here is the RDQM architecture, when one queue manager fails over on node 3, the queue manager on node 2 with the same name will take over the work from client 3.

Then let's see how Instana can be used to monitor this environment.

Prepare Instana environment

1. Install Instana Server as self-hosted by following the guide here.

2. Install Instana host agent in the public Kubernetes clusters by following the guide here. 

3. Configure IBM MQ Sensor to monitor RDQM Queue managers.

• This is the key step that will be introduced in detail in the following sections. You need to select one approach based on the scenarios and the expected monitoring results that you prefer.  

Scenario 1: Configure MQ Sensor to monitor remote RDQM queue managers by using the floating IP as one queue manager

Monitor the RDQM queue managers by using the floating IP as one queue manager. See the following example.

Select one Instana agent that is not on RDQM machines, which means the agent is on another box out of the 3 RDQM machines, and configure it to monitor the queue manager with the floating IP. In this scenario, user only needs to configure once –on the machine where the active queue manager is locate– and nothing else needs to be configured on the other boxes. Specify the host with the floating IP and the started listener port in agent configuration yaml file as follows. For more information, refer to the configuration guide here.

# IBM MQ

com.instana.plugin.ibmmq:

  enabled: true

  poll_rate: 60

  queueManagers: # Multiple Queue Manager instances can be specified for both local and remote. 

    RDQM1:  # RDQM Queue Manager Name

      host: '9.30.198.88'    # The FLOATING_IP of RDQM Queue Manager 

      port: '1414'   # The port of started listener 

      channel: 'SVRCONN'   # The server connection channel name

      username: 'user' # User ID to connect to MQ (optional)

      password: '***'  # User password to connect to MQ (optional)

      queuesRegex: '.*' # Regex for filtering queues (optional)

      availabilityZone: 'MQ_RDQM'  # RDQM Queue Manager Zone showed

 

By using such configuration, you will get the following monitoring result:

1. The monitored Queue managers will be always displayed as a separate box `QMgr@floating IP` in the MQ zone that you defined.
   

2. The queue manager will be always displayed as `QMgr@floating IP`, whether it is active or standby on the host or not. When the queue manager fails over, no events are triggered normally.

• Note:  If the failover time of the queue manager is longer than 1 minute, which is the MQ sensor default polling rate, the events "IBM MQ QueueManager is Down" will be triggered. After the queue manager on standby is running, this event "IBM MQ QueueManager is Down" will be closed.

3.  The historical data of the queue manager is persistent and retained in this `QMgr@floating IP` node, and you can check data all the time. 

• Note: If the failover time of the queue manager is longer than the default polling rate, you can see a breaking point in the chart at the switching time.

Scenario 2: Configure MQ Sensor to monitor each local RDQM queue managers by using the physical IP

Monitor the RDQM queue managers one by one with each Instana agent on each box.

You need to install the Instana agent on the each machine where the RDQM queue managers are located, and configure the agents to monitor each queue manager on each box. That is to say, monitor all the three RDQM queue managers locally, don't configure "host" and "port" for all the agents, let the agents discover by themself. If you use this local monitor way to monitor each queue manager, you don’t need to specify the host and port in the agent configuration yaml file as follows:

# IBM MQ

com.instana.plugin.ibmmq:

  enabled: true

  poll_rate: 60

  queueManagers: # Multiple Queue Manager instances can be specified for both local and remote. 

    RDQM1:  # RDQM Queue Manager Name

      channel: 'SVRCONN'   # The server connection channel name

      username: 'user' # User ID to connect to MQ (optional)

      password: '***'  # User password to connect to MQ (optional)

      queuesRegex: '.*' # Regex for filtering queues (optional)

In addition, to manage all RDQM boxes in the same zone easily, you are recommended to set "availabilityZone" in the agent configuration yaml file with your RDQM zone name. See the following screenshot. 

# Hardware & Zone

com.instana.plugin.generic.hardware:

  enabled: true # disabled by default

  availability-zone: 'RDQM-LOCAL'

For more information, refer to the configuration guide here.

You are also recommended to create an event to monitor Queue Manager offline with system rules as the following configurations, which can detect Queue Manager offline event more quickly.

By using such configuration, you will get the following monitoring results:

1. You can see clearly which queue manager is active and which queue manager is not active. The active queue manager will be shown on the machine, while the inactive one (standby or elsewhere) will be not shown on the machine.

2.  When it switches over, the new active queue manager will be shown, and the original queue manager will trigger the event that the queue manager is not active. If users need the event to be triggered when the active queue manager switchesover, see the following configuration to achieve this goal.

The event is triggered when RDQM queue manager switches over each time:

Event details:

3.  Each of the three queue managers has the data only when it is alive, and each node can show the data only when it is active.

• Note: The continuous historical data is not shown in one queue manager, but the sum of these 3 queue managers data is the full list.

Conclusion

Though currently Instana MQ sensor can't support native monitoring to show standby or elsewhere status, you can get the expected monitoring results by selecting one option from the described two scenarios.