Collecting and publishing data from the WebSphere MQ accounting and statistics messages

A WebSphere MQ queue manager can be configured to produce, at regular intervals, accounting data messages, and/or statistics data messages for the queue manager and/or the objects on that queue manager. The TrueSight Middleware and Transaction Monitor monitoring extension for MQ (qpmon) can be (optionally) configured to consume these messages and publish the contained data within during the monitoring cycle. When the extension goes to consume these messages, it consumes all the available messages in the order they were produced, updates the relevant attributes with the new data, and calculates new values for the daily total attributes.


The daily total accounting and statistics attributes for the queue manager and other objects are reset at the same time that channel totals are reset. Which by default happens at midnight on the machine where the extension is running, but this time can be configured via the ResetTotalsTime preference.

The collecting and publishing of the data is controlled by two extension preferences, ProcessMQAcctMessages and ProcessMQStatMessages. These preferences can be set at the extension default level, in which case the setting applies to all queue managers monitored by that agent. Either may also be set more specifically at the queue manager level.


Setting the monitoring extension preference instructs the extension to collect the accounting and/or statistics messages produced by the queue manager, but does not configure the queue manager to produce such messages, how often to produce them, for which objects they should be produced, nor what level of detail the messages should contain. These settings are specific to, and controlled by the IBM MQ product, please refer to the IBM documentation for details. The rest of this section assumes a certain level of familiarity with this IBM MQ feature.

Both preferences are disabled by default, to avoid an increase in the memory footprint of the agent, monitoring extension and topic server, for users that are not actually using the feature. When either or both of these preferences are enabled, more memory will be used by the agent, extension and topic server processes, for all queue managers monitored by the agent where the preference is enabled, regardless of whether or not MQ is producing the accounting and/or statistics messages. Because the amount of monitored attributes is doubled when these preferences are enabled, the memory required by the Topic Service may also need to be doubled in size. 

When using either or both of the MQ Accounting or MQ Statistics features, you may want to load the optional Event/Policy Packs with mqsimport. These files are located in Samples\EventPacks\WMQ under the service installation directory, and are named:

  • ReadMe.txt

The Accounting and Statistics tabs in the Monitor Console show the effective state of the preference for the object. If the preference is not enabled, the following visual elements will be displayed:

  • The value displayed for the preference will be "Off" or "Pending Restart".
  • The will be a grey rectangle visible under all the displayed attributes, indicating that the values are not being updated.
  • The "stale data" symbol (large question mark) is overlaid on the view.
  • Some text will be displayed at the top of the view, indicating why the values are not being updated, examples below.
    • The preference ProcessMQAcctMessages is not currently enabled for the monitoring extension for IBM MQ on this agent or queue manager, these attributes will not be updated and may display stale data.

    • The preference ProcessMQStatMessages is not currently enabled for the monitoring extension for IBM MQ on this agent or queue manager, these attributes will not be updated and may display stale data.

When the preference is changed to On, the monitoring extension will start looking for the MQ messages on the next sample interval, and will begin publishing data. If no accounting or statistics data messages were collected, then zeros will be published for the relevant values, as shown below.

When you change the preference for an active monitoring extension instance, on the next monitoring cycle, the extension will restart all of the monitoring sub-tasks, in order to immediately reduce the overall memory footprint. 


All of the memory consumed by the feature cannot be released fully back to the operating system until both qpea and qpmon are fully stopped and restarted, with the preference set to disabled.

In addition, restarting the monitoring sub-tasks will cause a delay in the next sample interval for all extensions connected to this agent, and the agent may be too busy to respond to further preference changes while the current preference change is being processed.

To make it easier to detect this situation, the value attribute for the preference takes on the value "Pending Restart" (the numeric value is 1), until qpmon is fully restarted. Note that the qpmon extension has no way of knowing whether or not qpea has been fully restarted.

The topic service also has to be restarted in order to fully reduce the memory footprint, but this is only significant when disabling one or both of the preferences on a wide scale. One such scenario would be if you turned either or both of these preferences on via a policy for a large number of agents, and then decided to turn it back off.

Was this page helpful? Yes No Submitting... Thank you