The Real User Monitoring (RUM) sub-service of Application Real-Time Monitoring Service (ARMS) allows you to configure alert rules for applications to improve the user experience. If an alert is triggered, alert notifications are sent to the contacts or DingTalk group chat based on the specified notification methods. This topic describes how to configure a static threshold in RUM alerting.
Scenarios
Web & HTML5 application: You can configure static thresholds for web & HTML5 applications to monitor key performance metrics, such as Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). If these metrics encounter anomalies, alerts are triggered to help you quickly locate and fix the anomalies, and improve user experience.
iOS and Android apps: You can configure static thresholds for iOS and Android apps to monitor key performance metrics, such as resource loading, API calls, crashes, and janks. Automatic reporting of abnormal stacks and crash logs helps you quickly locate and fix the anomalies and improve user experience.
Example:
After a new version of an app was released, the number of application janks significantly increased. In this case, you can configure a static threshold for the number of janks so that you can identify and fix them promptly, thus preventing more users from being affected.
Prerequisites
The application is monitored in RUM. For more information, see Integrate applications.
Procedure
Log on to the ARMS console.
In the left-side navigation pane, choose , and then click Create Alert Rule.
On the Create an alert rule page, specify an alert rule name and set the Alert Detection Type parameter to Threshold Detection.
In the Alert Contact section, specify the application, metric type, and filter condition.
In the alert rule section, set the alert triggering mode (for example, Multiple Conditions), select the alert triggering rule (for example, Meet any of the following rules), and configure the alert conditions (for example, if the average number of anomalies in the last 5 minutes is greater than or equal to 15). The page displays a trend chart for the metric with a threshold reference line to help you verify the threshold. Set the alert level (optional: P1:critical, P2:error, P3:warning, or P4:page) and the notification policy.
Parameter
Description
Select Applications
Select the application for which you want to create the alert rule. You can select multiple applications or all applications.
Automatically apply this alert rule to newly created applications
Specify whether to automatically apply this alert rule to applications that are later added to RUM.
Metric Type
Select the type of the metric that you want to detect. For more information, see RUM alert rule metrics.
NoteThe values of the Alert Condition and Filter Condition parameters vary with the value of the Metric Type parameter.
Filters
Further filter the metric data to narrow down the monitoring scope.
The condition for filtering data related to the dimension. Valid values:
Traverse: matches all alerts of the dimension.
=/!=: exactly matches or excludes alerts of the dimension based on one or more values.
Contain/Do Not Contain: fuzzily matches or excludes alerts of the dimension based on one or more values.
NoteIf you want to display information about a dimension in an alert notification, you must specify the dimension and filter condition. Otherwise, the data is aggregated in the metric query results.
In the Alert rules section, set the following parameters.
Parameter
Description
Alert Triggering Mode
Single Condition: Specify one condition.
Multiple Conditions: Set the Alert Triggering Rules parameter to specify multiple conditions. Valid values:
Meet All the Following Rules: Alerts are triggered only if all the conditions are met.
Meet One of the Following Rules: Alerts are triggered if one of the conditions is met.
Alert Condition
Configure alert conditions based on the selected metric type.
Time Period: Select the time period for triggering alerts. Example: 5.
Metric: Select the alert metric.
Condition: Select the condition for triggering alerts. Valid values: Greater Than or Equal To, Less Than or Equal To, Month-on-Month Increase %, Month-on-Month Decrease %, Hour-on-Hour Increase %, Hour-on-Hour Decrease %, Day-on-Day Increase %, and Day-on-Day Decrease %.
NoteIn an alert notification, you can evaluate whether the specified static threshold is reasonable and check whether the threshold has recently been triggered. For more information, see the View alert details section.
Alert Level
The system provides four built-in alert levels. You can configure a notification policy based on the alert level.
For example, you can configure phone calls for P1 alerts and DingTalk group notifications for others.
P1: critical
P2: error
P3: warning
P4: page
Enter P4 recommended threshold
You can adjust the threshold based on the metrics shown in the chart preview section. To apply the rule to multiple applications, click the
icon next to Application to generate different recommended thresholds for the applications. ARMS uses an intelligent algorithm to generate a recommended threshold based on the historical metric data. For more information, see the Recommended thresholds section.
Alert Quantity Prediction
View the 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 the alerts at the historical points in time.
Each time you create or modify an alert rule, we recommend that you use the alert prediction feature. This feature uses an anomaly detection algorithm to analyze historical data and predict the number of alerts within the specified time period. Then, you can adjust a static threshold based on the prediction results. For more information, see the Alert prediction section.
Configure the Notification Policy parameter and parameters in the Advanced Alert Settings section.
Parameter
Description
Notification Policy
Do Not Specify Notification Policy: If alerts are triggered, no notification is sent. Notifications are sent only when the matching rules of a notification policy is triggered.
Specify a notification policy: If you specify a notification policy, ARMS sends notifications by using the notification method specified in the notification policy. You can select an existing notification policy or create a notification policy. For more information, see Notification policies.
Advanced Alert Settings
No data
This parameter is used to fix data anomalies, such as missing data, abnormal composite metrics, and abnormal period-over-period comparison results. If data anomalies can be fixed, the data is automatically changed to 0 or 1, or the alert is not triggered.
For more information, see Terms.
Click Save.
View alert details
After you receive an alert notification, you can view the alert details in a or on the page of the ARMS console.
In the following scenarios, the Alert Event History page does not support redirection to the RUM module:
The alert conditions contain aggregation metrics, such as the number of anomalies, the number of resources, or the number of janks.
The alert conditions contain period-over-period comparison, such as Month-on-Month Increase %, Month-on-Month Decrease %, Hour-on-Hour Increase %, Hour-on-Hour Decrease %, Day-on-Day Increase %, or Day-on-Day Decrease %.
Alert Event History
On the Alert Event History page, click the name of an alert event. In the panel that appears, you can view details of the alert. For more information, see Alert event history.
The event details panel includes fields such as Event Name, Level, Description, Status, Object, Count, Start Time, End Time, URL, Integration Name, Integration Type, and Alert Type, as well as the Labels and Annotations tabs. A Retrospect Event Processing Flow link is available in the upper-right corner of the panel.
Click the URL of an event to go to the Data Exploration page of the RUM module to view the raw data that triggered the alert.
The page includes a quick filter panel on the left for filtering by application, app version, environment type, and more. The main area displays session statistics (user and session counts), a session trend chart, and a list of session details including session ID, time, client IP address, session duration, view count, anomaly count, and resource request count.
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.