236 IBM Tivoli OMEGAMON XE V3.1 – Deep Dive on z/OS
Figure 6-35 on page 232. The RKLVLOG for this Tivoli Enterprise Monitoring
Server instance will contain the KOS101I message:
KOSKFA00: KOS101I CMS SC52:CMS IS NOW THE SYSPLEX PROXY
As other Tivoli Enterprise Monitoring Server address spaces are started, they will
wait on the KLVGLOCK:{Plex name} resource as shown in Figure 6-36 on
page 233. Therefore, if the current sysplex proxy Tivoli Enterprise Monitoring
Server is stopped, the first waiting Tivoli Enterprise Monitoring Server will acquire
the exclusive enqueue and assume the sysplex proxy function.
Sysplex proxy recovery
If the sysplex proxy Tivoli Enterprise Monitoring Server fails, the “next” Tivoli
Enterprise Monitoring Server in the sysplex takes on the sysplex proxy status.
“Next” is determined by the start-up order of the CMSs within the scope of the
CMSs eligible (that is, not excluded) to perform sysplex proxy functions. The
other CMSs will redirect their information to the new sysplex proxy. Restart of the
original sysplex proxy does not modify the sysplex proxy processing.
Historical collection
The sysplex proxy Tivoli Enterprise Monitoring Server collects historical data to
Persistent Data Stores (PDS) files. If you have EPILOG historical collector
configured, it will also collect sysplex history. If the sysplex proxy fails over into
another Tivoli Enterprise Monitoring Server, the PDS files will be opened by the
new Tivoli Enterprise Monitoring Server to resume historical collection. However,
the EPILOG collector on the new Tivoli Enterprise Monitoring Server will not be
aware of these change. EPILOG must be recycled to activate historical collection
for sysplex information.
6.7.3 DASD threshold filtering
When a sysplex has a large number of images, and a large number of DASD
devices are shared, the volume of data that is normally sent to the sysplex proxy
can be extensive. The Candle Technology (CT) facility that processes the data
could be overwhelmed. The result is high CPU consumption and an apparent
storage creep condition.
In reality, most of the DASD metrics being collected are unremarkable. That is,
the information represents normal, well-behaved DASD activity rather than
abnormal conditions. DASD Threshold Filtering provides a mechanism for
indicating which devices are important, then collects metrics for just these
devices from all images. DASD Threshold Filtering uses the Situation Event
process to specify devices of interest.
Chapter 6. Working with Tivoli Enterprise Portal 237
Using the situation editor, you specify the inclusion criteria and the interval. The
inclusion criteria leads to the construction of a volume list that is sent to each
Tivoli Enterprise Monitoring Server, which should reduce the amount of
volume-related data. As a general rule, the DASD Threshold Filtering situation
should be simple and reasonable in order to achieve the best performance.
Avoid using the attributes System or Group Name.
The sampling interval is a balance between CPU consumption and data
fidelity. A shorter sampling interval will catch out-of-norm devices more
quickly at the cost of higher CPU consumption, but a longer sampling interval
may miss some devices of interest but require fewer CPU resources. Start by
using a sampling interval around 30 minutes and adjust it as required.
If a new Tivoli Enterprise Monitoring Server is added to a sysplex or a Tivoli
Enterprise Monitoring Server is recycled, stop and restart the DASD Filtering
Threshold situation. The device list constructed by the situation is distributed
to each z/OS image and maintained in storage. If the z/OS image comes
online after the list has been distributed, this image will send all of its DASD
information until the next volume list is built. Recycling the situation will reset
the list on all images.
Get IBM Tivoli OMEGAMON XE V3.1 Deep Dive on z/OS now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
