MQ Monitoring agent: remote monitoring on the MQ Appliance environment

Body

The general approach to monitor a queue manager in MQ Appliance is to configure an ITCAM for WebSphere MQ monitoring agent on another Linux, AIX or Windows system to remotely connect to the queue manager and gather information.  ITCAM for WebSphere MQ Monitoring does not currently run on MQ Appliance.
 

Prerequisites for system where ITCAM agent will be running:

1. ITCAM Agents for WebSphere Messaging Version 07.30.00.00 or above installed

See the link below for details about the latest installation level, v07.30.01.00:
http://www-01.ibm.com/support/docview.wss?uid=swg24040581

2. WebSphere MQ Client   

See the link below for details:
http://www-01.ibm.com/support/docview.wss?uid=swg24037500

 

Setup on system where agent will be running:

For each queue manager to be monitored:
1) Create an instance of the WebSphere Monitoring agent for each queue manager that will be monitored.
On Windows, in "Manage Tivoli Enterprise Monitoring Services". Select "WebSphere MQ Monitoring" primary task, right click, "Create Instance".
On Unix, issue itmcmd config with "-o <instance_name>", eg. "./itmcmd config -A -o <instance_name> mq".
instance_name is a name that can uniquely identify this instance, such as queue manager name.

2) Modify the configuration file of the agent instance to enable remote monitoring by setting the following parameters:

SET MANAGER NAME(<qmgr_name>) REMOTE(YES)
SET AGENT NAME(<agent_ID>)
where:
qmgr_name is the name of the queue manager on the MQ appliance to be monitored
agent_ID is an id to identify the queue manager location, such as the host name or IP address of the appliance.

On Windows, configuration file is mq_<instance_name>.cfg in <ITMHOME>\TMAITM6_x64 for Win64 or <ITMHOME>\TMAITM6 for Win32 . Note that you will be asked to edit this file when configuring.
On Unix, configuration file is <hostname>_mq_<instance_name>.cfg  in <ITMHOME>/config.

 

Setup on queue manager to be monitored:

SVRCONN channel and listener definitions

For each queue manager to be monitored, there must be SVRCONN channel and listener defined and started.  For example,

M2000# mqcli
M2000(mqcli)# runmqsc <qmgr_appliance>
> DEFINE LISTENER(<listener_name>) TRPTYPE(TCP) PORT(<port>) CONTROL(QMGR)
> DEFINE CHANNEL(chl_name) CHLTYPE(SVRCONN) TRPTYPE(TCP)
> END

Note that for agent to be able to access remote queue manager, the listener must be started.  CONTROL(QMGR) will ensure that listener is started when queue manager starts.

 

Create CCDT (Client Channel Definition Table File):

The CCDT must reside on the system where ITCAM agent is running and must have a CLNTCONN definition for EACH queue manager that an agent instance will be monitoring.  The CCDT can be created on any system where WebSphere MQ is installed and then transferred (in binary mode) to the system where the agent is going to run.   To remotely monitor multiple queue managers from the same system with multiple agent instances, you must create one CCDT (AMQCLCHL.TAB) that has all CLNTCONN definitions needed.  Note that the CCDT must be at a version less than, or equal to that of the client.  For example, if CCDT was created using WebSphere MQ V8, then you must be running WebSphere MQ V8 client on the system where the agent is running and using the client connection.

1) Use "runmqsc -n" or "runmqsc <any active qmgr> to generate CCDT and transfer to system where agent is going to run (if different system)

If  WebSphere MQ 8.0.0.0 or above is installed on a system that can be used, you can create the client channel definition table file (AMQCLCHL.TAB) for remote
monitoring by using "runmqsc -n". The -n option modifies the runmqsc command to not connect to a queue manager. This option requires the client libraries to be installed. If they are not installed an error message is issued. MQSC commands entered in this mode are limited to managing the local channel definition file.

Otherwise, issue ""runmqsc <any active qmgr>".

2) Once runmqsc issued, for EACH queue manager that is going to be monitored, i.e. each agent instance, issue a DEFINE CHANNEL,
 
DEFINE CHANNEL(<chl_name>) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(’<host_IP>(<port>)’) QMNAME(<qmgr_appliance>)
where:
<qmgr_appliance> is the name of the queue manager on the MQ Appliance
<port> is the port number that is used by the listener
<chl_name> is the name that matches the SVRCONN definition on the qmgr to be remotely monitored
<host_IP> is the IP address of the MQ Appliance the queue manager is running on

3) If this is not on the system that the agents are going to run on, then transfer the CCDT (AMQCLCHL.TAB) to agent system in binary mode.

If transferring from MQ Appliance you can use File Management in IBM MQ Console UI to manipulate/copy files.  Or for linux/unix:
M2000#config
M2000(config)#copy mqbackup:///AMQCLCHL.TAB
scp://username@ipaddress/[/]directorypath

The AMQCLCHL.TAB location may vary based on version,  MQ configuration, etc, but default location is:
   On Windows, c:\ProgramData\IBM|MQ\qmgrs\<qmgr_name>\@ipcc
   On Unix, /var/mqm/qmgrs/<qmgr_name>/@ipcc

Refer to the WebSphere MQ documentation for more details on CCDT and location if needed:
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q016730_.htm?lang=en

4) Place AMQCLCHL.TAB in directory where agent is running.

 On Windows: <ITMHOME>\TMAITM6 on Win32
                       <ITMHOME>\TMAITM6_x64 on Win64
 On Unix: <ITMHOME>/<arch>/mq/bin

 

