Different Levels for Enabling Alert Thresholds

Before you adjust datapoint thresholds, it is important to determine at which level they should be adjusted. The following are the different levels for enabling alert thresholds:

• Global DataSource definition level—Thresholds adjusted at the global level cascade down to every instance (across all resources) to which the DataSource is applied
• Resource group level—Thresholds adjusted at the resource group level cascade down to all instances for all resources in the resource group (and its subgroups)

• Resource DataSource level—If the instances and their parent instance groups do not have their own defined thresholds, then they inherit the threshold set at their resource datasource level. The threshold is applicable only to multi-instance resource datasources.

• Instance group level–If the instances do not have their own defined thresholds, then they inherit the threshold set at their instance group level.
• Instance level–Thresholds adjusted at the instance level can be configured to apply to a single instance on a single resource, multiple instances on a single resource, or all instances on a single resource.

For example, if you want the adjusted thresholds to apply across all relevant resources in your network infrastructure (For example, every instance for a specific DataSource), you should adjust the thresholds at the global level within the DataSource definition. Global tuning is useful when a majority of the instances in your infrastructure benefit from the tuning. Alternatively, if the adjusted thresholds are only applicable to a single instance of a single resource, you are required to adjust the thresholds at the instance level.

Static or dynamic datapoint thresholds, cascade down from the global level. However, if alternate threshold configurations are encountered at deeper levels in the Resources tree, those deeper configurations override the ones found at a higher level. For example, thresholds set at the instance level completely override those set at the resource group and global levels, and those set at the group level override those set at the global level.

The following table illustrates the set of threshold configurations that are used when evaluating a data point. When interpreting the table, assume the following conditions:

• The datapoint being evaluated belongs to DataSource F
• The datapoint being evaluated resides in Instance A
• Instance A resides in a resource that is a member of Resource Groups D and E
• Resource groups D and E are siblings on the Resources tree. Resource Group D was created first followed by Resource Group E.
• Instance A resides in the Instance Group B
• DataSource F is applied on a resource and is mapped with Resource Datasource C

Threshold Configurations Present Across Various Levels						Configurations that Take Precedence for the Datapoint on Instance A
Instance A	Instance Group B	Resource DataSource C	Resource Group D	Resource Group E	DataSource F
No	No	No	No	No	Yes	The configurations set for the global DataSource F definition is inherited and applied.
No	No	No	No	Yes	Yes	The configurations set for the Resource Group E is inherited and applied.
No	No	No	Yes	No	Yes	The configurations set for the Resource Group D is inherited and applied.
No	No	No	Yes	Yes	Yes	The configurations set for the Resource Group D is inherited and applied. (When a resource belongs to two sibling resource groups, the configurations of the resource group that was created first, in this case the Resource Group D, take precedence.)
No	No	Yes	Yes	No	Yes	The configurations set for the Resource DataSource C is inherited and applied.
No	Yes	Yes	No	Yes	Yes	The configurations set for the Instance Group B is inherited and applied.
Yes	Yes	Yes	Yes	Yes	Yes	The configurations set for the Instance A is applied.

Assignment of Static and Dynamic Thresholds to a Single Datapoint

The assignment of both static and dynamic thresholds for a single datapoint is possible—and beneficial in the right scenario. When both types of thresholds are applied, alerting behavior becomes more flexible, enabling one or both of the following actions per datapoint: 

• Automatic generation of alerts—when values fall outside of the expected warning, error, or critical alert severity ranges set for the datapoint.
• Automatic suppression of alert notification routing—for alerts triggered by the static thresholds in place for the datapoint if the triggering value falls within the expected range of the dynamic thresholds assigned the same alert severity. For example, if a static threshold triggers an alert severity level of warning, but a dynamic threshold of the same alert severity level indicates the value is not anomalous (that is, it does not fall outside of its calculated expected range), the alert triggered by the static threshold is not subsequently routed. Regardless of whether alert notifications are routed or suppressed based on dynamic thresholds, the originating alert itself always displays within the LogicMonitor interface.

As a result of these two sets of behaviors (which can work independently or in cooperation with one another), dynamic thresholds can be used to:

• Reduce alert noise in cases where static thresholds are not tuned well, while also alerting you to issues that are not caught by static thresholds. For this scenario, static thresholds must be in place and dynamic thresholds must be configured to both suppress and trigger alerts.

• Only reduce alert noise in cases where static thresholds are not (or cannot easily) be well tuned. For this scenario, static thresholds must be in place and dynamic thresholds must be configured to suppress alerts.
  This is useful when there are different use cases for suppression and alert generation. For example, a percentage-based metric for which there is a very clear good and bad range may benefit more from suppression when it is not outside its expected range than from alert generation when it is deemed anomalous.