Understanding historical configuration

It is necessary to configure historical data collection for attribute groups and distribute to managed systems before users can see historical data in the Cloud Pak System Software Monitoring Portal. Read this topic to understand the configuration settings and their implications.

Configure historical data collection first
Customization of the Cloud Pak System Software Monitoring Portal is best begun with configuring historical data collection. Until then, no historical data is available for the predefined historical workspaces that your product might offer, for situation modeling, or for chart baselining, all of which enable you to perform in-depth analysis and health assessments of your managed environment.
Distribute to Managed System (Agent) or Managing System (TEMS)
In a historical collection, the first decision made regarding distribution is the method:

Managed System (Agent) is the default method and requires that any managed system in the distribution connect to a Tivoli Enterprise Monitoring Server Version 6.2.2 or later. The distribution goes to a subset of managed systems: the managed systems of that agent type that are assigned individually or as part of a managed system group. Alternatively, you can choose to assign managed systems for distribution to a historical configuration group that the collection belongs to.

Historical configuration groups provide a way to group historical collections that have the same distribution requirements. The managed system distribution list can be assigned for the group rather than to each collection individually.

Managing System (TEMS) is the method that was used for distribution in Cloud Pak System Software Monitoring Server Version 6.2.1 or earlier; it is the required method for distribution if the managed system connects to a V6.2.1 or earlier monitoring server. The distribution is to managed systems of that agent type that are connected to theCloud Pak System Software Monitoring Server. If the Managing System (TEMS) method has been chosen for a collection definition, that collection becomes ineligible for membership in a historical configuration group.

Upgraded historical configuration from an earlier version
If you have upgraded to Tivoli Management Services Version 6.2.2 (or later) from a release prior to Version 6.2.2, you get a historical collection definition for each attribute group that was configured and the distribution method is unchanged: Managing System (TEMS). If you would like to use the distribution techniques that are available when distribution is by managed system, change the distribution method for each collection definition to Managed System (Agent). (See the link to Changing the distribution method at the end of this topic.)
Managed System distribution through the historical collection or through the historical configuration group
You can assign a managed system (or managed system group or both) to the individual historical collection definition, a historical configuration group or to a managed system group that is assigned to the collection or historical group.

As a best practice, develop a way to organize managed system distribution for historical data collection. It is possible for a managed system to be referenced more than once for the same historical collection definition. For example, the managed system might be have been assigned in the Distribution tab for the collection definition and the collection is a member of a historical configuration group that also has that managed system assigned. You need not be concerned with data being collected multiple times on that managed system for this collection definition, but be aware that if you intend to stop data collection on that managed system by removing it (or a managed system group it belongs to) from the distribution, data collection will continue to occur. This will go on until the managed system is removed from all group distributions that the collection is a member of.

Distributing a historical collection to a new managed system
After a new managed system is added to your managed environment, data collection begins immediately if the new managed system is assigned to a managed system group that a collection definition is distributed to or if the data collection method is to Managing System (TEMS) and the new managed system connects to the Tivoli Enterprise Monitoring Server that was specified.
For example, a new Linux managed system is automatically assigned to the *LZ_SYSTEM predefined managed system group. If the historical collection is distributed to *LZ_SYSTEM, then historical data collection begins on the new managed system. Otherwise, you must add the new managed system to the historical collection distribution directly, to a managed system group that the collection is distributed to, or to the distribution of a historical configuration group that the historical collection is a member of.
Effect of editing a managed system group on the historical collection
When a managed system group gets updated, which is typically when a constituent managed system is removed or a managed system is added, any historical collection that includes that group is redistributed to all managed systems in the group and collection is restarted.
The redistribution and restarting of data collection can result in some gaps in the data if the collection interval is frequent, because collection is aligned with time boundaries. For example, if the collection interval is 15 minutes and collection was started at 3:16, the first sampling is at 3:30; or if the last collection was at 4:15 and an update to the managed system group causes the 4:30 collection to be missed, the next data collection takes place at 4:45.
Multiple collection definitions for the same attribute group

You can create another copy of a collection definition for an attribute group, then configure the copy for different values for any of these criteria: collection interval, warehouse interval, managed system distribution, or attribute filtering. What remains the same for every historical collection that is defined for an attribute group, however, is the Collection Location (TEMA or TEMS) and the settings for Summarization and Pruning.

To illustrate some of the possibilities, here is an example of three collection definitions for the Process attribute group:
  • Process transaction servers has a 1-minute collection interval, a 1-hour warehousing interval, and is distributed to a few critical servers.
  • Process database servers has a 15-minute collection interval, data warehousing every 12 hours, and is distributed to database servers.
  • Process staff systems has a 1-hour collection interval, data warehousing every 24 hours, and is distributed to a general use group of managed systems.

The original and the two copied collection definitions have their short-term history files saved at the same place (TEMA or TEMS) and follow the same summarization and pruning schedule.

As stated earlier, it is important for you to develop a way to organize how managed systems are assigned to historical distributions. When you Create another collection, the managed system distribution from the original collection definition is not copied from the original collection. This is to help ensure that you do not assign the same managed systems to other collection definitions for the attribute group. If you do, historical data samples will be taken for each collection definition, a symptom of which is the occurrence of duplicate rows in a table view. Group functions, such as averages, will have skewed results also. If this happens, use the CLI tacmd histListCollections to list the historical collection distributions, then remove the managed system reference from all but one of the collections for the attribute group.

Historical attribute groups
Some attributes groups, such as Situation Status and Windows Event Log, are historical in nature and show all their entries without your having to specify a time span. You do not need to configure history collection for these attribute groups unless you want to roll off to a data warehouse or limit the data reported.
Configurable elements of collections for an attribute group and their dependencies
Summarization and pruning is configured by attribute group; not by the collection definitions, and can be configured independently of collection definitions.
Collection interval, the frequency that data samples are taken at the managed system and saved to the short-term history file, can be different for each collection definition.
Collection location for the short-term history file can be at the managed system or the monitoring server it connects to. There is one short-term history file for an attribute group per managed system; whatever was set for the first collection is used by all collection definitions for that attribute group.
Warehouse interval, for controlling how often historical data is copied from the short-term history file to the data warehouse, can be set differently for each collection definition.
Distribute to Managed System (Agent) or Managing System (TEMS) can be set differently for each collection definition.
When this is set to Managing System, distribution is to all managed systems connected to the monitoring server; the ability to selectively distribute the collection on managed systems is disabled.
When this is set to Managed System, you have the option of assigning managed systems to the individual collection definition in the Distribution tab or to a historical configuration group that the collection is a member of or both. And managed systems can be assigned individually or as a managed system group.
Filter criteria for preventing the collection of unwanted data is configurable for each collection definition. Applying filters to historical data collection can help reduce network traffic and wasted disk space and can improve summarization and pruning performance.
Be aware that filtered data collection can affect the results of trending calculations that are performed with chart baselining and situation modeling (see Chart baselines and Modeling conditions for situations) and of query-based views that include historical data (see Setting a time span to display). For example, a filter to collect only rows where the process uses 80% or more CPU means that a calculation of average values will be only of values 80% and higher, rather than of all values.