Application Real-Time Monitoring Service:Dynamic thresholds

When to use dynamic thresholds

Dynamic thresholds work best for metrics with stable, recurring patterns -- metrics that follow predictable trends. Common use cases include:

• Application performance: Detect unusual response time or request rate changes. If the response time of an API suddenly exceeds the learned pattern, an exception event is generated immediately.

• Server resource utilization: Monitor CPU utilization and memory usage. If resource consumption consistently exceeds the predicted range, an exception event is generated so you can adjust resource allocation before system stability is affected.

• Connection pool analysis: Track query rates and concurrent connection counts. If some metrics of a thread exceed the dynamic thresholds, an exception event is triggered for timely performance tuning.

• Microservice health: Monitor resource usage and response performance across microservices. Because microservice dependencies are complex, dynamic thresholds help you quickly isolate which service is behaving abnormally.

How dynamic thresholds work

ARMS uses the Prophet algorithm to power dynamic thresholds. The system operates on a daily cycle:

1. Every 24 hours, ARMS analyzes the last 7 days of historical data for each monitored metric.

2. The algorithm extracts the metric's trend (long-term direction) and seasonality (recurring patterns).

3. Based on these patterns and the metric's natural fluctuations, ARMS calculates an upper boundary and lower boundary for the next 24 hours.

4. Any data point that falls outside this predicted range is flagged as anomalous.

Unlike static thresholds, dynamic thresholds do not require manual updates when your application's traffic patterns change. Because ARMS retrains the model daily, the boundaries automatically adapt to gradual shifts in metric behavior.

Prerequisites

Before you begin, make sure that you have:

• An application monitored by Application Monitoring

Create a dynamic threshold alert rule

1. Log on to the ARMS console.

2. In the left-side navigation pane, choose Application Monitoring > Application Monitoring Alert Rules.

3. On the Application Monitoring Alert Rules page, click Create Alert Rule.

4. On the Create Application Monitoring Alert Rule page, specify Alert Rule Name and set Alert Detection Type to Interval detection.

   Note

   To configure static thresholds instead, see Static thresholds.

5. In the Alert Contact section, configure the following parameters:

   Parameter	Description
   Select Applications	Select the application to monitor. You can select only one application per anomaly detection rule.
   Metric Type	Select the metric to monitor. For available metrics, see Alert metrics. After you select a metric type, ARMS calculates upper and lower boundaries and renders the metric trend in real time. Preview the results in the Alert Condition section. The initial rendering takes about 2 to 4 seconds. For details on how boundaries are calculated, see How dynamic thresholds work.
   Filter Condition	Filter metric data to narrow the monitoring scope. Select a filter operator for each dimension: Traverse: Match all values of the dimension. No Dimension: Show all alerts for the metric type without dimension filtering. =: Exactly match one or more specified values. !=: Exclude one or more specified values. Contain: Fuzzy-match one or more values. Do Not Contain: Fuzzy-exclude one or more values. Match Regular Expression: Match values using a regular expression.

   Note

   The available Alert Condition and Filter Condition options change based on the selected Metric Type.

6. In the Alert rules section, configure the Alert Condition parameter:

   Parameter	Description
   Alert trigger mode	Select Single Condition.
   Alert Condition	Configure the detection rule: Last X Minutes: The lookback window for evaluation. Maximum: 60 minutes. Data: The metric data to evaluate (for example, call count or response time). Calculation method: How the data is aggregated (for example, average, maximum, or minimum). Comparison method: How the aggregated value is compared against the dynamic threshold. See the Comparison method reference table for guidance. Alert level: The severity of triggered alerts. Valid values: P1, P2, P3, P4.
   Tolerance	Controls the width of the acceptable data range. A higher tolerance value produces a wider range and fewer alerts. A lower tolerance value produces a narrower range and more alerts. Adjust this value based on alert quantity prediction results.
   Alert Quantity Prediction	Displays the predicted number of alerts that are expected to be triggered within the time period. Click the number to query the data that is expected to trigger alerts at the historical points in time. Each time you create or modify an alert rule, use this prediction to fine-tune your tolerance before saving the rule. For more information, see Validate rules with alert quantity prediction.

   In the data preview chart, blue points represent actual data points, and the green band represents the acceptable data range.

   Comparison method reference

   Select the comparison method based on the type of anomaly you want to detect:

   Comparison method	Behavior
   Outside the range of the dynamic threshold	Triggers an alert when a data point falls above the upper boundary or below the lower boundary.
   Larger than the maximum value of the dynamic threshold	Triggers an alert only when a data point exceeds the upper boundary.
   Lower than the minimum value of the dynamic threshold	Triggers an alert only when a data point drops below the lower boundary.

7. Configure the Alert Notification and Advanced Alert Settings parameters:

   Parameter	Description
   Notification Policy	Displayed only when Alert Notification is set to Standard Mode. Options: Do Not Specify Notification Policy: Alerts are generated but no notifications are sent. Notifications are sent only when the matching rules of a notification policy are triggered. Specify a notification policy: Select an existing notification policy or create one. For more information, see Create and manage a notification policy.
   No data	Handles data anomalies such as missing data points, abnormal composite metrics, and abnormal period-over-period comparison results. When fixable, the system automatically changes the value to 0 or 1, or suppresses the alert. For more information, see Terms.

8. Click Save.

Validate rules with alert quantity prediction

Use alert quantity prediction to validate your configuration before saving a rule. The feature analyzes historical data, displays the time when historical alerts occur, and predicts the number of alerts within a specified period of time. It also provides the metric details, including the specific time when each threshold is exceeded, so you can adjust thresholds based on your business requirements.

Review the predicted alert count each time you create or modify an alert rule. Adjust the tolerance or comparison method if the predicted volume is too high or too low.

FAQ

What to do next

• View historical alert events to investigate triggered alerts.

• View historical alerts to review alert notifications.