Monitoring and Reconfiguration for OCCI Resources - IEEE Computer ...

2013 IEEE International Conference on Cloud Computing Technology and Science

Monitoring and Reconfiguration for OCCI Resources Mohamed Mohamed, Djamel Bela¨ıd and Samir Tata Institut Mines-Telecom, Telecom SudParis, UMR CNRS Samovar 9 rue Charles Fourier 91011 EVRY Cedex, France Email: {firstName.lastName}@telecom-sudparis.eu which is the heterogeneity of the resources to be monitored and reconfigured. This problem is basically due to the fact that monitoring and reconfiguration are treated as separate aspects. Almost all the time, the resources used to these aims are not compatible with one another. Actually, almost all of the cloud computing projects suppose that monitoring is used just to gather Key Performance Indicator (KPI) for billing or to notify the interested client of eventual problems [3], [4], [5], [6]. They also consider that reconfiguration consists of a new deployment of resources [3], [4], [5], [6]. Therefore, reconfiguration is as expensive as new deployment. The few others works concerning monitoring and reconfiguration cope just with specific use cases. Thus, they can not respond to the dynamic of the cloud in different situations. We advocate that making monitoring and reconfiguration collaborate is really interesting since it allows to rapidly tackle anomalies and keep the system in a safe state. To do that, we need to bypass the previously explained problems.

Abstract—Monitoring and reconfiguration are critical issues in Cloud environments. Monitoring allows to detect violations and specific events, while reconfiguration allows to activate corrective mechanisms or runtime modifications. In this paper we propose an extension for Open Cloud Computing Interface (OCCI) to enable monitoring and reconfiguration. The extension describes the needed elements to manage (i.e, to monitor and reconfigure) cloud resources on demand. The definition entails the introduction of new OCCI Resources, Links and Mixins. We define on the one hand new types needed to monitor metrics based on a previously established SLA. On the other hand we define the needed types to reconfigure our managed resources when needed. The newly added elements are OCCI entities defined as generic Kinds, that are specialized using OCCI Mixins. Using these elements, the user is provided with a monitoring and reconfiguration infrastructure on demand. We propose herein, a real use case based on HTTP rendering showing how to establish and link the described elements of the infrastructure. Keywords—Cloud Computing, Monitoring, Reconfiguration, OCCI

I.

To resolve heterogeneity problems, the most trivial way is to use standard interfaces. For Cloud Computing, the de facto standard is Open Cloud Computing Interface (OCCI). OCCI is defined by the Open Grid Forum as ”an abstraction of real world resources, including the means to identify, classify, associate and extend those resources” [7]. Using OCCI standard enables also a granular description for monitoring and reconfiguration requirements. The extension mechanism of OCCI, based on the usage of Mixins, enables adding new functionalities easily. The rendering of the infrastructure is based on REST interfaces using HTTP [8]. In this paper, we propose an on demand monitoring and reconfiguration infrastructure based on OCCI standard. This infrastructure is based on new OCCI Entities (i.e. Resources and Links) and Mixins. Our aim is to add monitoring and reconfiguration facilities to OCCI resources independently of the level (XaaS). In order to add monitoring and reconfiguration facilities to a resource, we propose to add Mixins to enable the following functionalities: (1) to extract monitoring data from the concerned resource, (2) to handle subscriptions/notifications from/to interested parts and (3) to enable reconfigurations on concerned resources. The rest of the infrastructure consumes monitoring data using these latter Mixins in order to analyze it and generate reconfiguration actions. The established infrastructure needs eventually some Mixins for specific processing (i.e adding specific analysis rules and reconfiguration strategies, etc.).

I NTRODUCTION

Cloud Computing is a challenging area involving different aspects of IT (Information Technologies) services. Its adoption is increasing due its economic model based on pay-as-yougo model. A survey conducted by the Cloud Industry Forum [1] in 2012 involving 300 companies shows that 53% of the companies in this survey are currently adopting the Cloud. The same survey showed that 73% of these companies are planning to increase their adoption of Cloud services in the next 12 months. Many aspects related to Cloud Computing are well explored. Meanwhile, monitoring and reconfiguration did not get the needed attention in research works. In fact, Cloud resources are exposed to dynamic evolution during their life-cycle. This evolution is due to the environment dynamic. To cope with this evolution, a monitoring and reconfiguration infrastructure must be offered by the cloud provider. This infrastructure has to enable dynamic monitoring and reconfiguration of cloud resources with a minimal cost and a minimal performance degradation. Monitoring and reconfiguration are indeed critical tasks in Cloud environments. They allow the continuity of services and the fast reaction to any detected anomaly. Monitoring consists of informing interested parts of the current status of a property or a service. While reconfiguration is a runtime modification of the structure or the implementation of an infrastructure [2]. There are different unresolved problems related to monitoring and reconfiguration in Cloud Computing. In this environment the user may specify in a granular way what he wants to monitor and reconfigure. Going from a simple attribute to a complex system. This issue brings another major challenge 978-0-7695-5095-4/13 $31.00 © 2013 IEEE DOI 10.1109/CloudCom.2013.78

