Previous section.

UMA Measurement Layer Interface (MLI)
Copyright © 1997 The Open Group

Data Collection, Reporting and Recording

UMA Collection and Reporting

UMA distinguishes between the reporting of data to a MAP and the collection of data. A MAP requests reporting from a specified source to a destination (which may be the MAP itself) in the form of UMA messages. The UMA facility acts on behalf of a MAP to perform the actual data collection through the Data Capture Interface (DCI). This may mean initiating the collection or making use of an existing collection in progress for other MAPs that have requested the same measurement classes and subclasses. Data from the DCI will have an appropriate header appended to it and may undergo certain transformations and filtering before it is reported to one or more MAPs.

The UMA Data Capture Layer (DCL) is responsible for data collection to UMA-controlled structures from hardware registers, system counters and tables, driver counters and tables, etc. The collection of data has occurred when the data is in a structure controlled by UMA, that is, a structure that cannot be modified until a UMA component permits it.

Most subclasses defined in the Data Pool Definition (see reference DPD) specify interval data reporting, that is reporting of a difference in data values over the duration of the interval or a data value at the end of the interval. Reporting of absolute (undifferenced) data values at each interval can be chosen by specifying a flag UMA_WORKLOAD_ABSOLUTE in the umaStart() MLI call. In addition, there are subclasses associated with events and subclasses that may have both interval and event forms.

Capture Synchronisation and Data Coherency

Specifying capture synchronisation means that UMA Measurement Control will attempt to schedule data capture from different DCL data providers or instances of DCLs so that they occur at very near the same time. Capture coherency means that, as defined by implementation criteria, the collection of a UMA subclass will be as near an atomic operation as possible. This means that a collection may be rejected and retried if the atomicity criteria are not met.

Data Reporting - Intervals

In UMA, data is reported at intervals that a MAP specifies. Data collections take place at regular interval times, that is, at predictable wall clock times as measured from 12 midnight. See the umaSetAttr() specification for a definition of regular intervals.

If the session start time or the reporting request (umaStart()) occurs at a time between regular collection times, the first interval reported for the session may be for a shorter duration than that specified. All subsequent collections will be of the correct duration and at regular times.

A MAP may request exemption from regular interval collections for a session by specifying the session property UMA_NOTREGULAR. Session properties will be discussed in detail in a subsequent section.

If historical data has been requested (from UMADS, or a file), data may not be available at the specified interval. In this case, the UMA facility supplies data at the archive interval up to the point where either recent data or current data are available at the requested interval. The UMA message header specifies the applicable interval for any supplied data. The MAP can prevent data being retrieved from UMADS by setting the RECENT_ONLY session attribute to TRUE.

Data Reporting - Events

Event data in UMA consists of notification messages to the data consumer that some predefined set of system events specified by the class and subclass have occurred. The requester defines a UMA start/end time window for which these notifications are to be received. The data sources and destinations are specified as for interval UMA data.

By specifying certain event-related flags in the umaStart() MLI call, delivery of event data to the measurement application may be requested as either in-band (that is, in timestamp sequence) or out-of-band (ahead of timestamp sequence). This will be further discussed in the description for the umaStart() call.

Certain UMA subclasses defined in the Data Pool Definitions (see reference DPD) have both event and interval forms. For example, all Per Work Unit data pool subclasses admit both forms. This permits the MAP to select whether data is to be reported at each interval end, at an event, say, the termination of the process or at a process change in group ID, or both.

The UMA Configuration subclass is reported either as solicited event using the umaRequestConfig() MLI call or as an unsolicited event specified in a umaStart() MLI call.

Trace Data

Trace data in UMA is treated as high-volume event data. The requester specifies a UMA start/end time window during which he wishes to have the trace data collected. The class and subclass define the specific trace(s) activated. Because of the potentially high data volumes, trace data should normally be directed to a file.

Screening and Filtering Data

UMA provides two data interpretation capabilities that permit the reduction of message traffic to the MAP:

Subclass Screening

Assuming that the provider can measure and deliver data at the required level of granularity, it is possible to restrict reporting of subclasses that have met threshold criteria. Interval data transmissions to a MAP are screened, based on a set of variable values that are compared to session-specific threshold settings.

A MAP session will be able to establish and change threshold settings which will inhibit transmission of data to the session for those intervals where the associated variables are within the threshold ranges. The MAP session uses the umaSetThreshold() function to establish or change thresholds.

Work Unit Data Filtering
It is possible to select subclass data by various Per Work Unit criteria, for example:

This is discussed further in the description of the umaStart() call.

Constructed Workloads and Summarisation

