Monitoring as an SLA-oriented consumable service for SaaS assurance: A prototype

Goal-Oriented Monitoring Adaptation: Methodology and Patterns

“…This section enumerates some existing trends focusing on (i) adapting the QoS monitoring in autonomic systems [2,3,4,5,6], and (ii) designing patterns regarding the distributed deployment as well as the adaptation of MAPE loop modules [7,8,9].…”

“…Collecting additional metrics or joining managed resources is addressed in [2,3,5] either to adapt monitoring to meet SLA modifications, or to deal with the managed scope changes, or even to operate a "minimal" monitoring that is able to be extended in case of SLA violations. Indeed, the capability of scaling up/down the monitored metrics and resources is important as an adaptation action.…”

“…Runtime deployment of monitoring resources (i.e., managers, probes) is discussed in [3,4,6] either to integrate monitoring into the SLA management lifecycle of large scale systems, or to replace failed managers, or even to monitor metrics concerning particular paths or segments. But here also, besides the undeniable gains of deploying monitoring resources during runtime, we don't see how the system administrators can orchestrate the monitoring adaptation of the distributed modules among several collaborating managers.…”

“…In most large scale systems, distributed agents push metrics periodically; in our case, agents push metrics each 10 seconds to specific pre-configured autonomic managers. We assume that our studied SLA template distinguishes two time-slots: metrics must be refreshed at the client side with a freshness falling into the range of [3][4][5][6] seconds during the first time-slot, and a range of [30][31][32][33][34][35][36][37][38][39][40] seconds for the second one. The SLAs metrics values are instrumented and delivered automatically through polling and exporting respectively in a manner that, once new SLA is enforced, the autonomic managers pull metrics with the lowest freshness value (3 seconds).…”

“…Since the second time-slot freshness ([30-40] seconds) is greater than agents push period (10 seconds), there is no need to poll metrics, nor to export all received metrics. Rather, we apply the temporal pattern to update the exporting period from [3][4] to [30][31][32][33][34][35][36][37][38][39][40] seconds (Update Exporting Period ), and consequently, the first time-slot pollings will be stopped (Deactivate Polling).…”