Identifying, Modifying, Creating, and Removing Monitor Rules for SOC

Identifying, Modifying, Creating, and Removing Monitor Rules for SOC

Ricardo Contreras Andrea Zisman [email protected] [email protected]

Software Engineering GroupSchool of Informatics

City University LondonUK

Andrea Zisman

• Background

• Motivation

• MADap Framework Overview

• Patterns

• Adaptation Process

• Initial Evaluation

• Conclusions and Future Work

Outline

Andrea Zisman

Background • Monitoring of service-based systems

– Collecting information about the execution of SBS and verifying if the system operates correctly based on system’s properties (monitor rules)

• SBS monitoring supports– adaptation, repair, and evolution of SBS– discovery and replacement of services– notification of SLA, business rules, and KPI violations– optimization of resource allocation

• Existing monitoring approached are based on:– Type of information being monitored (what)– Purpose of monitoring activity (why)– Used techniques for monitoring (how)

• Intrusive: instrumentation of the SBS or its services• Non-intrusive: use special components to capture runtime

service information

Andrea Zisman

Motivation

• Monitoring approaches– assume monitor rules are pre-defined and known

in advance

• Monitor needs to support changes in– SBS and services used by SBS– Types of interactions of users with the system– Context characteristics of the users interacting with

the system

Andrea Zisman

Motivation (Example)

Cultural event service-based system (CE_SBS)

S1: What’s going on (per city)S2: Ticket search and selectionS3: Payment S4: Performance schedulingS5: Resource search and allocation S6: Catering S7: Performance review …

Andrea Zisman

Framework Overview

• Pattern-based HCI-aware monitor adaptation framework (MADap) - changes in monitor rules due to user’s interaction and different types of user context

• Adaptation activities: identification, modification, creation, removal

• Rule patterns for different types of user context: role, skills, needs, preferences, cognition, time, location, environment

• Rules concerned with execution parts of SBS for a user context type

• User models for representing information about users• Patterns and monitor rules represented in event-

calculus (EC)

Andrea Zisman

Context Types Direct: information about the characteristics of users

Role: the social behavior of an individual within the domain of a SBS (e.g., occupation, access type, privilege)

Skill: the level of expertise of an individual with respect to a SBS (e.g., level of expertise, years of experience)

Preference: an individual’s choice over pre-established alternatives of computational resources of a SBS

Cognition: individual’s characteristics associated with the process of thought (the way that individuals think, feel or react; e.g., attention level, comprehensive ability)

Need: an individual’s requirement or desire from a SBS

Related: information that may influence data about a user Time: the moment an individual interacts with a SBS Location: the place where an individual interacts with a SBS Environment: the environment where a SBS is used

Andrea Zisman

User Context

Andrea Zisman

Event Calculus

• Why? It supports– rule representation as first order logic providing

expressiveness for large range of applications– specification of quantitative temporal constraints and

relationships– distinction between events and states– definition of influences between events and states

• It uses events and fluents to represent system’s behavior– Event: action occurring at a specific time and may

change the state of a system– Fluent: condition of a system state that may be

affected by events

Andrea Zisman

Event Calculus (Predicates)Predicate Meaning

Happens (event, t, R(t1,t2)) The occurrence of an event, at sometime t, where t is between t1 and t2

Initiates (event, fluent, t) The initialization of a fluent; which means a fluent starts to hold after an event occurs at a time t

InitiallyP (fluent) The fluent holds (is valid) from time 0

InitiallyN (fluent) The fluent does not hold from time 0

HoldsAt (fluent, t) The fluent holds (is valid) at a time t

Clipped (t1, fluent, t2) The fluent is terminated between the time interval specified by t1 and t2

Declipped (t1, fluent, t2) The fluent is initiated between the time interval specified by t1 and t2

Terminates (event, fluent, t)

The fluent ceases to hold after an event occurs at a time t

Plus: logical, relational, implication operators & axioms

Andrea Zisman

MADap Architecture

Andrea Zisman

Patterns

