Runtime Monitoring - Capabilities

This capability consists in monitoring the execution of a Service Instance (sometimes called Application, Task or Job)with an associated contract, namely the SLA, and evaluating if the contract is satisfied. During execution, if some parameter associated to a SLO of the SLA reaches defined threshold, a violation threat is detected and recovery actions are taken in order to guarantee the SLA, or minimise the consequences of an effective breach of the contract. Among the recovery actions, we can foresee re-allocation of application tasks on available resources, acquisition of additional resources, but there exist other recovery action available to the Service Provider that can guarantee the SLA.

The capability works according to the following flow:

mapping of high level application-specific business objectives (negotiated between client and provider and formalised into a Pre-SLA document) into low-level infrastructural parameters (such as CPU, bandwidth, memory usage) that can be quantitatively measured (usually supported by OS probes). This mapping happens on the basis of specific schemas or rules that are defined by the actor providing the application to monitor (e.g. Application or Service provider, who is the application domain expert);
after the mapping of high level objectives into low-level parameters, the full SLA is created, stored and, when the client asks for the application, the SLA is retrieved and its metrics are monitored;
if some parameter associated to an SLO reaches a threshold, in order to avoid penalties, a violation alarm is generated and recovery actions are taken in order to return to normal execution values.

This capability has to allow separation of application monitoring from monitoring of the infrastructural resources (e.g. hosts) where the application is running.
A component providing this capability (from now on: Runtime Monitoring component) has to

interact with components that are able to monitor the parameters of the hosts (from now on: Host Monitoring component);
offer an interface allowing on-the-fly modification of the alarm thresholds, and should allow graphical visualisation of the metrics;
analyse monitored data on the basis of rules and generate violation threat events when threat thresholds are reached;
Send threat alerts to the provider allowing him to take action to try to prevent the violation

An option to this capacity is the possibility to offer information to the user who signed the SLA informing him of the current SLA status. This poses the problem of knowing who owns and runs the component implementing this capacity. If the module is on the provider side (which is logical, as the provider owns the monitoring tools which come with the resources), will the provider be willing to offer this information to the user? If on the other hand, a third reliable party own this module, how can the connection be made with the providers monitored values? Fine-grained information given to the user poses the problem of trust and level of implication of the user. This can only be decided by the provider, defined by its business practices.