Writer instructions

Page title

For most spaces, this page must be titled Space announcements.

For spaces with localized content, this page must be titled Space announcements l10n.

Purpose

Provide an announcement banner on every page of your space.

Location

Move this page outside of your home branch.

Guidelines

Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see MainView Middleware Monitor 9.2.

Architecture for agentless monitoring on WebSphere MQ

In a traditional agent-based installation, an agent (QPEA) and its WebSphere MQ extensions (QPMON and QPCFG) are set up to run on each monitored WebSphere MQ server host. In an agentless installation, QPEA/QPMON/QPCFG can be configured to run on a separate computer and remotely administer multiple WebSphere MQ servers from one set of processes.

To distinguish when QPEA/QPMON/QPCFG is run in a remote agentless configuration versus an agent-based setup, the term "Agentless Services" refers to the former configuration. The Agentless Services can be run on the same platforms as the other MainView Middleware Monitor (MVMM) services: Windows, Linux, or AIX.

Related topics

Agent-architecture

Enabling-Agentless-Service-monitoring-on-WebSphere-MQ

Different operating systems/hardware platforms represent data in different ways.

For example, string data might be in a different code page and numeric data might be represented in a different byte order. These differences cause the collected performance data to be converted, some portions by WebSphere MQ, some portions by the MVMM extensions. There is a performance cost associated with such conversion.

To avoid extra work, BMC recommends that you deploy your Agentless Services on operating systems that have similar data representation to the target operating systems/hardware platforms wherever possible.

 

worddavd94d0a874798d263ff32b1e6c7bb4ed7.png

When used in this configuration, MVMM utilizes the WebSphere MQ client bindings and the IBM WebSphere MQ MQCONNX call to connect to the remote WebSphere MQ queue managers via a CLNTCONN/SVRCONN channel pair. By default, the MVMM Agentless Services connect using the SYSTEM.ADMIN.SVRCONN server connection channel to each queue manager and send messages to the SYSTEM.ADMIN.COMMAND.QUEUE and retrieve replies from a dynamic queue created based upon the SYSTEM.MQSC.REPLY.QUEUE model queue. The actual names of the channel and reply queue can be changed. See the Agentpref Utility for details.

Because no BMC software is installed on the monitored MQ Server, the MQ Administrator must ensure that the specified queues and channel are defined and that the Agentless Services can connect to the monitored queue manager as a client and perform administrative operations. These operations include, but are not limited to:

  • Opening the required port in any firewalls
  • Verifying network connectivity and host resolution between the MVMM Agentless Services and the monitored queue manager
  • Ensuring that the MVMM Agentless Services have and are configured for any required SSL certificates, security exits
  • Ensuring that no MQ ChannelAuth rules block access to the target queue manager
  • Ensuring that the MVMM Agentless Services run under or are mapped to a user with full MQ administrative authority on the monitored queue manager

See the IBM documentation for details of establishing an MQ Client Connection.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*