Next: Layer 1: Monitoring Up: Standardization of Event Traces Previous: Introduction

A Hierarchical Layered Model for Event Trace Monitoring and Analysis Systems

In this section we will introduce a hierarchical layered model for event trace monitoring and analysis systems. It will allow a systematic and structured discussion of the problem of object-independence. The model is based on investigations of the structure and features of monitoring and analysis systems described in the literature, and on experiences from implementing our ZM4/SIMPLE environment. Each layer provides a higher level of abstraction than the level below. In fig. 1, the six layers, together with the abstraction each layer provides, are shown. The different layers provide the following function:

layer 1: monitoring
The task of the monitoring layer is to recognize the events defined for the object system and to store all the data necessary for later analysis. It should also provide a global time base (virtual or real) to allow the ordering of all events with global interdependence. The interface to the object system depends on the chosen monitoring technique (hardware, software or hybrid) and on the properties of the object system itself.
layer 2: event trace access
This layer performs the mapping of bits and bytes of the monitoring data to the abstraction of an event trace, i.e. a sequence of event records each describing the properties of one event occurred. The structure, format and physical representation of the monitoring data is hidden for the upper layers.
layer 3: filtering
Normally, an event trace will contain more information than needed for performing a particular analysis. The filtering layer allows to define a so-called view on an event trace. A view is defined by filtering and clustering events [1]. Filtering deletes all but a designated subset of events from the trace. By clustering events, a sequence of events is regarded as a single higher level event, which we will call activity in the following.
layer 4: tool support
This layer contains all functional modules which are independent of the semantics of the object system and of the analysis. It provides often used functions which are needed for the modules of the tool layer, such as graphical displays or statistical functions.
layer 5: tool
The tool layer implements the different possibilities of event trace analysis: validation of event traces, statistical evaluation, visualization of the system's behavior, animation, sonification and extraction of information necessary for other tools, such as modeling environments, debuggers or load balancing tools. The tools can provide some predefined analyses or can be programmable or even interactive.
layer 6: application support
The application support layer constitutes the interface between the "customer" of the analysis and the event trace analysis system. In case of a human user, this layer is implemented by the user interface, i.e. it includes modules such as on-line help, result explanation or interpretation and event trace administration.

Of course, this model presents a rather idealistic view. In reality, one will often find systems in which layers are missing or combined together in order to achieve better performance. In [21] the hierarchical layered model is discussed in much more detail. In particular, the functional modules of each layer and their interdependencies are described. Besides this, a classification scheme based on the layered model is introduced, which allows a comparison and rating of different event trace monitoring and analysis systems.

Coming back to the problem of object-independence, a closer look at the layered model shows that there are three components in a monitoring and analysis system which are affected by that problem: (i) the interface between the monitor system and the object system, (ii) the event trace access and (iii) the analysis tools. These three topics will be discussed in more detail in the next three sections.



Next: Layer 1: Monitoring Up: Standardization of Event Traces Previous: Introduction


mohr@cs.uoregon.edu
Fri Feb 25 11:04:10 PST 1994