• Parts:– Monitor rule: properties of a systems that

need to be monitored– Assumptions: formulae to identify system’s

state information

• Event types– Operation request/response: prefix ic/ir– Initial/last event: ic_initial/ic_last– User interaction: ic/ir + user_op

Andrea Zisman

Examples: Pattern Role

R1:Happens (ic_start_CE, t1, R(t1,t1)) Happens (ic_shows, t2, R(t1,t1+2500))Ass: Happens(ic_shows, t1, R(t1, t1)) Initiates (ic_shows, list_shows, t1)

R2:Happens (ic_start_CE, t1, R(t1,t1)) Happens (ic_perfschedule, t2, R(t1,t1+3000))Ass: Happens(ic_perfschedule, t1, R(t1, t1)) Initiates (ic_perfschedule, list_perfschedule, t1)

Monitor Rule:Happens (ic_initialeventE, t1, R(t1,t1)) Happens (ic_operX, t2, R(t1,tn))Assumption: Happens(ic_operX, t, R(t, t)) Initiates (ic_operX, fluent, t)

Andrea Zisman

Pattern Cognition

R3: Happens (ic_userIdentification, t1, R(t1,t1)) Happens (ir_userIdentification, t2, R(t1,t1+90))

Assumption: Happens(ic_userIdentification, t, R(t, t)) Initiates (ic_userIdentification, userIdentification, t)

Monitor Rule:Happens (ic_OperX_User_op, t1, R(t1, t1)) Happens (ir_OperX_User_op, t2, R(t1, t1+(response time for OperX)))Assumption: Happens(ic_OperX, t1, R(t1, t1)) Initiates (ic_OperX, fluent, t1)

Andrea Zisman

Adaptation Process

Identify semi-instantiated pattern;Search for rules that match semi-instantiated pattern (SI);

C1: repository has rules Set(R) that fully match SI pattern /*verify if time values in rules are consistent */ For every rule R in Set(R){ if time values in rules are consistent {rules maintained in the repository;} if time values in rules are not consistent {rules are modified with new time values based on SLAs/historical execution data;} }

Andrea Zisman

Adaptation ProcessC2: repository has rules Set(R) that only match invariant part of SI pattern create new rule by instantiating time values for SI pattern; add new rule in repository; /*verification of the validity of rules*/ For every rule R in Set(R){ if there is valid path in SBS specification that uses R {time values for R are checked and adjusted if necessary;} if there is no valid path in SBS specification that uses R {R is removed from repository;}}

C3: repository does not have rules that match SI pattern create new rule by instantiating time values for SI pattern; add new rule in repository;

Andrea Zisman

Implementation and (Initial) Evaluation

• Prototype tool implemented

• Evaluation– CE-SBS with seven services– Demonstration of four adaptation cases:

identification, modification, creation, removal– Context types: role, skills, need, preference,

cognition– Five different cases

Andrea Zisman

Cases Results

1: Empty repository 29 rules with assumptions were created: 8 for context type role; 6 for context type need; 4 for context type skill; 8 for context type cognition; 3 for context type preference

2: Repository with 100 unrelated rules

29 rules/assumptions were created (Case 1)

3: Repository with 29 related rules

For each different context type relevant rules were identified

4: Repository with 29 related and 100 unrelated rules

For each different context type relevant rules were identified (as in Case 3)

5: Repository with 100 unrelated and 27 related rules, and 5 rules that match invariant parts for each context type

For each context type relevant rules from the 27 rules were identified, two rules were created, and 5 rules matching invariant parts were identified and checked for maintenance or removal from repository

Andrea Zisman

Conclusions and Future Work• Conclusions:

– Framework for identifying, modifying, creating, and removing monitor rules expressed in EC

– HCI-aware monitor adaptation– Use of rule patterns

• Current/Future Work:– Creation of more patterns– Evaluation:

• Performance • Use of adapted rules

– Extension of the work to support:• Adaptation of assumptions • Adaptation due to changes of several context types• Patterns/Rules specified in other formalisms