Previous section.
UMA Data Capture Interface (DCI)
Copyright © 1997 The Open Group
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 defines the requirements for a programming interface for
the lowest layer in the UMA performance metrics architecture. The purpose of
this document is twofold. The first is to provide sufficient
background for the reader to understand the problem being solved and
the source of the programming interface requirements. The second is to
provide a specification of an interface that would meet these requirements.
The UMA is defined in the following documents:
-
Guide to the Universal Measurement Architecture (see reference UMA).
This document provides an overview of the UMA.
-
UMA Measurement Layer Interface Specification (see reference MLI).
This document defines functional characteristics
for a high-level open Application
Program Interface (API) to be used by Measurement Application Programs
(MAPs) to request and receive data.
It also defines header formats to be appended to the data captured
by a low-level Data Capture Interface (DCI).
-
UMA Data Capture Interface Specification (this document).
-
UMA Data Pool Definitions (see reference DPD). This document defines a
performance data pool (a set of operating system metrics)
for the analysis and management of computer systems,
and an organisation to facilitate the collection and use of such data.
The Data Pool specification describes the metric data
types, and groups metrics into classes and subclasses.
Scope
Performance and capacity management of operating
systems have been considered 'internal' to the
operating system and as such differ from operating system
to operating system
and from implementation to 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 and tools. 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
the capture and reporting of performance metrics to
be clearly defined and portable between platforms
and operating systems.
Historically, many operating systems have
not had a well defined interface for acquiring
information about system performance. These systems typically provide a number of
user commands for obtaining the status of system resources,
such as
ps,
sar
and the
stat
commands of UNIX.
However, programs which require
instrumentation beyond that provided by these utilities, or
applications which require higher metric acquisition rates, have
resorted to interrogating the operating system themselves.
In these cases, privileged access to system memory
(for example, kernel memory in UNIX, system control blocks for MVS)
is the only available mechanism. Such access is
notoriously slow, and can require the development and
maintenance of specialised subsystems linked
in with the operating system.
Clearly, a flexible,
extensible interface to system metrics is required.
The Performance Management Working Group has provided a solution to
this problem. This solution, the Universal Measurement Architecture (UMA),
specifies two architectural layers for system performance metrics. The
uppermost layer specifies an API for the transfer of formatted
measurement data. The lower layer specifies the interface for
acquiring raw measurement data. The term
formatted
implies
that the upper layer provides measurement services that modify the
content and format of the data on behalf of the user. For details,
see the Measurement Layer Interface specification (reference MLI).
Raw
implies that the measurement data is
acquired in its original, unchanged form.
The Data Capture Layer is the term used for this lowest layer in this
performance metrics architecture. The programming interface for the
Data Capture layer is called the Data Capture Interface, or DCI.
Measurements provided by the DCI are intended to be collected,
interpreted, or distributed by higher level applications or services
before their consumption by a user. The DCI provides an alternative
to, and eventually a replacement for, older mechanisms such as
reading the kernel memory device on UNIX systems.
The DCI is intended for anyone writing system performance monitoring or
management tools. A correctly specified Data Capture Interface
provides several benefits to the performance community. The first is
that they will be able to write portable measurement applications
because they will not have to adapt the application to each operating
system variant and release. Another benefit is that the
DCI will allow toolmakers to provide services beyond those that could
be supported by the current state of metric acquisition. Also, by
establishing a solid foundation, higher levels of standardisation, as
described by the UMA, can be specified. Finally,
DCI can become part of the lowest layers of the emerging effort to
standardise distributed system management.
Goals
There are two classes of goals for the DCI. The first class consists
of those goals that meet the needs of the performance community.
The second class consists of those goals that must
be met to satisfy requirements that the system
imposes on any new interfaces.
The DCI application programming interface must meet the following goals
to satisfy the needs of the performance community. (A detailed
description of each goal follows this section.)
- Performance
The addition and use of the DCI should not significantly
alter the performance of an existing system.
- Standardisation
Standardise the interface for retrieving performance data.
- Portability
The DCI should be implementable on a wide variety of systems.
- Multiple
The DCI should allow for metric providers other than the operating system.
- Extensibility
The DCI should have little or no inherent knowledge of the
structure of the data being provided.
- Efficient
The DCI, while limiting its scope to metrics provided
by a single system, must allow for an efficient multi-system
measurement solution.
- Polled
Both passive and interrupt driven metrics acquisition must be supported.
- Modification
The DCI should allow for the possibility that metrics, such
as configuration values, be modified by a properly privileged
MAP. It is implementation defined whether such modification
requests are honoured.
The following are requirements imposed by the current state of
operating system software.
- Security
The interface should not preclude a secure implementation.
- Multiprocessor
The interface should not preclude implementation
on multiprocessor architectures.
- Internationalisation
Any textual information should be capable of
supporting an internationalised implementation.
- Interoperability
The interface should fit into a distributed environment.
Performance
The addition of any metrics acquisition subsystem should not noticeably
affect the performance of the measured system. (Many performance tool
builders assert that system performance should not be altered by more
than 5% when there is measurement activity.) Although it is beyond this
specification to stipulate a performance degradation figure, that figure
belongs in an implementation's design specification, the performance
goal does impose a requirement that the programming interfaces
specified in this document be capable of being implemented in the most
efficient manner possible on the target operating system.
Standardisation and Portability
The reason for these two goals stems from a desire to have this API be
accepted as a standard for system metrics acquisition. The intent is
to propagate the Data Capture Interface across a wide range of systems
so that performance applications can themselves be ported to those
systems. To do so, the specification of the programming interface
cannot impose constraints which would make implementations difficult.
An example of such a constraint would be a requirement that the entire
DCI be implemented in either the system or user address space. Such a
requirement unnecessarily limits the implementor's options, possibly
precluding implementation on some systems, and would thus decrease DCI
availability to the performance community.
Multiple Metrics Sources
The goal of allowing non-operating system information providers arises
from practical considerations. Metrics collection and management is a
system problem. Not all metrics necessarily reside in the operating
system. Many metrics also exist in user space server programs or in
applications. This decentralised information is exaggerated in the
case of microkernel operating system architectures, although it also
exists in operating systems with traditional structures. This goal
allows the API to not only cover a wide range of system types but also
allows for the introduction of vendor supplied metrics to a local
system. This goal requires that loadable subsystems, such as device
drivers, streams modules, and transaction processing applications, be
able to register and provide their metrics.
Extensibility
One of the keys to extensibility is to
allow variable representations of metric data.
If the API requires that applications have prior knowledge
of the availability of metrics and their data types, then this
information would have to be maintained separately. When the metadata
(information that describes a data structure) and the data it describes
are disjoint, then possible version skew problems are introduced.
Therefore it is a requirement that the API specify "self-describing"
data structures. The solution should allow applications to read both
the metrics metadata and the data it describes and not require prior
knowledge of the metadata contents.
Efficient Enablement for Multi-system Measurement
The limitation of this API's scope to the information coming from a
single system is motivated by practicality. (In this document, a single
system refers to any machine or machines which use a single
operating system image and could be uniquely identified on a network.) The
Data Capture API provides the most basic of services: locating system
information and providing that information to a higher level
application. More complex services, such as distributing the
information across a network of machines or data reduction, will use
the information gathered by this API and should be provided by higher
layers. Limiting the scope of
this specification to a single system has the added benefit of
deferring the problems of heterogeneous data representation to higher
layers, where they belong. However, defining the scope to cover a
single system should not prevent solutions of multiple system issues at
the higher layers.
Polled Metrics and Events
Much of performance monitoring consists of polling activity counts.
However it is also useful to provide event driven information. An
application should be able to request notification of one or more
events. The event features should not preclude supporting a wide range
of event throughput requirements; from low speed events such as disk
mounting and unmounting to the high bandwidth required by trace
packages.
Modification of Configuration Data
Often the application measuring performance may wish
to take steps to address a perceived performance problem.
This might take the form of configuration changes (e.g., widening
network timeout windows).
The DCI can offer a front-end to simple configuration
management, if the underlying implementation supports it.
Security
It is now a computer industry requirement that security issues be
addressed whenever specifying the collection and distribution of
information. The information specified by the Data Pool document
(see reference DPD)
covers the activity of an entire system. A secure system
implementation must concern itself with discretionary and mandatory
access control between objects (metrics) and subjects (metrics
requesters) before allowing the metrics to be propagated. This
specification has been designed to be implemented on systems with the
full range of security requirements: from no security to the highest
security levels. Note that although this specification must allow
for highly secure implementations the choice of security level
is dependent on the target system.
Multiprocessor Systems
Multiprocessor systems are becoming commonplace in the computing
world. Any programming interface must take into account these systems
and allow for the provision of a
thread-safe
environment. When
designing with multiprocessor systems in mind, one should avoid the
introduction of global variables. Global variables work perfectly well
in single threaded environments but require synchronised access in
multi-threaded environments. Beyond taking care to not introduce
functions which require undue synchronisation, multiprocessor support
should be relatively straight forward.
Internationalisation
It is no longer acceptable in the world of computing to limit textual
output to English. Should the specification call for the use of any
text fields, these fields should be capable of providing the native
system's ability to support internationalised text. As with security,
the decision to provide internationalised text is dependent on the
target implementation.
Such is the frequency of use of the word
internationalization,
that it it commonly abbreviated in this and other documents to
i18n
or
I18n.
Interoperability
Although this API is intended to be a single machine interface, it
should provide the metrics in a format that does not make it
difficult to transport those values in a heterogeneous, networked
environment. Furthermore, application software should be capable
of operating upon the data regardless of the machine that is
eventually used for the operation. It is intended that
this interface work well as low level support for a range of
distributed management and performance applications.
Non-goals
This section describes features which are considered to be out of the
scope of this specification.
-
It is not within the scope of this document to provide specific
implementation details, such as the mechanism that must be used to
access operating system metrics. Those details would be found in a
design specification. In fact, this specification attempts to leave
the designer as much room as possible in the selection of the
implementation.
-
This specification does not cover management services for information
providers. This work focuses on the lowest level services: data
transfer from providers to users. Operations which control a system's
collection of information providers belong in a higher level design.
Definitions, Acronyms and Abbreviations
Terms, acronyms and abbreviations used in this specification
are defined in the Glossary.
Conformance
A conformant implementation must support the
basic support functions as listed in
DCI Routines, Grouped by Implementation Subset
of this specification. In addition, an
implementation may support any of the following DCI API subsets:
-
Multiple Providers
-
Event Support
-
Set Capability Support
-
Access Control.
These are also listed in
DCI Routines, Grouped by Implementation Subset
.
For each of these additional capabilities supported in an implementation,
all DCI APIs in the corresponding subset must be implemented in
their entirety.
Functions in unsupported subsets must be
implemented to the extent that they return the
[DCI_NOIMPLEMENTATION] error code.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.