Introduction

Purpose

This document is one of a family of documents that comprise the Universal Measurement Architecture (UMA), which define interfaces and data formats for Performance Measurement. UMA was originally defined by the Performance Management Working Group (PMWG) and subsequently adopted by The Open Group.

This document is a specification for the functional characteristics of the Measurement Layer Interface (MLI), as defined in the UMA Reference Model in UMA Reference Model . The document describes the underlying semantics and the function calls that implement them. It also defines a format for headers appended to data as captured by the low-level Data Capture Interface (DCI). (These headers are part of the control and status messages sent between UMA and the applications it serves.)

The UMA is defined in the following documents:

• Universal Measurement Architecture Guide (see reference UMA). This document provides an overview of the UMA.

• UMA Measurement Layer Interface Specification (this document).

• UMA Data Capture Interface Specification (see reference DCI). This document defines a standard programming interface for capturing system and application provided data.

• UMA Data Pool Definitions (see reference DPD). This document defines a performance data pool for the analysis and management of computer systems, and an organisation to facilitate the collection and use of such data.

Scope of the Universal Measurement Architecture

• to provide a set of common measurement control and data delivery services for (client) performance applications

• to provide seamless access to current and historical measurement data

• to insulate the operating system kernel from performance display and analysis applications by means of a common application programming interface (API)

• to maintain portability of user tools to any systems that implement the architecture (again through the common API)

• to provide specific mechanisms for data capture that implement metric registration functions from distinct data providers

• to provide a mechanism for control of the instrumentation that coordinates the capture of kernel and non-kernel data sources

• to support access to distributed performance functions and data from remote nodes.

The UMA architecture specifies two interfaces:

• the MLI - a high-level application programming interface for specification and reporting of formatted measurement data, (this document)

  and

• the DCI - a low-level application programming interface for acquisition of raw kernel, trace, event, and subsystem data, (see reference DCI).

In addition, the architecture provides services for distributing data to multiple applications, for maintaining historical data, and for synchronising the capture of metrics from different sources.

Performance and capacity management of operating systems have been considered internal to the operating system and as such differ from one operating system to another operating system, and from one implementation to another implementation. Most operating systems have, as a matter of necessity, performance analysis modules, narrowly targeted at the type of hardware, software and networking facilities implemented within the system.

Most operating systems provide ad-hoc developed or tailored performance metrics. Some of these tools are developed as internal support tools for benchmarking or on demand of performance analysts and capacity planners. These tools are generally also confined to one machine only and can not be interrogated remotely.

The new era of networking and interoperability views performance management and capacity planning from the user's perspective. Multiple machines and operating systems can be involved in the interaction with the user. This approach requires capture and presentation of performance metrics to be clearly defined and portable between platforms and operating systems.

Definitions, Acronyms and Abbreviations

Conformance

1. Support of unsolicited events:

   MLI support of unsolicited events is optional. When a measurement application requests delivery of unsolicited events from an MLI implementation which does not support this feature, status and reason codes will be returned from the call indicating the condition.

2. Support of metric, instance tag and work unit description by metadata:

   MLI support of metric, instance tag and work unit description by metadata is optional. This information, when available, is presented in the "Subclass Attributes" subclass of the class "UMA Configuration" solicited with the umaRequestConfig() MLI call. When not supported, an attempt to retrieve this subclass will return status and reason codes indicating that the subclass is not implemented.

3. Support of dynamic data:

   MLI support of dynamic data is optional. The availability of dynamic classes and subclasses is indicated in the subclass "Implementation" of class "UMA Configuration" by the setting of the bit flag UMA_DYNAMIC for each class and subclass. Support of dynamic data implies the MLI support of metric metadata.

4. Support of protocol section contents in control messages:

   The only required usage of the control UDU header protocol section is that the umaCreate() and umaReconnect() logical message protocols and their acknowledgements include the protocol section field describing the sending platform's wordsize (mh_wdsize). The other fields may be used to support private protocols between MLI service layers. The presence or absence of the additional protocol fields has no impact on the use of the MLI API.

5. MLI use of the DCI:

   Use of the DCI by the MLI for data acquisition is optional. However, if the DCI is used as a source of data, the user should refer to the DCI conformance requirements.

6. Enhanced security services:

   These are specified external to the MLI.

7. WorkInfo granularities:

   While MLI implementation of the Workload definition mechanism (using UMAWorkInfo) is mandatory, the availability of specific WorkInfo granularities is defined by the data provider.

   ---

   Why not acquire a nicely bound hard copy?
   Click here to return to the publication details or order a copy of this publication.

   Contents

   Next section

   Index