Special Considerations for HA queue managers in MQ Appliance environment

If monitoring HA queue managers in MQ Appliance environment, you have 2 options:

OPTION 1 - One ITCAM for WebSphere MQ Monitoring Agent Instance that connects to whichever system that has the active queue manager

The steps outlined above should be followed, with one change.  In step (2) of "Create CCDT" section, create 2 definitions for the HA queue manager, one for each host_IP:

DEFINE CHANNEL(<chl_name>) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(’<host_IP1>(<port>)’) QMNAME(<qmgr_appliance>)
DEFINE CHANNEL(<chl_name>) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(’<host_IP2>(<port>)’) QMNAME(<qmgr_appliance>)
where:
<qmgr_appliance> is the name of the HA queue manager on the MQ Appliances
<port> is the port number that is used by the listener
<chl_name> is the name that matches the SVRCONN definition on the qmgr to be remotely monitored
<host_IP1> is the IP address of one MQ Appliance the queue manager may run on
<host_IP2> is the IP address of the other MQ Appliance the queue manager may run on

OPTION 2 - Separate ITCAM for WebSphere MQ Monitoring Agent Instance for each appliance that the queue manager can be running on.  

At this time, with ITCAM V730, the inactive/standby queue manager will not have any data but "Queue Manager Not Available" in queue manager status.  However, users will be able to see which appliance the queue manager is active on.      

To run remote agents on Unix, one for each appliance/qmgr in HA group:

To set up this option, the steps outlined above should be done for each appliance/qmgr.  The CCDT that is used for the different appliances must only contain the CLNTCONN for that appliance.  So separate installation and CCDT must be created for each one.      

To run remote agents on Windows, one for each appliance/qmgr in HA group:   

To set up this option, the steps outlined above should be done for each appliance/qmgr.  Only one installation is needed, with one agent instance for each appliance/qmgr.  The following differences apply when creating CCDT table:
1) One CCDT for each appliance/qmgr must be created.  The CCDT used for the different appliances must only contain the CLNTCONN for that appliance.

For example:
   SET MQCHLTAB=APPL1.TAB     
   Issue "runmqsc -n"
   From runmqsc, issue "DEFINE CHANNEL(<chl_name>) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(’<host_IP1>(<port>)’) QMNAME(<qmgr_appliance>) "    

   SET MQCHLTAB=APPL2.TAB     
   Issue "runmqsc -n"
   From runmqsc, issue "DEFINE CHANNEL(<chl_name>) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(’<host_IP2>(<port>)’) QMNAME(<qmgr_appliance>) "                                        

 2) Copy both APPL1.TAB and APPL2 TAB to agent directory:
    
     <ITMHOME>\TMAITM6_x64 on Win64
 
 3) Edit the .ini file for each agent instance to specify the renamed table file for the MQCHLTAB value.

For example, after you create two WebSphere MQ Agent instances, which are instance1 and instance2, two files, kmqcma_instance1.ini and kmqcma_instance2.ini, are created in the C:\IBM\APM\TMAITM6_x64 installation directory. Specify the MQCHLTAB value as follows in each .ini file (or use Manage Tivoli Enterprise Monitoring Services, select Advanced, Edit Variables):
In the kmqcma_instance1.ini file: MQCHLTAB=APPL1.TAB
In the kmqcma_instance2.ini file: MQCHLTAB=APPL2.TAB

 4) Open the Windows registry editor by typing regedit in the command line. Locate the following key of the MQCHLTAB and change it from AMQCLCHL.TAB to the proper value.

For example:
HKEY_LOCAL_MACHINE\SOFTWARE\Candle\KMQ\Ver730\ instance1 \Environment
MQCHLTAB= APPL1.TAB
HKEY_LOCAL_MACHINE\SOFTWARE\Candle\KMQ\Ver730\ instance2 \Environment
MQCHLTAB= APPL2.TAB

where , instance1 and instance2 are the two WebSphere MQ Agent instance names.

Configure Channel Authentication Settings

Make sure that channel authentication settings are configured properly for the user ID that is used to start the agent instance.  This will vary depending on queue manager settings for CONNAUTH and CHLAUTH.  A few things to consider:

1) With WebSphere MQ version 8.0.0, the default channel authentication specifies CONNAUTH of SYSTEM.DEFAULT.AUTHINO.IDPWOS.  The default AUTHINFO definitions has CHKCLNT set to REQADM.  If this is the setting used, you must create a non-privileged user ID on the system where your queue manager is running. After you create the non-privilege user ID, you must grant the necessary WebSphere MQ OAM authorities to this ID as documented at:

   http://www.ibm.com/support/knowledgecenter/SSRLD6_7.3.0/kmq_userguide/t_grant_oam_auth.html

Note that setmqaut is not available on MQ Appliance so IBM MQ Console or SET AUTHREC in runmqsc can be used to grant this authorization.

2) If queue manager has CHLAUTH(DISABLED), then MCAUSER of authorized user can be specified in the SVRCONN definition that is used for client connection.

3) Our agent client connection does not currently pass any password, so CHCKCLNT(REQUIRED) will not work properly. 

 

 

 

Subscribe and follow us for all the latest information directly on your social feeds:

 

 

  

Check out all our other posts and updates:
Academy Blogs:	https://goo.gl/U7cYYY
Academy Videos:	https://goo.gl/TLfMoF
Academy Google+:	https://goo.gl/HnTs0w
Academy Twitter :	https://goo.gl/AhR8CL