Research Problem #

Various monitoring frameworks have been proposed and offered which usually cover only one or two
levels of abstraction. Moreover, such frameworks usually rely on level-independent mechanisms
which are able to support the individual assessment over the respective metrics. The latter
leads to the issue of measurability gaps: as adjacent levels are not able to cooperate,
then it is not possible to produce measurements of a high-level metric from measurements
of a lower-level metric. This issue leads to the fact that most of the monitoring frameworks
are able to support a rather limited and fixed set of metrics. Related to this issue is
the problem of metric computability: in particular, the frameworks are not able, based on the
high-level but complete description of a metric, to produce its measurements. They rather
stay on a quite technical mapping of the fixed description of the limited set of metrics
supported to the corresponding sensing or aggregation code needed for the metric measurement.  

The above inabilities of the current monitoring frameworks highlight the need for introducing
a cross-layer monitoring framework which is able to measure metrics over different levels as
well as cover measurability gaps by being able to address the measurement of any kind of metric. 
Such a framework should also rely on a flexible and complete high-level description of a metric
which is independent from any technical specificities.

Solution #

FORTH and University of ULM (UULM) have developed two separate monitoring frameworks which cover different 
levels of abstraction. The monitoring framework of FORTH covers mainly the workflow and service level,
while the monitoring of UULM covers mainly the infrastructure and platform levels. As such, it
is apparent that the integration of these frameworks can result in the production of a synergic
framework which is able to cover the measurement of metrics at all possible levels. To this end, 
a synergic framework has been designed and is currently developed which is able to capitalize over
the individual capabilities of the aforementioned monitoring frameworks. Each individual framework
is seen as a service which offers monitoring and evaluation capabilities. The cross-layer aggregation
of metric measurements between the two individual frameworks is facilitated by a publish-subscribe
mechanism: this means that one framework subscribes to those lower-level measurements that are needed in order to
aggregate a measurement for a higher-level. The combined framework also offers another publish-subscribe
mechanism in order to enable interested components, like an Adaptation Engine, to retrieve the SLO
evaluations produced and enact, in this case, respective adaptation actions. 

Other interesting features of the combined framework which map to common features of the individual 
frameworks are the following: recovery capability in case a monitoring component fails, data 
redundancy to avoid important monitoring data loss as well as capability to monitor both domain-independent
and domain-specific metrics.

Architecture #

The architecture of the combined/synergic monitoring framework can be seen in the following figure. As
expected, the respective individual frameworks are included and they communicate via a publish-subscribe
mechanism. In addition, this mechanism is used in order to propagate measurements to the Evaluator
component which includes a CEP engine responsible for evaluating conditions over the propagated measurements.
The events produced are further propagated to interested components, such as Adaptation Engines. 
The measurements can also be inspected in a programmatic or UI-based manner by two other components
which are part of the Collosseum cloud orchestration engine. The Collosseum API enables the
programmatic retrieval of measurements that are stored in the Evaluator while the Collosseum UI enables the
production of graphs over these measurements. Both components can rely on the measurements propagated
by the individual monitoring frameworks but in principle they could also require the further aggregation
of the stored measurements which is natively supported by the encompassing CEP Engine.

This innovation item will be made available at Gitlab.

References: #

• D3.3 - BPaaS Allocation and Execution Environment Blueprints
• D3.4 - BPaaS Allocation and Execution Environment Prototypes