The remainder of this paper is organized as follows. In Section II we define monitoring, reconfiguration and give an overview on OCCI. Section III is the core of our proposition, and it introduces the different OCCI Entities and Mixins that we use to establish a monitoring and reconfiguration infrastructure. In Section IV we present the interactions between the 539

extend those resources.” OCCI provides a model to represent resources and an API to manage them. The OCCI model can be extended to cover different levels in the cloud (i.e. IaaS, PaaS,etc.). OCCI specifications consist essentially of three documents. The first is OCCI Core [7] and it formally describes the OCCI Core Model. The second document is OCCI HTTP Rendering [8] and it describes how to interact with OCCI Core using HTTP protocol. The third document is OCCI Infrastructure [11] and it represents an extension of the Core to include new resources representing the cloud infrastructure layer. OCCI represents the real world as Entities. Entities are Resources related with Links. These Entities (Resources and Links) are typed using Kinds. Entities are extensible using Mix-ins. Mix-ins and Kinds inherit Category base type defined in OCCI. Each Category can have one or more actions. The diagram representing OCCI core base types is shown in Figure 1.

different defined elements. Then, we continue with a use case that gives more understanding for our approach in Section V. We discuss the related works in Section VI. Finally, we conclude the paper and give some perspectives in Section VII. II.

BACKGROUND

In this section, we will introduce the different terms related to our work. On one hand, we will describe some aspects of monitoring and reconfiguration. On the other hand, we will briefly introduce Open Cloud Computing Interface (OCCI). A. Monitoring Monitoring consists of informing interested parts of the status of a property or a service. In our work [9], we consider two models of monitoring: monitoring by polling or by subscription. Polling is the simpler way of monitoring, as it allows the observer to request the current state of a property whenever there is a need. The interested part can generally interact with a specific interface that provides a getter of the needed property. Monitoring by subscription model is based on a publish/subscribe system which is defined as a set of nodes divided into publishers and subscribers. Subscribers express their interests by subscribing for specific notifications independently of the publishers. Publishers produce notifications that are asynchronously sent to subscribers whose subscriptions match these notifications [10]. Subscription allows an observing resource to be notified about changes of monitored properties using one of the following modes: (1) The subscription on interval implies that the publisher (producer) broadcasts the state of its properties periodically to the subscribers (consumers) and (2) The subscription on change implies that the publisher has to notify the subscribers whenever its properties changed.

III.

M ONITORING AND R ECONFIGURATION TYPES D ESCRIPTION

In this section, we define the different types that we need to enable monitoring and reconfiguration based on OCCI. Monitoring is usually used to get information to verify whether an SLA is met or not. This latter may concern one or more resources to be managed (i.e, monitored and reconfigured). We assume that each resource has its own SLA. Based on monitoring information, the established infrastructure can take decisions to trigger reconfiguration actions to apply on Cloud resources. In order to offer a monitoring and reconfiguration infrastructure on demand, a Cloud provider needs to define new Resource types, new Links and new Mixins. In the following subsections we define these elements.

B. Reconfiguration

A. Resources

Reconfiguration is a runtime modification of the structure or the implementation of an Infrastructure [2]. In the literature, we can classify the reconfiguration in four classes: (1) Structural: the reconfiguration leads to a change in the structure of the system (removing resources, adding resources, creating or removing binding between resources); (2) Geometric: the reconfiguration leads to a new mapping of the existing resource to new locations (migration of components); (3) Implementation: the reconfiguration leads to changing the implementation of one or more resources, but the structure of the system remains unchanged; and (4)Behavioral: the reconfiguration leads to a change of the behavior of one or more resources by changing some attributes. We also identified that there are simple reconfiguration actions and complex ones. These latter could be represented as a combination of a set of simple actions. The usual reconfiguration actions are: (1) Adding/Removing a component; (2) Modification of an attribute; (3) Adding/Removing a connection; and (4) Adding/Removing a component interface.

