You can create Threshold Detection alert rules to monitor specific applications. When an alert rule is triggered, the system notifies your specified contacts or DingTalk groups so you can take appropriate action.
Prerequisites
Ensure your application is integrated with Application Monitoring. For more information, see Application Monitoring overview.
Configure threshold detection
Log on to the ARMS console.
-
In the left-side navigation pane, choose . On the page that appears, click Create Alert Rule.
-
On the Create Application Monitoring Alert Rule page, specify an Alert Rule Name, and set Alert Detection Type to Threshold Detection.
NoteFor information about how to configure dynamic thresholds, see dynamic thresholds.
-
In the Alert Contact section, select the applications to monitor, metric type, and filter conditions.
Parameter
Description
Alert Application
Select the applications to monitor. You can select one or more applications, or all applications.
Automatically apply this alert rule to newly created applications
Select this option to automatically apply this alert rule to new applications integrated with Application Monitoring.
Metric Type
Select the metric type to monitor. For more information, see Metrics for alert rules.
NoteThe available options in the Alert rules and Filter Condition sections vary based on the selected Metric Type.
Filter Condition
Filter the metric to narrow the monitoring scope.
Dimensions of the alert metric:
-
Traverse: The alert notification includes the specific dimension value that triggered the alert.
-
None: The alert notification includes the sum of all values for this dimension.
-
=: The alert includes only data for the specified dimension value.
-
!=: The alert includes data for all dimension values except the specified one.
-
Contains: The alert includes only data for dimension values that contain the specified string.
-
Does not contain: The alert includes data for all dimension values except those containing the specified string.
-
RegEx match: The alert includes data only for dimension values that match the specified regular expression.
-
-
In the Alert rules section, select an Alert Trigger Mode and set the Alert Condition.
Parameter
Description
Alert Trigger Mode
-
Single Condition: An alert is triggered when the specified condition is met.
-
Multiple Conditions: Select a rule for Alert Triggering Rules.
-
Meet All the Following Rules: An alert is triggered only when all alert conditions are met.
-
Meet One of the Following Rules: An alert is triggered if any of the alert conditions is met.
-
Alert Condition
Single Condition:
Define an expression for the alert rule. You can set different thresholds for different severity levels.
Alert severity levels range from P4 (lowest) to P1 (highest). You can configure thresholds for the levels you need. You are not required to set a threshold for every level.
Example 1: Trigger a P4 alert if the average number of JVM Full GCs in the last 5 minutes is greater than 1, a P3 alert if greater than 2, a P2 alert if greater than 5, and a P1 alert if greater than 10.
Example 2: Trigger a P4 alert if the average number of JVM Full GCs in the last 5 minutes is greater than 1.
Multiple Conditions:
Click Add Condition to define multiple alert conditions.
For example:
Alert Triggering Rules: Meet All the Following Rules
Condition 1: The average call error rate in the last 2 minutes is greater than or equal to 5%.
Condition 2: The number of calls in the last 2 minutes is greater than or equal to 200.
In Multiple Conditions mode, you must also set an Alert Level. Alert severity levels range from P4 (lowest) to P1 (highest).
Enter P4 recommended threshold
Use the comparison chart to adjust the metric's threshold. If this rule applies to multiple applications, click the
icon next to Application to generate different recommended thresholds for different applications.ARMS uses an intelligent algorithm to recommend thresholds based on historical metric data. For more information, see How recommended thresholds work.
Alert quantity prediction
Shows the estimated number of times the metric would have crossed the threshold during the selected historical period. You can click a specific number to see the metric values that would have triggered an alert at historical points in time.
Each time you create or modify an alert rule, use the alert quantity prediction feature. This feature analyzes historical data to forecast the number of alerts within a selected time frame, helping you fine-tune your thresholds. For more information, see How alert quantity prediction works.
Wait for data completeness
When enabled, the system waits until metric data is stably written before performing alert evaluation, preventing false alerts caused by data write delays or jitter.
When disabled, alert notification latency is reduced, but alerts may be triggered prematurely before all metric data has been fully written, which carries a risk of false alerts. Choose based on your business tolerance for notification latency versus alert accuracy.
-
-
Configure the Notification Policy and Advanced Alert Settings.
Parameter
Description
Notification Policy
-
Do Not Specify Notification Policy: If this option is selected, this alert rule does not send notifications directly. Notifications are only sent if the alert matches a separate notification policy.
-
Specify a notification policy: When an alert is triggered, ARMS sends alert notifications using the specified notification policy. You can select an existing policy or create a new one. For more information, see Notification policies.
Advanced Alert Settings
No data
Specifies how to handle alerts when data is missing, or for composite metrics and period-over-period comparisons. If an alert condition is not met due to a lack of data, you can configure the system to treat the value as 0 or 1, or to not trigger an alert.
For more information, see Alert Management glossary.
If you encounter an exception error when using the Alert quantity prediction feature in single-condition alert mode, this is typically caused by missing metric data without a zero-fill strategy configured. Enable the zero-fill data correction strategy under No data before using the Alert quantity prediction feature.
-
-
After you complete the configuration, click Save.
Recommended thresholds
The recommended thresholds feature analyzes historical data for your selected application, interface, and alert metric to recommend a suitable static threshold. It also generates a real-time chart comparing the metric and the threshold to help you adjust the threshold.
Use cases
-
If you frequently receive alerts for a metric but your system is operating normally, your threshold may be too low or unsuitable for certain applications or interfaces. In this case, use the recommended thresholds feature to adjust the threshold for the alert rule or for specific applications and interfaces. ARMS automatically recommends a new threshold based on historical data.
-
When you need to set different thresholds for a metric across many applications and interfaces, use the recommended thresholds feature. This feature uses an intelligent algorithm to quickly set appropriate thresholds for each application or interface, saving you the effort of manual configuration.
How it works
When you click Enter P4 recommended threshold, ARMS retrieves the last three days of historical data for the specified metric of each application and interface. It then uses the N-sigma algorithm to calculate the mean and variance. Assuming your business patterns are stable, the metric should follow a normal distribution. In this case, values that deviate significantly (for example, by three standard deviations) from the mean are rare and may indicate an anomaly. Based on this principle, ARMS suggests a threshold based on the metric's average value and volatility over the last three days.
The P4 alert level has the lowest severity. A recommended P4 threshold indicates a minor anomaly. You can use the P4 recommendation as a baseline to set thresholds for more severe alerts, such as P1, P2, and P3.
Alert quantity prediction
The alert quantity prediction feature analyzes historical data to forecast the number of alerts that would have been triggered within a selected period and shows the exact time each alert would have occurred.
How it works
ARMS analyzes the last 24 hours of metric data to predict how many alerts your proposed threshold would have generated. ARMS also provides details showing the exact times the metric value would have exceeded the threshold. You can use this information to adjust thresholds to better fit your business needs.
FAQ
Why does my alert rule with a <=threshold condition trigger during data gaps?
When you configure an alert condition using a less-than-or-equal-to operator (for example, <= 2), and the monitored object (such as a single JVM instance) experiences a data gap within the statistical period — caused by an application restart, hang, CPU saturation, network interruption, or other issue that prevents the probe from reporting data — the cumulative sum value falls below the threshold due to the missing data, triggering a false alert.
The root cause of this type of false alert is discontinuous monitoring data. Simply adjusting the threshold value cannot resolve the issue. To address it, take one or both of the following steps:
-
Investigate and resolve the cause of the data gap (for example, diagnose application availability issues such as process crashes or high CPU usage that prevent the probe from reporting metrics).
-
Configure the No data setting to define how the system handles missing metric data (for example, use the zero-fill data correction strategy to substitute 0 for missing data points during the statistical window).
Why can't I collect host monitoring or container monitoring data when creating a threshold detection alert rule?
Threshold detection is primarily designed for application monitoring metrics. If you need to configure alert rules for host monitoring or container monitoring metrics, use Interval Detection instead.