Health rules let you specify the parameters that represent what you consider normal or expected operations for your environment. The parameters rely on metric values, for example, the average response time for a business transaction or CPU utilization for a node.

When the performance of an entity affected by the health rule violates the rule's conditions, a health rule violation occurs. The health statuses are represented as critical, warning, normal, and unknown. 

When the health status of an entity changes, a health rule violation event occurs. Examples of a health rule violation include:

• Starting
• Ending
• Upgrading from warning to critical or 
• Downgrading from critical to warning

The health statuses of entities and health rule violations are surfaced in the controller user interface. A health rule violation event can also be used to trigger a policy, which can initiate automatic actions, such as, sending alerting emails or running remedial scripts.

You create health rules using the health rule wizard, described in Configure Health Rules. The wizard groups commonly-used system entities and related metrics to simplify setting up health rules. You can also use the default health rules as-is, or modify them.

Default Health Rules

provides a default set of health rules for some products, such as applications and servers. These default health rules vary depending on the entity. To see the default rules, before any health rules have been added to your  installation:

1. From the Alert & Respond tab, click Health Rules.
2. Select the entity.
   The default health rules for the selected entity are displayed.

If any of these predefined health rules are violated, the affected entities are marked in the UI as yellow-orange if it is a Warning violation and red if it is a Critical violation.

In many cases, the default health rules may be the only health rules that you need. You can edit and customize the health rules to suit your application. You can also disable the default health rules.

Health Rule Scopes

The health rule scope determines the set of default health rule types. You can choose the scope to get a set of default health rule types for applications, servers, or databases. For example, when you define a mobile application as the scope, the default health rules such as crash rates and HTTP/network error rates are displayed. Similarly, if you define the health rule scope for an application, the health rules would be for business transactions, CPU/memory utilization, and so on.

From Alert & Respond > Health Rules, you can select one of the following health rule scopes from the drop-down list:

• Applications
• User Experience: Browser Apps
• User Experience: Mobile Apps
• User Experience: API Monitoring
• Event Storage: Overage Monitoring
• Databases
• Servers
• Analytics

You can also create new health rules to add to the default set for each scope. You may want to add the health rule app starts to your mobile application. This health rule is not part of the default set of health rules in the mobile app scope, so you would just need to add a new health rule.

Heath Rule Types

The health rule wizard groups health rules into types that are categorized by the entity that the health rule covers. This allows the wizard to display appropriate configuration items during the health rule creation.

The following table lists various health rule types.

When you select one of these health rule types, the wizard offers you the metrics commonly associated with that type in an embedded browser.

How to Set Up Health Rules?

 recommends the following process to set up health rules for your application:

1. Identify the key metrics (performance indicators) on the key entities that you need to monitor.
2. Click Alert & Respond > Health Rules to examine any default health rules.
   • Compare your list of metrics with the metrics configured for the default rules.
   • You can view the list of affected entities for each of the default health rules and modify them. See Configure Affected Entities.

   • If the default health rules cover all the key metrics you need, determine if the pre-configured conditions are applicable to your environment. If required, modify the conditions.

     Define a metric expression to evaluate complex criteria for a condition. Define a boolean expression to evaluate multiple health rule conditions.

3. If default health rules do not cover all your requirements or if you need finely-applied health rules to cover specific use cases, create new health rules.
   1. Identify the type of health rule that you want to create. See Health Rule Types.
   2. Decide which entities are affected by the new rule. See Entities Affected by a Health Rule.
   3. Define the conditions to monitor. See Create and Configure Conditions.
4. If you want the health rules to be evaluated according to a pre-defined time schedule, create a health rule schedule. In some situations, a health rule is more useful if it is evaluated at a particular time. See Health Rule Schedules.

After you set up health rules you must configure policies and actions to be executed when health rules are violated. See Policies and Actions.

Additional Considerations

• Your application status is based on health rules for the current time range. If you disable old health rule policies or enable new ones, you might see errors in red in your application status, even if there are no current critical events based on the new policies. To verify that your new or disabled health rule policies have taken effect, change the time range in your dashboard to a smaller, more recent time frame.

• When you are configuring health rules for business transactions with baseline selected in the configured condition with a very fast average response time (ART) such as 25 ms, using standard deviation as a criterion can cause the health rule to be violated too frequently. The health rule may violate too frequently because a tiny increase in response time can represent multiple standard deviations. In this case, consider adding a second condition that sets a minimum ART as a threshold. For example, if you do not want to be notified unless ART is over 50 ms, you could set your threshold as ART > 2 Standard Deviations and ART > 50 ms.