106 IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments
Figure 4-21 Sorted list of attribute groups with number of monitoring server for collection
To benefit from this feature, you have to assign the agents to different monitoring
servers when implementing your environment. This feature can also be used to
temporarily shift agents to the data collection in certain situations. If you are
planning to use different collection parameters for a given attribute group on
different monitoring servers, these configuration actions have to be done as
separate actions through the historical collection configuration user dialog (that
is, not at the same time).
4.4.2 Configure multiple Warehouse Proxy agents
Multiple Warehouse Proxy agents has been supported since IBM Tivoli
Monitoring V6.1 Fix Pack 2, but Fix Pack 5 should be installed in order to use all
the features described here.
More than one Warehouse Proxy agent could be beneficial for the following
򐂰 Maintenance
When maintenance procedures (such as adding more memory, replacing a
disk, or defragmenting a filesystem) are applied on the machine where one
Warehouse Proxy agent is installed, other Warehouse Proxy agents can be
used to send the historical data to the Tivoli Data Warehouse database.
Note: A Technote explaining best practices for configuring multiple
Warehouse Proxy agents is available at the following site:
Chapter 4. Planning historical data collection in large scale environments 107
򐂰 Sharing the load
A large volume of simultaneous uploaded requests may negatively affect the
insertion rate if only one Warehouse Proxy agent is used. 5.5, “Tivoli Data
Warehouse performance” on page 151 advises how to set some Warehouse
Proxy tuning variables such as the number of export threads, the size of the
queue containing the historical exports, the batch option, or the database
itself when the Warehouse Proxy agent has to handle large data volumes.
Note that, if one Warehouse Proxy agent cannot handle all the historical
exports despite the tuning, the workload can be shared by installing multiple
Warehouse Proxy agents.
򐂰 Failover
Tivoli Monitoring 6.1 FP5 provides the ability to automatically send historical
uploads to a failover Warehouse Proxy agent when the communication to the
primary Warehouse Proxy agent is unavailable. However, this facility does
not provide load balancing or an automatic switch-back to the original
Warehouse Proxy agent.
Determining which Warehouse Proxy agent will act for which agent is based on:
򐂰 For an agent: which TEMS does it report to
򐂰 For a Warehouse Proxy agent: the list of TEMS it is related to for
warehousing purposes
The second relationship is set by the KHD_WAREHOUSE_TEMS_LIST
environment variable in the Warehouse Proxy agent environment file.
KHD_WAREHOUSE_TEMS_LIST is a space-separated, semi-colon-separated,
or comma-separated list of TEMS names.
The primary Warehouse Proxy agent for all agents reporting to a given TEMS is
the Warehouse Proxy agent which includes the name of this TEMS in its
A Warehouse Proxy agent without any KHD_WAREHOUSE_TEMS_LIST
variable set, or with a variable containing the string '*ANY' serves automatically
all the agents that do not have a primary Warehouse Proxy agent. In this case, it
is known as the default Warehouse Proxy agent for all agents.
A default Warehouse Proxy agent should be started last of all the Warehouse
Proxy agents, so that agents use their primary Warehouse Proxy agent if it is
The relationships indicating which Warehouse Proxy agent is acting for which
agent are stored in the hub monitoring server. This is why all Warehouse Proxy

Get IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.