To provide a generic description for monitoring and reconfiguration using OCCI, we defined new resources. Basically, these resources are the Analyzer resource and the Reconfiguration Manager resource. These resources inherits the Resource base type defined in OCCI core [7] (see Figure 1). 1) Analyzer: It is a generic OCCI resource that allows to analyze monitoring data and eventually generate alerts. Notifications are received through an instance of the NotificationLink (described in III-B2). The Analyzer resource is an abstract description that would be specified using RuleSet Mixin collection (described in III-C4). It uses RuleSet Mixin to specify rules to apply on monitoring data. The description of this resource is depicted in Table I. Model attribute value scheme http://ogf.schemas.org/occi/reconfiguration# term Analyzer attributes (see below) related http://ogf.schemas.org/occi/core#resource Set of Attributes for the Analyzer name type mut. req. Description occi.analyzer.ruleset Enumeration yes yes Applicable rules Resubscription time occi.analyzer.rtime number yes no

C. OCCI Specification overall The Open Grid Forum defines the Open Cloud Computing Interface (OCCI) [7] as ”an abstraction of real world resources, including the means to identify, classify, associate and

TABLE I.

540

D EFINITION OF THE A NALYZER RESOURCE

Category +scheme: URI +term: string +title: string[0..1] +attributes: set 1

category

related 0..1 related *

* *

actions 0..1

Kind

Action

action 0..1

*

*

Mix-in

+entity_type: Entity 1

kind

mixins

*

*

Entity

Polling

Reconfiguration

Subscription

RuleSet

AlertTool

+id: URI +title: string[0..1]

ActionTool

1

Analyzer

Fig. 1.

Reconfiguration Manager

NotificationTool

SubscriptionTool

target

Resource +summary: String[]

StrategySet

Link links 1

source *

NotificationLink

SubscriptionLink

AlertLink

ActionLink

OCCI Core Model and our extension (bold boxes) for Monitoring and Reconfiguration.

2) Reconfiguration Manager: It is a generic OCCI resource that receives alerts from the Analyzer resource through an Alert Link (described in III-B3). To receive alerts, this resource must be the target of one or more Alert Link instances. The Reconfiguration Manager resource is an abstract description that would be specified using StrategySet Mixin collection (described in III-C8). This latter is used to specify strategies to apply for each received alert. Based on these alerts the Reconfiguration Manager resource may generate reconfiguration actions to apply on resources. The description of the Reconfiguration Manager resource is depicted in Table II.

1) SubscriptionLink: It is a Link between a subscriber and the resource to be monitored (via its Subscription Mixin described in III-C2). It models the occurrence of subscriptions on specific metrics. A Subscription Link is related to one consumer that requires monitoring information and one managed resource that have a Subscription Mixin. A Subscription is specified with a Mixin instance from the SubscriptionSet Mixin collection. 2) NotificationLink: It is a Link between a monitored resource (via its Subscription Mixin) and a subscriber. It models the activity of notifying subscribers about the state of a monitored metric. This activity depends on the type of the subscription. If the subscription is on change, a notification will occur whenever the monitored metric changes. If the subscription is on interval, a notification will occur periodically based on the period specified in the subscription. A notification is specified by an instance of the NotificationSet Mixin collection (described in III-C6).

Model attribute value scheme http://ogf.schemas.org/occi/reconfiguration# term Reconfiguration Manager attributes (see below) related http://ogf.schemas.org/occi/core#resource Set of Attributes for the Reconfiguration Manager name type mut. req. Description occi.reconfigmanager.strategies Enumeration yes yes Used strategies Thread type occi.reconfigmanager.activation String yes no

TABLE II.

3) AlertLink: It is a Link between the Analyzer resource and the Reconfiguration Manager resource. Its role is to drive alerts from the Analyzer to the Reconfiguration Manager. An alert is generated when the Analyzer resource detects that one rule in the RuleSet Mixin collection is not respected. An alert is specified by an instance of the AlertSet Mixin collection (described in III-C7).

D EFINITION OF THE R ECONFIGURATION M ANAGER RESOURCE

B. Links To link the different resources, we defined new links inheriting the Link base type defined in OCCI Core [7] (see Figure 1). Due to space limits, some attributes of the Links are not specified 1 .

