Determining whether to use agent-based or agentless monitoring
Agents and their extensions are typically installed on the hosts that run the monitored applications. However, in most cases, you can choose whether to install the agent and the extensions on the host that runs the applications, or on a host that is separate from the application.
- Local agent-based monitoring and configuration: An agent and extensions are installed on each monitored WebSphere MQ server.
- Remote (agentless) monitoring and configuration: The agent and the extensions are installed on a computer that is separate from the monitored application.
In both deployment scenarios, the agent and the extensions are installed on the same host computer and the agent communicates with the Topic Service.
Advantages and disadvantages of local (agent-based) monitoring
Only data values that change between sample intervals are sent across the network by the agent on the monitored host.
Advantages and disadvantages of remote (agentless) monitoring
Following configuration, agentless monitoring can significantly reduce administration efforts because no software is required to be installed or maintained on the monitored platform.
Advantages of remote monitoring
- Updates to the Agent and MQ extensions need only be performed at the central location of the Agentless Services rather than on individual systems.
- With this remote monitoring method, all of the monitoring features found in the agent-based solution are available.
Disadvantages of remote monitoring
- Agentless monitoring might require more network bandwidth than the traditional agent-based solution. This is because all WebSphere MQ PCF traffic goes over the network connection.
- Some configuration features found in the agent-based solution are not available in an agentless configuration. During agentless monitoring, it is not possible to issue commands on the target system, which means that certain WebSphere MQ operations cannot be executed. For this reason, the following TrueSight Middleware Administrator (Monitor Edition) features are not available with the agentless implementation:
- Start/Stop Queue Manager
- Delete Queue manager
- Start Command Server
- Start Trigger Monitor via runmqtrm command
- Start Channel Initiator via runmqchi command
- Start Channel Listener via runmqlsr command
- Display/Configure Object Security via dspmqaut/setmqaut
- Service Control (amqmdain)
- MQ Installation Information
- MQ Environment Information
- Discard Broker Resources
- Set MQM Installation
- Display MQ Version
Additional configuration considerations with remote monitoring
With an agent-based solution, only data values that change between sample intervals are sent across the network by the agent on the monitored host. Because of this fact, it is recommended that you use agentpref to increase the WebSphere MQ Monitor sample interval for the Agentless Services to a minimum of 120 seconds.
While a single Agentless Service set can handle a significant number of WebSphere MQ servers, it might be necessary to configure additional servers to run additional Agentless Service sets. BMC recommends that you run each additional Agentless Service set on its own physical or virtual server. The following theoretical maximum limitations per service set exist:
- Windows: 60 queue managers per Agentless Service set.
- AIX: 500 queue managers per Agentless Service set.
- Linux: 500 queue managers per Agentless Service set.
However, the need to add additional Agentless Services varies significantly among environments and is based on your total number of monitored objects and your sample interval. You should monitor the CPU and memory consumption on your server to determine your own realistic maximum.
It is possible to configure client connections and PCF commands to MQ system types and versions other than those supported by TMTM Agents. Such configurations are not supported by BMC, and you configure them at your own risk. Also, the failure of the server connection channel, MQ LISTENER, queue manager, or the network are indistinguishable to the Agentless Services. This dependence on MQ to monitor MQ has broad implications for the clarity of alerts and some monitored properties. Consider these implications carefully when using an agentless configuration.
With the following exceptions, agentless monitoring is supported when the target IBM MQ queue manager is installed on a platform where the agent-based MQ monitoring extension is supported:
- i5/OS is not supported
- OpenVMS Itanium is not supported
- TPF will not work
- z/OS will not work
You can implement agentless monitoring on unsupported platforms at your own risk. However, defects and issues are accepted only if they can be replicated on a supported platform.