The UMA MLI supports requesting of workload construction by permitting the labelling of workloads specified in the umaStart() call. These constructed workloads typically represent the result of a request for filtering and/or summarisation of workload metric subclasses. The summarisation is over the elementary workloads specified by selection criteria in the umaStart() call. Thus, for example, one could request the selection of all commands starting with the letters "abc" and one could additionally request that a specific per-work unit metric subclass report its process metrics over the sum of all processes whose command names start with these same letters. A constructed workload is assigned an identifier by the caller which can then be used to tag this workload for later reference. The workload tag is implemented in UMA data messages as a special case of an instance tag.

A special constructed workload that is the complement of a specified workload is also available. The complement workload metrics are derived by subtracting the selected per-work-unit workload data values from the available global equivalents. For example, for reporting at the process level, if the selection criterion is <User Name: Albert>, then the cpu utilization metric for the complement workload would consist of the global cpu utilization minus the usage for all processes running under the user name "Albert".

Data Buffering and Delivery

Normally, the Data Services Layer (DSL) will buffer data messages associated with intervals that are destined for a MAP. That is, they are not sent until an event happens that requires the buffer to be sent and then they are sent in a block. This triggering event might be the end of a reporting interval, the arrival of the last message requested, a buffer getting filled, etc. The deblocking of such messages is generally handled by the MLI.

Data messages associated with events having the out-of-band attribute are sent to the MLI as soon as they arrive.

Recent Data Facility

UMA provides a Recent Data facility to hold a limited number of the most recent data messages for MAP-requested interval sizes. The number of intervals and the granularities potentially maintained by this facility would be specified by the systems administrator in a configuration file for each UMA instance.

UMA Data Recording

UMADS (UMA Data Storage)

The UMADS facility consists of an interface and a set of storage mechanisms for access by the DSL. Data in UMADS may be structured or recorded in implementation-specific ways. The only requirements are that the data be capable of being read by the DSL, that it support positioning in time via the umaSeek() MLI call, and that the DSL can format its contents to the message standards. UMADS, therefore, functions as a time-indexed, non-volatile cache.

For specification of UMADS access, either the source and destination parameters of the umaCreate() function may be set to a string of the form "UMADS[(dbid)]"1 , which denotes a specific UMADS. In particular, the dbid may be used to designate any of a number of UMADS areas, for example hourly, daily, etc. Access to these areas may be controlled to permit either public or private read/write through the use of an administrative UMADS authorisation file.

Requests to UMADS can be originated by a MAP making historical reporting references. These historical references may occur in one of two ways. First, a MAP may explicitly constrain access to UMADS by specifying it as the source. Second, a historical reference may result from a positioning to a time that is before any contained in the Recent Data facility.

Data messages are sent to the MAP from UMADS or the Recent Data in exactly the same form, thus providing a seamless link of historical and current data. Interval sizes from the historical data sources may, however, be either larger or not integer divisors of the requested interval. In this case, the data provided from these sources may be at a different interval size (the UMA data message header will indicate the size). If this is not satisfactory for some applications, the user may consider use of specially collected data saved in a private UMADS area.

The UMA MLI supports location transparency for UMADS data. This means that:

  1. UMADS data for a specific host (sysid) does not have to be located on that host

    and

  2. The measurement application does not need to know where host-specific UMADS data is located.

UMA MLI calls, therefore, can refer to the object system through its symbolic name and let UMA locate the historical data for it - this is the presumed location. Alternatively, a caller may specify a location as a source or destination for UMADS data for a given session, if security policy permits it.

No special MLI calls are required for a MAP to access UMADS; however an administrator may need to perform certain support and maintenance that are specific to UMA. Examples include dbid initialisation, copy-in or copy-out by class and subclass, setting retention periods by class/subclass, and so on.

Compatible Granularity

For any host, several UMADS areas can be established, each having a different interval size. This allows users to select UMADS data with an interval size that is compatible with various live interval sizes (for example, the UMADS interval size could be a multiple of the live interval.)

Interval sizes can be mixed within a single UMADS area. This should be done, however, so that it is consistent and easily handled by MAPs. For example:

Private Files

UMA provides for the reading and writing of session messages to and from conventional flat files.

Specification of private files, for reading or for writing is via the source and destination parameters of the umaCreate() call. The details are discussed in the description of umaCreate(). It is important to note that UMA does not support seamless switching between private files and Recent Data. (Seamless Switching between UMADS and Recent Data is supported.) When a private file is the source in the umaCreate() call, it is the only source of data for the session.

Footnotes

1.
In subsequent text, "UMADS[(dbid)]" will frequently be abbreviated to "UMADS".

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