Dynamic set-up of Monitoring Infrastructures for SLA Management
Over the last few years, several approaches have been developed to support the monitoring of SLAs. Typically, these approaches collect events during service executions and use them to check whether the properties of service provision as specified in an SLA are satisfied. Such approaches provide state of the art mechanisms for performing the basic checks of service compliance with SLAs but fall short of providing adequate support when replacements of the services deployed in a service based system (SBS) occur at runtime, or the terms of the SLA under which a service is provided change dynamically.
To provide effective monitoring support when such changes happen it is necessary to be able not only to check whether the monitorability of the required SLA terms and conditions is affected by the changes but also to modify the deployed monitoring infrastructure in order to ensure the continuous execution of the required runtime checks. These capabilities, however, are not offered by existing monitoring environments and approaches. To address this gap, SLA@SOI is developing a novel SLA monitoring framework, called “SLA Management for Monitoring” (SLAM4M). A key characteristic of this framework is the separation of the actual service monitoring from the assessment of SLA monitorability, and the dynamic set up of the monitoring resources (i.e., event captors and monitors) for checking an SLA.
SLA Management for Monitoring: Overview of the new architecture
A key characteristic of the approach underpinning the design of SLAM4M is the distinction between two key layers in service provision, namely the SLA management and service management layers as illustrated in Figure 1. The SLA management layer is concerned with SLA management activities (e.g. SLA specification, negotiation, modification) and the service management layer is concerned with the software stack required for making a service manageable according to an SLA. From a monitoring perspective, the SLA management layer incorporates the mechanisms required for performing the SLA monitorability checks and the dynamic set up of monitoring infrastructures that can enable the monitoring of an SLA whilst the service management layer incorporates the Event Captors and Monitors required for service event capturing and performing the actual SLA checks, respectively. Given this distinction, SLAM4M belongs to the SLA Management layer, as shown in Figure 1.
Fig 1: Scenarios for dynamic setup of monitoring infrastructures
Figure 1 shows the two scenarios for dynamic service monitoring setup in SLAM4M. In the first scenario (see Figure 1a), the managed service is provided with both Event Captor(s) and a local Monitor and has, therefore, both event reporting and SLA checking capabilities. Thus, when it receives an SLA, SLAM4M checks if each guarantee term in it can be monitored locally, according to the capabilities exposed by the Event Captor and the Monitor. In particular, in order for a Guarantee Term to be locally monitored, the Event Captor should be able to provide the required events, while the Monitor should support the language used for expressing the Guarantee Term.
The second scenario (see Figure 1b) applies to the following two cases:
- The Event captor provides the events required for monitoring a Guarantee Term, but the Monitor does not support the Guarantee Term language; and
- the managed service has only an Event Captor but no associated local Monitor.
In the second scenario, SLAM4M first assesses if the required events are available from the local event captor of the service and then tries to identify an external monitor that can support the Guarantee Term language. This identification takes place through a monitor registry that is accessible to SLAM4M and, if an appropriate external monitor can be found, SLAM4M submits the guarantee term to the external monitor and instructs the event captor of the service to provide events to this monitor. It should be noted that the external monitor may be available at some URI on the network and, therefore, an engagement protocol and an event communication infrastructure are required for establishing and realizing the communication of events between the service event captor and the external monitor.
In the prototype implementation of SLAM4M, we use a “publish/subscribe” event communication infrastructure designated as “Event Bus” in Figure 1b. More specifically, after locating a Monitor, SLAM4M gets from it a token designating an event channel of interest and uses this token to subscribe the monitor to the Event Bus. The same token is passed to the Event Captor to be used when it publishes events to the bus so that these events can be forwarded to the appropriate monitor.
For more information on our monitoring architecture, please see the accompanying SLA@SOI Technical Article. Additionally, further details including a discussion of the implementation of SLAM4M and some initial experiences are being published in “Dynamic Set Up of Monitoring Infrastructures for Service Based Systems”, at the track on Service Oriented Architectures and Programming at the 25th Annual ACM Symposium on Applied Computing to be held in March 2010.
George Spanoudakis, School of Informatics, City University London
Tags: dynamic monitoring infrastructures, hierarchical monitoring infrastructures, Service Monitoring, sla
