Identifying, Modifying, Creating, and Removing Monitor Rules for SOC
-
Upload
leslie-cooley -
Category
Documents
-
view
36 -
download
5
description
Transcript of 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