A metric is a measurement taken on a system or business driver. It is also known as a key performance indicator (KPI) or resource counter.

Some examples of metrics are:

  • The CPU utilization percentage of a system
  • The number of hits on a web page
  • Average number of users logged on to a website
  • The amount of memory used for a particular transaction

BMC Helix Continuous Optimization supports a large number of built-in metrics and collection of application-specific metrics.

Related topics

Metrics and data series

For each entity defined in BMC Helix Continuous Optimization, various data series can be collected that contain useful metrics for capacity planning.

Every data series is characterized as follows:

  • Name
  • Resource
  • Unit of measure
  • Type
  • Subresource

Configuration data

Systems and business drivers contain a set of configuration data - special type of metrics that either changes slowly over time or remains unchanged. Some examples of configuration data are:

  • Core CPU frequency
  • Database CPU count
  • Database product version
  • Hard disk size
  • Installed memory
  • OS version

For numeric data (example, Core CPU frequency, Database CPU count), the historic data is stored as it is considered as Performance data. Whereas, for string values (example, OS version), only the last value is retained.


Depending on your user preferences, metrics that have not imported data for some time might not be displayed in the BMC Helix Continuous Optimization tree, and are not returned in search results.

Types of metrics

Metrics are of the following types:

  • Time series metrics: An instance of this sub-type contains a series of numeric values over regular time intervals, for example, one value every five minutes, or one value every hour, etc. Each value represents something measured over that time interval (five minutes or one hour). Each interval of time can have at most one value in the series.
  • Configuration series metrics: An instance of this sub-type contains a series of values that have variable-length validity periods. Each value represents something that holds true during a time period t1 to t2. The validity periods in the series are non-overlapping, so that at any given instant in time, there can be at most one value valid. This kind of representation is suitable for configuration information, for example, hardware description or total amount of memory in a system, which does not change very often. Each value is represented as a string.

Datasets and metrics

BMC Helix Continuous 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 Helix Continuous 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 Helix Continuous Optimization are arranged in homogeneous groups called Datasets.

For example:

  • The dataset named SYSCNF contains over a hundred different Configuration series metric definitions, including CPU_MODEL and CPU_NUM.
  • The dataset named SYSGLB contains over a hundred and fifty Time series metric definitions, including CPU_UTIL.
  • The dataset named EVDAT contains a single definition for all Events.

One particular dataset, named OBJREL, contains a single definition for all relationships. .

Custom metrics created by users or connectors are distinguished by a _C suffix in their name.

Metric instances and sub-object metrics

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 workspace, you will see the metric and the sub-object of each metric instance identified in columns named Resource and Subresource, respectively.

Metric instances associated with domains

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.

Structure of a metric instance

A metric instance is identified by the following tuple:




Unique identifier for an entity, for example, a System ID for a system


Whether the entity is a domain ("APP"), a system ("SYS"), or a business driver ("WKLD")


Metric unique name, for example, BYPAGE_RESPONSE_TIME


Sub-object name, for example,

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.

Metric values and summarization

Time series metric values are summarized by the BMC Helix Continuous 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







A count of events, absolute number

A numeric value that indicates the count of events. For example, errors, transactions, and calls. 


Pages downloaded, errors



Elapsed time

A numeric value that indicates the time required for a specific action or task to complete.


Response time



A frequency, in events/sec

A numeric value that indicates events or operations that occur per second.





Percentage counter

Numeric metric expressed in percentage.


Burst percentage, Memory
utilization percentage 



Configuration data

A numeric or textual value which indicates a configuration detail that does not frequently change such as Asset ID, Reference date, or max bandwidth.


Number of CPUs



Positive accumulation counter

Same as peak counter.


Disk space used



Negative accumulation counter

A counter for which minimum value is of interest. For example, free disk space, free storage space volumes, or CPU.


Disk space free



Generic counter, absolute value

A numeric value for counter metrics. For example, power consumption or CPU service units.


CPU queue length



Generic counter, absolute value, weightedA numeric value for weighted counter metrics, where the weight is set in the ETL.WAVG VALUEWeb response time


Peak percentage counterPeak value for percentage metrics.MAX VALUEMemory Utilization Peak
Percentage, CPU Utilization
Peak Percentage


Peak counterA numeric value that indicates positive peak values for events or operations that occur per second.


Peak packets received per second
12DELTADifference between subsequent samplesA positive numeric value that indicates the difference in value between two samples of a metric.SUM VALUE-
13WEIGHTED_PERCENTAGEPercentagecounter,weightedNumeric value expressed in percentage, that is weighted by a value imported by the ETL.WAVG VALUEEvents of a specific set,
weighed by total events expressed in percentage.


Peak counterPeak value for counter metrics.


Peak download time
for a web page
15HIGHMARKHighmark counter, peak on granular samples A numeric value that indicates peak values on the granular samples.MAX VALUE

The BMC Helix Continuous 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 Helix Continuous Optimization helps distinguish among metrics from different sources by placing them in different namespaces. For some of the technologies, metrics from hypervisors and operating systems can be imported into BMC Helix Continuous Optimization.

The following namespaces are currently in use:

  • opt:meas - Assigned to the metrics that are collected from hypervisors. This is the default namespace. 
  • opt:der - Assigned to derived metrics.
  • opt:ind - Assigned to computed indicator timeseries
  • opt:meas:vn - Assigned to metrics that are collected from Continuous Optimization Agents installed on virtual servers
  • opt:meas:app:<application name> - Assigned to metrics collected by an application

Namespaces from which a metric is used is an important consideration when running analyses or defining optimizer rules. BMC Helix Continuous Optimization employs an inbuilt fallback algorithm to automatically identify the namespace for each metric. This inbuilt fallback algorithm chooses a namespace by using a priority sequence of available namespaces.

The sequence for memory related metrics is as follows:

  • opt:meas:vn
  • opt:meas:app:<application name>
  • opt:meas
  • opt:der

The sequence for all other metrics is as follows:

  • opt:meas
  • opt:meas:vn
  • opt:meas:app:<application name>
  • opt:der

Namespace example

Metrics of an entity (CPU_UTIL in the following image) could reside in multiple namespaces because they were extracted by more than one means (OEM ETL and VIS parser ETL as seen in the following image). While analyzing a metric it needs to be picked from these namespaces.


When time series data is loaded by an ETL from a data source, it may have arbitrary time stamps and durations. BMC Helix Continuous Optimization transforms this data into a form usable for analysis and reporting. The data is normalized into a common set of meaningful intervals (hour, day, month), and some statistics are computed for each interval. If you want to view the list of percentile metrics, use analysis in Workspace and a Summary Data Mart wizard in Views. 

Size metric unit prefixes

BMC Helix Continuous Optimization uses the JEDEC standards for unit prefixes for representing binary data in BMC Helix Continuous 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:

  • kilo (k): A multiplier equal to 1024 (210).
  • mega (M): A multiplier equal to 1048576 (220 or K2, where K = 1024).
  • giga (G): A multiplier equal to 1073741824 (230 or K3, where K = 1024).

These prefixes are used to match and cross-verify metrics in BMC Helix Continuous 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.

Was this page helpful? Yes No Submitting... Thank you