|
DMTF Tutorial
> CIM > CIM
Schema > Common
Models > Metrics Model
 |
CIM Schema - Metrics Model
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
Core Model
| Common Models
The CIM Metrics Model defines the management components that allow
the dynamic definition and retrieval of metric information.
The Metrics Model uses a pattern (similar to a "decorator" pattern)
based on a metric-definition CIM class, that specifies the semantics
and usage of a metric (its meta-data) and another class (a CIM Metric
"value" class), containing data values, captured for a particular
instance of the metric-definition class.
Originally, this pattern of metric definition / value was defined
to manage transaction response time information (e.g., response
times at the client, and as a transaction flows through a system),
and provide additional metric information about the transaction
(for example, identification, processing or resource utilization
information). The concept of transaction response time was generalized
to the concept of unit of work. The unit of work classes
measure time for some action to be performed and can attach other
metrics to provide additional information.
The goals of the UnitOfWork portion of the Metrics Model are to:
-
Define a model for representing UnitOfWork metric values and
their definitions; an instance of a metric should exist only
when a definition of its characteristics is present.
-
Provide a mechanism for dynamically (i.e., at runtime) associating
both metrics and their definitions with a LogicalElement.
While it was originally defined for transaction response time measurement,
the unit of work concept is general enough to address a variety
of runtime entities requiring the measurement of time between start
and end of an activity (for example, batch processing times). This
model matches an instrumentation API for capture of processing time
information - the ARM (Application Response Measurement) Specification
is defined by the Open Group.
Because the pattern of definition value classes proved to be useful
to define dynamic metrics information for unit of work, it was extended
to more general metrics (they are named Base Metrics in the model).
CIM users often desire metric objects that the models have not yet
standardized - for example, time series analysis data on a particular
"standard" statistic. Rather than fill more and more CIM Schema
with various statistical analysis options, the Metrics Model supports
externally defined metrics which add dynamic properties to existing
classes.
BaseMetrics provide flexible and dynamically extensible meta-data
that is associated with existing ManagedElements. Again, there is
a definition class (CIM_BaseMetricDefinition) and a values class
(CIM_BaseMetricValue). An instance of a CIM_BaseMetricDefintion
defines the semantics, type, and usage of a metric (e.g., a data
type for the metric); instances of the CIM_BaseMetricValue class
capture values for a particular definition instance.
One of the core assets of the CIM 2.7 Metrics Model is its capability
of introducing late-binding for arbitrary, user/administrator-defined
metrics. More specifically, a user is able to introduce new Metric
Definitions at runtime into CIM and then instantiate one or more
Metric Values that follow the semantics of these Metric Definitions
- all as instances of existing classes, without needing to define
new classes.
Work continues in the Metrics Sub-Team of the Application Working
Group on 1) the development of usage scenarios for metrics, 2) the
development of further components of the model to work with metric
information (for example, aggregation, time series, and correlation
classes), and 3) connection of the Unit-Of-Work metrics to the general
runtime applications model that is being developed to allow direct
relationships between the modeling of performance and status of
application systems and the flow of traffic through those systems.
|