4) ActionLink: It is a Link between a Reconfiguration Manager resource and another resource on which the latter applies reconfiguration actions. It models the transfer of actions from the Reconfiguration Manager to be applied on the managed resource. An Action Link is characterized by the activity that applies reconfiguration actions on other resources. This activity

1 A complete description of Links attributes is available on http://www-inf. it-sudparis.eu/SIMBAD/tools/OCCI/autonomic/occilinks.html.

541

is specified with a Mixin instance from the ActionTool Mixin collection (described in III-C9). C. Mixins

7) AlertTool Mixin: It models the needed tools by which alerts can reach a Reconfiguration Manager. An instance of the AlertTool may represent a simple message containing the description of the encountered event. It may also refer to an external program that handles the alerting task.

To customize the different resources and links between them, we defined different Mixins. These latter inherits the Mixin base type defined in OCCI Core [7] (see Figure 1). Due to space limits, attributes of the Mixins are not herein described 2 .

8) StrategySet Mixin: Each instance of this Mixin implements a computation strategy that based on incoming alerts triggers reconfiguration actions on specific resources. It represents a function applied by the Reconfiguration Manager to process incoming alerts.

1) Polling Mixin: It describes the needed operations to monitor a resource by polling. It provides the needed functionalities to ensure monitoring by Polling. By extending a resource with this Mixin, we add a list of actions. The first action getAttributes() returns the list of the attributes of the managed resource. The getAttributeValue() returns the value of a given attribute.

9) ActionTool Mixin: It models the needed mechanisms by which reconfiguration actions are applied on a specific resource. An instance of the ActionTool may represent a simple action as it is defined for the OCCI Core model [7]. It may also be a composed action that refers to a list of actions. This Mixin may refer to an external program that handles the reconfiguration task. IV.

2) Subscription Mixin: It allows an interested part to get monitoring data. For each resource that we want to manage (managed resource), we add a Subscription Mixin to manage subscriptions on specific metrics in order to receive notifications containing monitoring data. Notifications may be on interval so that the client receives a notification periodically containing the state of one or more metrics. It may also be on change, so the Subscription Mixin pushes the new state of the metric whenever a change occurred. Subscription Mixin offers a list of actions to manage clients subscriptions (i.e, subscribe(), unsubscribe(), etc.).

M ONITORING AND R ECONFIGURATION I NFRASTRUCTURE

In this section, we detail the usage of the previously defined OCCI Entities (i.e, Resources and Links) and Mixins to establish a monitoring and reconfiguration infrastructue ( see Figure 2). To instantiate our monitoring and reconfiguration infrastructure, we start by extending the resource that we want to monitor. In this aim, we extend it by a Polling Mixin to allow the extraction of monitoring data. Then, we add a Subscription Mixin to allow subscriptions and notifications. A Reconfiguration Mixin is also needed to enable reconfigurations. This is the first step to render a resource monitorable and reconfigurable.

3) Reconfiguration Mixin: It provides the needed functionalities to ensure reconfiguration. By extending a resource with this Mixin, we are adding new actions. The first action setAttributeValue() changes the value of an attribute. The getActions() returns the list of actions that one could apply on the managed resource. The invokeAction() invokes a given action on the managed resource.

The next step is to instantiate the Analyzer that consumes monitoring data and applies analysis rules. To receive monitoring notifications, the Analyzer must subscribe to the monitored resource using a SubscriptionLink having as source the Analyzer itself and as target the resource to be monitored. The SubscriptionLink being abstract, needs to be specified using a SubscriptionTool Mixin. This latter Mixin contains the specific aspects of the subscription. An instance of this Mixin can specify the start time of the subscription, its duration and its type whether it is on interval or on change. Based on the type of the needed subscription, the Analyzer may receive periodic notifications if the subscription is on interval, and it may receive notifications whenever the monitored metric changed if the monitoring is on change. Notifications are received through an instance of the NotificationLink. Technically, the aspects related to notifications are described using instances of the NotificationTool Mixin. It may specify exactly how the notifications can reach the subscriber (i.e, the notification can be an email, a message or HTTP callback, etc). When receiving a notification, the Analyzer uses RuleSet Mixin instances to specify rules to apply on incoming monitoring data. These Mixin instances can be simple conditions comparing the data against previously defined values or they can be calls to an external program that applies analysis. In the two cases, if the data does not meet the SLA, the Analyzer may raise alerts to the Reconfiguration Manager.

