The BMC TrueSight Capacity Optimization Data Warehouse offers capabilities to store metrics of different sub-types. In addition, the product offers various out-of-the-box datasets and predefined metrics that can be populated either by ETLs or Agents.
For more information, refer to the following sections:
Metrics in BMC TrueSight Capacity Optimization are definitions of time-varying information about entities, either domains, systems, or business drivers. (See Entity Types for the various types of entities in BMC TrueSight Capacity Optimization.) The actual information, in the form of metric instances, is loaded into BMC TrueSight Capacity Optimization by connectors.
Metrics are of three sub-types:
BMC TrueSight Capacity Optimization contains definitions of thousands of metrics, sometimes called resource counters, and in addition, a connector may define its own custom metrics. Every metric known to a BMC TrueSight Capacity Optimization instance must have a unique string name called the "object" or "resource" identifier, conventionally in an all-capitals and underscores format, for example, CPU_UTIL, CPU_MODEL, and BYDISK_UTIL. As explained in Viewing datasets and metrics by dataset and ETL module, metrics in BMC TrueSight Capacity Optimization are arranged in homogeneous groups called Datasets. For example:
One particular dataset, named OBJREL, contains a single definition for all relationships. For more information about relationships, see Entity relationships.
Custom metrics created by users or connectors are distinguished by a _C suffix in their name.
The entities and metrics that are imported by the ETLs are documented in the respective ETL topics. For more information, see the topics under Collecting data via ETL modules.
Datasets contain only the definitions of metrics. Instances of metrics are created by a connector based on the connector's data source.
Each instance of a metric is associated with only one entity. For example, a connector may create an instance of the time series metric CPU_UTIL and associate it with a particular system named Host1. Usually, there can be only one instance of a metric associated with an entity, as in the example of CPU_UTIL.
But some metrics are sub-object metrics. For such a metric, multiple metric instances may be associated with a single entity, one per sub-object of an entity. By convention, such metrics have names starting with the prefix BY. For example, the time series metric BYDISK_UTIL can have multiple instances for a system, one per disk. The connector that creates the metric instances assigns strings to each disk of each system, based on the data source. For example, if a system Host1 has two disks named diskA and diskB, then the connector may choose to create two instances of the time series metric BYDISK_UTIL, one instance for a sub-object of Host1 called diskA, and another instance for a sub-object of Host1 called diskB.
When looking at the metric instances of an entity in the BMC TrueSight Capacity Optimization console workspace, you will see the metric and the sub-object of each metric instance identified in columns named Resource and Subresource, respectively.
There is another way to associate multiple metric instances with a single entity: every metric also has a LOCATION field, by default filled with the string UNKNOWN. But when creating an instance, a connector may fill this field with arbitrary strings like Boston or New York. Then each such LOCATION value added, creates a separate instance of the metric associated with the same entity.
The intent of this field is to enable the connector to associate separate instances with geographic locations. Such a scheme might make sense for business drivers, for example, BYPAGE_RESPONSE_TIME could denote response times broken down by web page as well as by the location from where the page request was made. In our example, these two instances would be created for a single business driver entity:
This use of the LOCATION field in metrics is rare, but it is available for when there are an unpredictable number of geographic locations that need to be tracked separately for a single business driver. You can achieve the same effect by creating separate business drivers, one for each location.
When looking at the metric instances of an entity in the BMC TrueSight Capacity Optimization console workspace, you will see the LOCATION value identified in a column named Location.
Assigning a LOCATION field creates a new instance of the metric on the same entity! Do not use the LOCATION field if you simply need to associate a location with a system. Use a configuration metric for that purpose.
Domains, i.e., entities of category APP, may have only configuration series metrics associated with them. Otherwise, domains behave just like the other two categories of metrics, namely systems (SYS) and business drivers (WKLD), for the purposes of metric instance creation.
The dataset named APPCNF contains definitions for a handful of built-in configuration series metrics, and users or connectors can define additional custom configuration series metrics.
A metric instance is identified by the following tuple:
Element | Meaning |
---|---|
ENTITY | Unique identifier for an entity, for example, a System ID for a system |
ENTCATNM | Whether the entity is a domain ("APP"), a system ("SYS"), or a business driver ("WKLD") |
OBJECT | Metric unique name, for example, BYPAGE_RESPONSE_TIME |
SUBOBJECT | Sub-object name, for example, www.foo.com/index.html |
LOCATION | Location field, for example, "Boston" |
Each of these elements can be specified by a connector. The most typical case is for a system time series or configuration series metric, where the SUBOBJECT is GLOBAL and LOCATION is UKNOWN.
Time series metric values are summarized by the BMC TrueSight Capacity Optimization data warehouse according to the meanings of the metrics. The meanings are denoted by metric type codes, as follows:
Metric type ID | Metric type | Meaning | Summarization | Example |
---|---|---|---|---|
1 | COUNT | Time series; number of events in interval | SUM | Pages downloaded |
2 | ELAPSED | Time series; time taken for a typical activity | AVG | Response time |
3 | RATE | Time series; events per second during interval | AVG | Disk IOPS |
4 | PERCENT | Time series; typical quantity normalized against a maximum | AVG | CPU utilization |
5 | CONF | Configuration series; something true during the validity period | (none) | Number of CPUs |
6 | POSACCUM | Time series; a quantitative increment over the previous interval | MAX | Disk space used |
7 | NEGACCUM | Time series; a negative increment (decrement) over previous interval | MIN | Disk space free |
8 | GENERIC | Time series; an absolute value | AVG | CPU queue length |
The BMC TrueSight Capacity Optimization data warehouse uses the indicated summarization methods to calculate hourly, daily, and monthly values from the raw numbers loaded by connectors. No summarization is done for CONF metrics.
BMC TrueSight Capacity Optimization uses the JEDEC standards for unit prefixes for representing binary data in BMC TrueSight Capacity Optimization. These standards are uniformly applied when presenting binary data in the user interface and while defining thresholds.
The JEDEC specification contains definitions of commonly used prefixes such as kilo, mega, and giga, which are usually combined with the units byte and/or bit to designate multiples of the units.
The specification lists three prefixes as follows:
These prefixes are also the de facto standard in the industry, and are used to match and cross-verify metrics in BMC TrueSight Capacity Optimization against similar metrics from other monitoring and capacity management tools.
For example, Linux operating system uses K from the JEDEC standard when reporting KB/s in commands such as iostat and Microsoft Windows uses KB/GB from the JEDEC standards when reporting disk space available.
For more information on entities, metrics and datasets available in BMC TrueSight Capacity Optimization, see the following topics: