Policy and Health Rule Configuration Matrix

[pclark]

This article describes how policies and health rules behave depending on which entities/objects are used in the configuration.

You can specify affected entities, such as nodes and tiers, in both Health rules and policies. It is important to understand how various combinations of "affected entity" selections affect the overall policy behavior.

Here are some examples to illustrate the interactions.

Table of Contents

• Health Rule Examples 
• Policy Examples 
• Policy Matching Combination Examples 

Health Rule Examples

• Health- Rule-1 (HR1) specifies a health rule violation (HRV) on Tier-1 when metric-1 > 0.
• Health-Rule-2 (HR2) specifies a HRV on all nodes in Tier-1 when metric-1 > 0.
• Health-Rule-3 (HR3) specifes a HRV on any node in Tier-1 when metric-1 > 0.

When the policy/health rule engine detects that metric-1 is greater than 0 for one of these health rules, the resulting events are different for each combination as shown in this table:

Health Rule Example	Affected Entity	Resulting Events when metric-1 > 0
Health Rule	Node and Tier	Results when engine detects metric-1 > 0
HR1	Tier-1	1 HRV event for the tier only.
HR2	all nodes in Tier-1	1 HRV for each violating node in the tier. No HRV event for the tier.
HR3	any node in Tier-1	A single HRV event for the tier and all violating nodes in the tier

Policy Examples

When you configure your alerting policies  based on the above health rules, the corresponding policies will fire alerts as follows:

Policy Example	Affected Object	Result
Policy-1	Tier	policy fires the alert for HR1
Policy-2	node	policy fires the alert for HR2 or HR3

This behavior is by design and provides flexibility for deciding when alerts are needed. For, example what does it mean for a tier to be unhealthy? Depending on the specific metric that is used, you can decide the tier is unhealthy even if all the nodes are healthy. Here are some examples of using different metrics with each type of health rule:

HR1	Metric-1= active database connections > X (some number)	You would use this configuration because you are concerned with the total number of connections for the tier not the # of connections for each node.
HR2	Metric-1 = memory utilization % > 80%	Here you want to know if the HRV occurs on any node because it may indicate a problem on that specific node, although the others are healthy.
HR3	Metric-1 = calls per minute > X	Say you are using a load balancer in round-robin fashion. If the load on one node is higher than the others, you might have a problem with the load balancer, so you would want to alert if any node has a HRV.

Policy Matching Combination Examples

This table specifies the result of using different combinations of event type, health rules, and objects in the Policy configuration. 

Health Rule Violation Started - Critical Slow transaction
1	*any	*any	Policy fires when any health rule violates at the critical level or any transaction is slow for the application. In other words, any slow transaction on any tier or any health rule violation at the critical threshold causes this policy to fire.
2	Health Rule-1 Health Rule-2	*any	Policy fires for a slow transaction or for a violation of Health Rule-1 or Health Rule-2 for any object across the application. This policy example fires even if the object specified in the health rule configuration is a specific tier or node or set of nodes. The "Any Object" configuration in the policy causes the policy engine to ignore the objects specified in Health Rule-1 and Health Rule-2.
3	*any	Tier 1	This policy fires for any slow transaction on Tier 1 or for any Health Rule Violation Started - Critical event on tier 1 for any health rule.
4	Health Rule-1 Health Rule-2	Tier 1	This policy fires for a slow transaction or any Health Rule Violation Started - Critical event on tier 1 for Health Rule-1 or Health Rule-2. Note, if you were to configure Health Rule-1 or Health Rule-2 for any node in Tier 1 this policy would never fire.