4) RuleSet Mixin: It implements a computation rule that based on incoming information (monitoring information) triggers specific alerts. It represents a function applied by the Analyzer resource to compare monitoring information values against previously defined threshold or conditions. Whenever the condition is verified, the Mixin instance make the Analyzer trigger a specific alert. 5) SubscriptionTool Mixin: It models a Subscription instance. It contains the different aspects of a subscription (i.e, subscription type, duration, and eventually filters). This Mixin may describe the mechanism of the subscription or may refer to an external program that handles this task. 6) NotificationTool Mixin: It models the needed tools by which notifications are sent to subscribers. An instance of the NotificationTool may enable notification messages by different tools like emails, messages, or simple HTTP notifications. This Mixin may implement the needed mechanisms to send the notification or it may refer to an external program that handles this task.

Accordingly we need to instantiate the Reconfiguration Manager resource and link it to the Analyzer via an Alert

2 A complete description of Mixins attributes is available on http://www-inf. it-sudparis.eu/SIMBAD/tools/OCCI/autonomic/occiMixins.html.

542

> POST /analyzer / HTTP/1.1 >... < X-OCCI-Location: .../analyzer

link. This latter specifies how the alert is sent to the Reconfiguration Manager using an instance of the AlertTool Mixin. The Reconfiguration Manager uses specific strategies to generate reconfiguration actions. These strategies are instances of the StrategySet Mixin. A strategy can be a simple matching between incoming alerts and outgoing actions. It can be also a call to external program able to handle alerts and generate reconfiguration actions. The last step is to link the Reconfiguration Manager to the managed resource using an ActionLink that takes the generated reconfiguration actions and applies them on the resource. We specify how to apply these actions using an ActionTool Mixin instance. V.

This resource consumes monitoring data and compares them against previously established values (based on SLA). The Analyzer resource uses the RuleSet mixin which is a collection of rules. Each instance is a rule, that verifies a given condition. > POST /ruleset/diskrule / HTTP/1.1 >... > X-OCCI-Location: .../analyzer > X-OCCI-Attribute: threshold=10Gb > X-OCCI-Attribute: attribute= freedisk

U SE C ASE

To push further the details of our approach, we present a use case describing the sequence of actions needed to establish a Monitoring and Reconfiguration infrastructure. We assume that the different thresholds needed to trigger reconfiguration actions are extracted from a previously defined SLA contract. Suppose that we have a resource named DataB that represents a data base instance. This instance has a freeDisk attribute that represents the disk space left in the used partition. The SLA related to this resource indicates that the freeDisk attribute must remain bigger than 10Gb. The needed infrastructure consists of an Analyzer Resource that consumes monitoring information from an incoming NotificationLink concerning the freeDisk attribute. If this space is less then a given threshold (i.e. 10Gb for this example), the Analyzer must send an alert to the Reconfiguration Manager resource. This latter must generate a ScaleUpDiskAction action to extend the partition disk space. The action is triggered using a ScaleUpDiskStrategy mixin which is an instance of the StrategySet mixin collection.

In this example, the rule compares the incoming value of the attribute freedisk against the given threshold. To receive monitoring data, the Analyzer must be a subscriber to the Subscription mixin. To do that, it may use a SubscriptionLink between the Analyzer resource and the managed resource. In order to specify monitoring aspects, the SubscriptionLink may use a mixin instance from the SubscriptionTool mixin collection. In this instance, the user specifies the type of the subscription and all the needed data. The Analyzer resource may subscribe to the Subscription mixin to receive notifications whenever the freedisk attribute changes. > > > > > > > <
POST /Polling / HTTP/1.1 >... > X-OCCI-Location: http://provider/DataB

POST /subscriptionlink / HTTP/1.1 Category: SubscriptionLink; scheme=.../occi/monitoring#; class=kind; X-OCCI-Attribute: ..target=.../DataB" X-OCCI-Attribute: ..source=.../analyzer" ... HTTP/1.1 201 OK Location: .../subscriptionlink

Due to space limits, the rest of listing representing the queries are not described 3 . In order to specify the notification aspects, the NotificationLink makes use of an instance of the NotificationTool mixin collection. the Subscription mixin uses a HTTP callback to send the notification instance. The notification contains the name of the attribute, its new value and the occurrence time of the change. At this stage, the Analyzer is able to consume monitoring data and generate alerts if the data do not meet the SLA. Alerts generated by the Analyzer resource are consumed by a Reconfiguration Manager resource. The user needs now to instantiate a Reconfiguration Manager resource to enable reconfigurations (in this example we name it ”rmanager”).

