Difference between revisions of "PolicyGuidedFulfillmentLibertyPlanning PolicyBasedMonitoring"
(Created page with "This topic is part of PolicyGuidedFulfillmentLibertyPlanning == Policy Based Monitoring == * '''''Policy based monitoring enabling (Ceilometer/Monasca) during provisio...") |
|||
| Line 3: | Line 3: | ||
== Policy Based Monitoring == | == Policy Based Monitoring == | ||
| + | Goal is to be able to simply control application scalability via Congress policies using telemetry (e.g., Ceilometer, Monasca, ...) data. | ||
| − | + | It is about | |
| − | + | * modifying Murano environment before deployment by adding components as result of predeploy policy check | |
| − | + | * invocation of components public action as result of policy checks in runtime | |
| − | |||
| − | * | ||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | Policy rules: | + | '''Scenario''' |
| + | * ''Phase 1: environment modification at predeploy time'' | ||
| + | ** prior predeploy_error evaluation, there will be policy ''monitoring'' evaluated (via simulation). It will contain rules which execute actions modifying environment in Murano by adding (via Murano REST) monitoring components. Such monitoring components are responsible for configuration of corresponding monitoring system (e.g., Ceilometer's alarms,....) on deploy. User can create component for any monitoring system (e.g., watch dogs to check running Tomcat,DB,...) | ||
| + | |||
| + | * ''Phase 2: public action invocation at runtime'' | ||
| + | ** it defines binding between monitoring system and Murano. If rule detects monitoring event, it executes corresponding action in Murano (e.g., invocation of public action "scaleOut" on scalable component, ...) | ||
| + | |||
| + | '''Example''' | ||
| + | Monitoring component | ||
| + | * '''Ceilometer''' , its input parameters are 'relation to Instance', and 'alarm definition'. On deploy it creates alarm in Ceilometer. | ||
| + | |||
| + | Policy rules: | ||
execute[ add-object-to-murano(envid, name, type, instance=instance-id, alarm_expression='cpu_util>50') ] :- murano:object(instance-id,parent-id,'Instance'), murano:connected(envid, instrance-id), murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat'),.... | execute[ add-object-to-murano(envid, name, type, instance=instance-id, alarm_expression='cpu_util>50') ] :- murano:object(instance-id,parent-id,'Instance'), murano:connected(envid, instrance-id), murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat'),.... | ||
execute[murano-action(envid, scalableObject, 'scale-out' ) :- ceilometer:alarm(...instance-id,...), murano:object(instance-id,parent-id,'Instance'), murano:connected(env-id, instance-id),murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat') | execute[murano-action(envid, scalableObject, 'scale-out' ) :- ceilometer:alarm(...instance-id,...), murano:object(instance-id,parent-id,'Instance'), murano:connected(env-id, instance-id),murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat') | ||
Latest revision as of 14:26, 12 May 2015
This topic is part of PolicyGuidedFulfillmentLibertyPlanning
Policy Based Monitoring
Goal is to be able to simply control application scalability via Congress policies using telemetry (e.g., Ceilometer, Monasca, ...) data.
It is about
- modifying Murano environment before deployment by adding components as result of predeploy policy check
- invocation of components public action as result of policy checks in runtime
Scenario
- Phase 1: environment modification at predeploy time
- prior predeploy_error evaluation, there will be policy monitoring evaluated (via simulation). It will contain rules which execute actions modifying environment in Murano by adding (via Murano REST) monitoring components. Such monitoring components are responsible for configuration of corresponding monitoring system (e.g., Ceilometer's alarms,....) on deploy. User can create component for any monitoring system (e.g., watch dogs to check running Tomcat,DB,...)
- Phase 2: public action invocation at runtime
- it defines binding between monitoring system and Murano. If rule detects monitoring event, it executes corresponding action in Murano (e.g., invocation of public action "scaleOut" on scalable component, ...)
Example Monitoring component
- Ceilometer , its input parameters are 'relation to Instance', and 'alarm definition'. On deploy it creates alarm in Ceilometer.
Policy rules:
execute[ add-object-to-murano(envid, name, type, instance=instance-id, alarm_expression='cpu_util>50') ] :- murano:object(instance-id,parent-id,'Instance'), murano:connected(envid, instrance-id), murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat'),....
execute[murano-action(envid, scalableObject, 'scale-out' ) :- ceilometer:alarm(...instance-id,...), murano:object(instance-id,parent-id,'Instance'), murano:connected(env-id, instance-id),murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat')
