When publishing MQ facts with WorkGroup Server 10 (WGS 10), the first thing to consider is which facts you are publishing. If you do not have sensors that use a specific object, such as namelists, do not activate facts for it. See Controlling Facts that are published in WGS 10 for additional discussion on that topic.
Data collected is cached, visible in the GUI interfaces, and optionally published as facts and simultaneously.
Data collection concepts
The key thing to consider is the data collection activity. The data collected by the WGS has 2 main types. The first type of data to consider is status metrics which change frequently, such as queue depth, input and output open counts, channel status, sequence number, etc. These need to be frequently collected and published. The other type of data is configuration data which change infrequently or may never change. Because these 2 types of data behave so differently, there are 2 individual intervals defined and the facts they produce updated at those times.
These settings can be found on the Other Options property tab for the WGS in Enterprise Manager.
MQ object status refresh interval controls the frequency for data that changes all of the time, and defaults to every 30 seconds. Thus, every 30 seconds, the current status of objects will be refreshed. 30 seconds is a good frequency for this data to ensure that updates like queue depth are up to date. There are other factors, such as events or user queries that can cause individual objects to update on demand.
MQ object refresh interval controls the frequency for the more static data and defaults to every 600 seconds. When requesting this data, the WGS sends a request to MQ asking for changes since the last interval. The default of 600 seconds is a good value to start but depends largely on how dynamic the environment is, the maximum time you are willing to wait before a change is reported and whether changes are being made using Nastel Navigator or external tooling. Increasing the value decreases load on the MQ Server as that is the primary cost in identifying these changes. For stable environments, even once an hour may be sufficient. Actions such as creating a queue that is triggered by Nastel components are immediately recognized. This incremental discovery can be triggered manually if needed.
Data update and expiration
A third interval on this tab, the fact republish rate controls a periodic update of facts the WGS has collected. This works the expiry interval to make sure facts that are no longer available are removed. For example, if an object has been deleted, since there are no facts to publish, it will no longer be updated. As another example, if a queue manager or node is stopped, no facts other than the queue manager status are maintained in the WGS so these also stop publishing. By default, this interval is 30 seconds, which means that for active objects, the most recent data will be published at least every 30 seconds. The fact expiry interval controls how quickly objects are removed from the published facts. The default for the expiration is 90 seconds. As an example, if a queue were deleted at time 0, its facts would stop publishing, since it no longer exists and it would be removed 90 seconds later. 90 seconds allows for delays in update times due to system load. The example below expires all facts after 90000 milliseconds (90 seconds) except for DBSTATS facts.
Understanding your fact publishing behavior
The total number of facts published and the publishing rate are available in the CEP system metrics. To locate these facts, expand the SYSTEM folder under the CEP Server hosting the WGS. Expand SYSTEM and then your cep-server_Facts and expand the folder facts, then Services, and finally the name of your WGS expert. A number of different metrics are published every 30 seconds.
These are several of the key ones
- fact_publish_rate_per_sec - the rates that facts were published across the interval (number of facts/interval time)
- facts_current - The total number of facts currently under the WGS
- facts_published - the total number of facts that have been published during the interval
- facts_updated - the number of publishes that updated an existing fact during the interval
- facts_created - The total number of new facts created during the interval
- facts_cleared - The total number of facts that expired during the interval
In addition to the current value, the derived metrics can be useful to understand the behavior. See this article on interpreting derived metrics.