After adding this mixin, the user can monitor by polling the managed resource. But to enable the monitoring by subscription, he still needs to add a Subscription mixin instance. > POST /Subscription / HTTP/1.1 >... > X-OCCI-Location: http://provider/DataB The monitoring infrastructure is now in place. To allow reconfigurations, we need to extend the DataB resource with an instance of the Reconfiguration mixin.

The Reconfiguration Manager resource is able to apply reconfiguration strategies to meet the previously defined SLA. A strategy is an instance of the StrategySet mixin collection. To specify a strategy, the user may instantiate one of the mixins offered by the provider.

> POST /Reconfiguration / HTTP/1.1 >... > X-OCCI-Location: http://provider/DataB The following actions are related to the reconfiguration infrastructure. They include also, the needed actions to consume monitoring data. The user starts by instantiating an Analyzer resource.

> POST /strategyset/scalediskstrategy... 3 The list of all actions for this use case is available on http://www-inf. int-evry.fr/∼mohame m/usecase.

543

Fig. 2.

Monitoring and Reconfiguration Infrastructure.

>... > X-OCCI-Attribute: related=../rmanager > X-OCCI-Attribute: alerttype=lowdisk > X-OCCI-Attribute: attribute=freedisk > X-OCCI-Attribute: action=scale-up-disk > X-OCCI-Attribute: newval=freedisk+2Gb >... < HTTP/1.1 201 OK < Location: .../scalediskstrategy"

VI.

S TATE O F T HE A RT

In this section we present different works on monitoring and reconfiguration. We were inspired by these works to progress in our proposal. A. Monitoring In the literature, there are many attempts to provide monitoring in the cloud and in distributed systems. In this subsection, we present some proposed approaches in this area. We conclude by explaining the limitations of these approaches and giving our objectives to overtake these limits.

In this example, whenever the Reconfiguration Manager resource receives a lowdisk alert, it triggers a reconfiguration action ScaleUpDiskAction. To receive such kind of alerts, there must be an AlertLink between the Analyzer and the Reconfiguration Manager. To specify how the alerts are going through the Alert Link, the user may use an instance of the AlertTool mixin collection.

Augusto Ciuffoletti [12] proposed a monitoring infrastructure based on OCCI resources. The infrastructure consists basically on a Sensor resource and a Collector Link. The Collector Link is responsible of the collect of monitoring data from a given resource. The Sensor receives monitoring data and republishes them. The Sensor and the Collector are abstract types specified using mixins: (1) a metric mixin is used to specify how to bring monitoring data from a resource instance to a Sensor resource; (2) an aggregator mixin specifies the eventual aggregation functions to be applied on monitoring data and; (3) a publisher mixin specifies how to publish the monitoring data. We were inspired by this work to extend OCCI to provide a Monitoring and Reconfiguration infrastructure on demand.

Here, the Analyzer sends a HTTP message to the Reconfiguration Manager whenever the monitoring data does not meet the SLA. The alert contains the value of the monitoring data and the required value indicated in the SLA. When the Reconfiguration Manager receives the alert it applies a specific strategy to generate one or more reconfiguration actions. These actions are applied on the managed resource through an ActionLink. Every reconfiguration action represents an instance of the ActionTool mixin collection. It details the reconfiguration action, and how to apply it.

Nagios [13] is an open-source core system for network monitoring. It allows monitoring IT infrastructure to ensure that systems, applications and services are functioning properly. Monitoring can be applied on private or public services (private services are services and attributes of a server and public services are those available across network). To monitor any target, Nagios uses a list of plug-ins that would be executed to poll the target status. A plug-in acts as an abstraction layer between the monitoring daemon and the monitored targets. It enables remote command execution to know the status of the monitored target. There are several plug-ins for different protocols as SNMP, NRPE or SSH. Monitoring using Nagios

The activation of the ScaleUpDiskAction action results on an activation of the Reconfiguration mixin operation (i.e, invokeAction()) with the method attribute of the mixin. In this case, the Reconfiguration mixin can reconfigure the DataB resource without service interruption. In other cases, the ActionTool instance may contain an action to replace one or more resources. The Reconfiguration mixin may synchronize all the bindings incoming or outgoing the resource. The resulting infrastructure is shown in Figure 3.

544

mx:reconfiguration

mx:Polling getAttributes() getAttributeValue()

setAttributeValue() getActions() invokeAction() changeConnectionState()

mx:diskRule mx:diskSizeSubscription

rule="if freeDisk