Share This:

Introduction


One of the five pillars of Application Performance Management (APM) is:


Component deep-dive monitoring in application context


What does “Component deep-dive monitoring in application context” mean?  Simply stated, it means having the ability
to drill-deep into the components of an online transaction.  But what are the components?  The components are
perhaps an HTTP server (aka web server), an application server, or perhaps WebSphere MQ?  (Check here https://communities.bmc.com/community/bmcdn/bmc_for_mainframes_and_middleware/middleware/blog/2013/08/19/what-is-middleware for more about WebSphere MQ).


In this article we will assume we need to monitor WMQ.  We now need to decide; agent or agentless?  Meaning, do we
use an agent or go agentless for the drill-deep monitoring?  With BMC Middleware Management (BMM), BMC offers
both agent support and agentless support for WMQ monitoring.


That is the focus of this paper, explaining the virtues of how each BMM solution approaches agent and/or agentless
support.  We will be covering two products in the BMM solution set:


BMM-Administration
BMM-Monitoring


BMM-Administration – Agentless


BMM-Administration is the industry leader solution for WMQ/TIBCO administration (adding, altering, deleting objects). 
As extra value, it offers ultra-light agentless monitoring of WMQ objects via a WMQ client connection.  Many times this
ultra-light WMQ monitoring is just enough for resource restrained managed systems.


The ultra-light agentless WMQ monitoring offered by BMM-Administration is manifested in the creation and viewing of
events. Think of an event as you would an alert. There are about two dozen of these events that BMM can detect and
alert on to specific WMQ objects within the managed system.  These are the events monitored by BMM-Administration:


1. Queue more than N percent full
2. Queue Manager not accessible
3. Message in DLQ
4. Queue Full
5. Command Server Down
6. XMT queue not serviced
7. Channel retrying and XMIT queue not empty
8. Channel retrying Channel in doubt
9. Channel stopped
10. Queue has more than N messages
11. Queue has more than N messages and no readers
12. Queue is more than N percent full and has no readers
13. Queue has less than N readers Queue has less than N writers
14. Server conn channel has more than N running instances
15. Total running channel count is more than N
16. XMIT queue has more than N messages
17. XMIT queue is more than N percent full
18. First message on queue waiting more than N seconds
19. Oldest message on queue waiting more than N seconds
20. Oldest message on XMIT queue waiting more than N seconds
21. Trigger monitor is not running
22. Channel initiator is not running

 

BMM-Administration monitors WMQ on an exception basis via events.  Since BMM-Administration does not have a
database of performance metrics, there is no performance history kept.  In other words, you cannot tell the queue
depth of a queue yesterday at noon.  But you can tell if a queue’s depth was over a predefined threshold yesterday at
noon; by reviewing the events from that time frame.

 

For event notification, BMM-Administration provides two other methods for event notification:


1. Email – Via a POP3 SMTP server
2. Trap – SNMP datagram(s)


A popular misconception of agentless monitoring is there is less overhead.  This is partially true in that there is no
agent processing (CPU and memory usage) on the WMQ platform.  However, there is still overhead (agentless or
agent) to WMQ itself.  WMQ resource consumption is still going to increase (compared to no monitoring), because it
will be processing the commands BMM puts on the WMQ command server.

 

The most popular reason people choose agentless monitoring is because, there is no software to distribute, install, and
maintain on each server running WMQ.  Also the user does not have to worry about the agent being compatible with
the version of WMQ.  Many times after IBM announces a new version of WMQ, you will have to wait for the vendor to
release an agent to be compatible with the new release of WMQ.

 

An agent running on the WMQ platform requires OS level and MQ level security to run.  These security requirements
can be tedious to implement and maintain.  With agentless support, these agent related security requirements are not
needed.

 

Another semi-popular reason to think about agentless monitoring is to consider the platform running WMQ.  Is the
platform a supported WMQ platform but not supported by a vendor’s agent (such as Windows XP)?  You are
somewhat forced to consider agentless monitoring, because there is no agent available.

 

BMM-Monitoring – Agent


Of all the agent verses agentless configurations, the BMM-Monitoring agent configuration is the most robust option.
 
Since BMM-Monitoring has a backend database for storing MQ performance metric history, a user can go back and see
for example; the queue depth of a target queue yesterday at noon.

 

An agent allows an authorized user to issue WMQ commands such as starting a queue manager or starting an WMQ
command server.

 

An agent allows for the collection of hundreds of WMQ performance metrics.  All of these metrics can have associated
thresholds set (verses only 22 out of the box pre-defined events for BMM-Administration).

 

Agent support has a direct native integration with BMC Proactive Performance Manager (aka Patrol).  This integration
allows all BMM data and events to feed natively (no SNMP traps) into BPPM.

 

An The BMM agent is intelligent because it will only send in values to parameters that have changed since the last
interval.  This means if a queue depth has not changed since the last interval, the agent will not send a new value. 
This intelligence can significantly cut down on network overhead (as compared to agentless support where all values
are sent at every interval).


Agent based monitoring requires more security/access on the monitored platform.  Typically a running process (agent)
requires possible access to system files, WMQ files, and some degree of WMQ authority.


With the BMM-Monitoring solution, a customer is technically positioned to exploit BMM-Application Transaction Tracing. 
This is because the BMM-Monitoring agent is the same agent used by BMM-Application Transaction Tracing, just with a
different BMM extension loaded into the agent.

 

BMM-Monitoring – Agentless


The most popular reason people choose agentless monitoring is because, there is no software maintenance to install
on each agent running with WMQ.  Also the user does not have to worry about the agent being compatible with the
version of WMQ.  Many times after IBM announces a new version of WMQ, you will have to wait for the vendor to
release an agent to be compatible with the new release of WMQ.


A popular misconception of agentless monitoring is there is less overhead.  This is partially true in that there is no
agent processing (CPU and memory usage) on the WMQ platform.  However, there is still overhead (agentless or
agent) within WMQ itself.  WMQ resource consumption is still going to increase (compared to no monitoring), because
it will be processing the commands BMM puts on the WMQ command server.  There is still agent processing (CPU and
memory usage) on a platform somewhere, just not on the managed platform.

 

Agentless monitoring is popular because many people perceive there are no agents involved in monitoring.  Yes, it is
true no agents operate on the monitored platform.  However, there is an agent/process running somewhere
consuming resources.  So please do not slip into believing agentless monitoring is free (i.e. no resources used).  The
agentless processing is accomplished on a platform external to the platform running WMQ.  This external platform can
be Windows, Linux, or AIX.  The WMQ platform can also be Windows, Linux, or AIX.  Different operating
systems/hardware platforms represent data in different ways. For example, string data may be in a different code page
and numeric data may be represented in a different byte order. These differences will cause the collected performance
data to be converted, some portions by WebSphere MQ, some portions by BMM. There is a performance cost
associated with such conversion. To avoid extra work, it is recommended that you deploy your agentless processes on
operating systems that have similar data representation to the target operating system(s)/hardware platform(s)
wherever possible.


Some configuration features found in the agent-based solution are not available in an agentless configuration.
When running agentless, there is no way to issue commands on the target system, which means that certain
WebSphere MQ operations cannot be carried out. Therefore, the following features are not available with the
agentless solution:

1. Delete Queue manager
2. Start/Stop Queue Manager
3. Start Command Server
4. Start Trigger Monitor via runmqtrm command
5. Start Channel Initiator via runmqchi command
6. Start Channel Listener via runmqlsr command
7. Display/Configure Object Security via dspmqaut/setmqaut
8. Service Control (amqmdain)
9. MQ Installation Information
10. MQ Environment Information
11. Discard Broker Resources
12. Set MQM Installation
13. Display MQ Version

 

It is important to understand that agentless monitoring may also require more network bandwidth than agent-
based monitoring. This is because all WMQ management traffic goes (both ways) over the network connection.
With an agent-based solution, only data values that change between sample intervals are sent across the
network by the agent on the monitored WMQ host.

 

A target monitored platform may reside inside a DMZ, meaning a BMM agent could have issues communicating
back to the central BMM server.  This condition may require an agentless approach to BMM-Monitoring.

Sometimes the BMM central server supporting all the remote clients (used to manage agentless servers), may
have a limit on the maximum number of remote clients that can be supported.  This means you may have to
add resources to support more agentlessly managed platforms.

 

One the biggest drawback to agentless monitoring of WMQ, is the monitoring is considered “in-band”.  In band
means the delivery mechanism to monitor WMQ is WMQ itself.  In the vernacular, how can you monitor WMQ if
the WMQ resource (server conn channel) itself is down?  Granted server conn channels rarely go down, but at
least this potential issue should be mentioned.

 

BMM-Monitoring – Hybrid Monitoring – Agent and Agentless Together


This approach offers the best of both worlds.  For your central corporate WMQ servers you get robust full-bodied WMQ
monitoring with agents.  For your tightly constrained servers, you get the light to ultra-light monitoring with agentless
WMQ monitoring.


You Make the Call


You make the call; agent or agentless?  As with most things in life, there are pros and cons.  There are tradeoffs (CPU,
memory, network bandwidth…) for each approach. Hopefully this paper has helped explain all the BMM-Monitoring
options available for WMQ monitoring.