Application metrics such as error rates, response times, and JVM garbage collection counts typically have well-understood baselines. Static threshold alert rules in Application Real-Time Monitoring Service (ARMS) evaluate these metrics against fixed values you define and trigger alerts when those values are exceeded, so the specified contacts are notified before users are affected.
For metrics without clear baselines -- such as request latency on services with variable traffic patterns -- use dynamic thresholds instead. Dynamic thresholds detect anomalies algorithmically based on historical patterns.
How static thresholds work
A static threshold rule evaluates a metric expression and compares the result to values you set for each severity level (P4 through P1). When the result exceeds a threshold, ARMS generates an alert at the corresponding level.
You can define:
Single condition rules that evaluate one expression with up to four severity tiers.
Multiple condition rules that combine two or more expressions and trigger only when all conditions (or any single condition) are met.
ARMS also provides two built-in tools to help you set and validate thresholds:
| Tool | What it does |
|---|---|
| Recommended thresholds | Analyzes the last three days of metric data using the N-sigma algorithm and suggests a P4 threshold for each application and interface. Use this as a starting point, then set P3, P2, and P1 values based on your tolerance for alert noise. |
| Alert quantity prediction | Applies an anomaly detection algorithm to the last 24 hours of metric data and predicts how many alerts the current thresholds would generate. Click the predicted count to see exact timestamps when thresholds were exceeded historically. |
Prerequisites
Before you begin, make sure that you have:
An application monitored by Application Monitoring. For more information, see Application Monitoring overview
Create a static threshold alert rule
Log on to the ARMS console.
In the left-side navigation pane, choose .
On the Application Monitoring Alert Rules page, click Create Alert Rule.
On the Create Application Monitoring Alert Rule page, set Alert Rule Name and set Alert Detection Type to Threshold Detection.
In the Alert Contact section, specify the application, metric type, and filter condition.
Parameter
Description
Select Applications
Select one or more applications to monitor. To monitor all applications, select all.
Automatically apply this alert rule to newly created applications
When enabled, this rule is automatically applied to applications that are later integrated into Application Monitoring.
Metric Type
Select the metric to evaluate. The available options for Alert Condition and Filter Condition change based on your selection. For details, see Alert metrics.
Filter Condition
Narrow the monitoring scope by filtering on specific dimensions.
Filter condition options
Option Behavior Traverse The alert shows the specific dimension value that triggered it. No Dimension The alert shows the aggregated sum across all dimension values. = The alert shows only the specified dimension values. != The alert shows all dimension values except the specified ones. Contain The alert shows dimension values that contain the specified text. Do Not Contain The alert shows all dimension values except those that contain the specified text. Match Regular Expression The alert shows only the dimension values that match the specified regular expression. In the Alert rules section, set Alert trigger mode and Alert Condition.
Alert trigger mode determines whether the rule evaluates a single expression or combines multiple expressions:
Single Condition: Evaluate one expression. Define thresholds at up to four severity levels.
Multiple Conditions: Combine two or more expressions. Set the Alert Triggering Rules parameter to control how conditions are combined:
Meet All the Following Rules: The alert triggers only when all conditions are met simultaneously.
Meet One of the Following Rules: The alert triggers when any single condition is met.
Alert levels
ARMS supports four alert levels, from lowest to highest severity: P4, P3, P2, P1. Assign different thresholds to each level based on your operational requirements. You do not need to configure all four levels.
Example: single condition
Monitor JVM full GC count over the last 5 minutes:
Condition Level Average full GCs > 1 P4 Average full GCs > 2 P3 Average full GCs > 5 P2 Average full GCs > 10 P1 A minimal configuration is also valid -- for example, trigger a P4 alert whenever the average full GC count exceeds 1.
Example: multiple conditions
Set Alert Triggering Rules to Meet All the Following Rules, then define:
Condition 1: Average error rate over the last 2 minutes >= 5%
Condition 2: Total call count over the last 2 minutes >= 200
In Multiple Conditions mode, the Alert Level parameter is required. Click Add Condition to add more conditions.
Tune thresholds with recommended values
Click Enter P4 recommended threshold to generate a suggested P4 threshold based on historical data. ARMS analyzes the last three days of metric data for each application and interface using the N-sigma algorithm, calculating the mean and variance to produce a statistically grounded starting value. Because P4 is the lowest severity level, use it as a baseline and adjust P3, P2, and P1 thresholds according to your tolerance for alert noise.
To generate per-application recommendations when the rule covers multiple applications, click the
icon next to Application. Review the chart preview to compare recommended values against actual historical data and adjust as needed.Preview alert volume with alert quantity prediction
Check the Alert Quantity Prediction value each time you create or modify a rule. ARMS applies an anomaly detection algorithm to the last 24 hours of metric data and predicts how many alerts the current thresholds would generate. Click the predicted count to see the exact timestamps when thresholds were exceeded historically. Use this information to fine-tune thresholds and reduce unnecessary alerts.
Configure the Notification Policy parameter.
Option
Behavior
Do Not Specify Notification Policy
No notification is sent when the alert triggers. Notifications are sent only when the matching rules of a notification policy are triggered.
Specify a notification policy
ARMS sends notifications through the selected policy when the alert triggers. Select an existing notification policy or create one. For more information, see Create and manage a notification policy.
In the Advanced Alert Settings section, configure the No data parameter to control how ARMS handles missing or incomplete data.
This parameter covers scenarios such as gaps in data collection, abnormal composite metrics, and unexpected period-over-period comparison results. When ARMS detects these anomalies, it either substitutes the missing values with 0 or 1, or the alert is not triggered. For more information, see Terms.
Click Save.
When to use recommended thresholds
Recommended thresholds are most useful in two scenarios:
Noisy alerts on stable systems: If a metric frequently triggers alerts even though the system operates normally, the current threshold may be too sensitive. Generate a recommended threshold to recalibrate.
Scaling across many applications: When the same alert rule applies to dozens of applications and interfaces, manually setting thresholds for each is impractical. Use the algorithm to generate tailored thresholds at scale.
How the algorithm works
ARMS pulls metric data for each application and interface from the last three days and applies the N-sigma algorithm to compute the mean and variance. Under the assumption that your workload is stable and metric values follow a normal distribution, values beyond three standard deviations from the mean are statistically rare. ARMS uses this boundary as the recommended P4 threshold.
P4 represents the lowest severity. Use it as a baseline and set stricter thresholds for P3, P2, and P1 based on your operational requirements.
When to use alert quantity prediction
The alert quantity prediction feature uses an algorithm to analyze historical data, display the time when historical alerts occur, and then predicts the number of alerts within a specified period of time. The feature helps you configure static thresholds or improve alert sensitivity for dynamic thresholds.
How it works
ARMS examines metric data from the last 24 hours and counts how many times each threshold was breached. It then predicts the number of alerts that would trigger within the configured time window. Detailed results include the specific timestamps of each historical breach, helping you verify whether those incidents were genuine or noise.