Real User Monitoring (RUM) Metrics Detection¶

About This Document

This document is the second step in the detection rule configuration flow. After completing the configuration, return to the main document to continue with Step 3: Event Notification.

Used to monitor RUM metrics data in the workspace. It supports setting threshold ranges for the performance metrics of multiple application types, including Web, Android, iOS, Miniapp, React Native, and HarmonyOS. When a metric exceeds the threshold, the system automatically triggers an alert.

Suitable for scenarios where frontend application performance needs to be monitored. For example, monitor the JS error rate by city dimension on the Web, or monitor the page load time of Miniapp and the crash rate of mobile applications.

Detection Configuration¶

Detection Frequency¶

Set the time period at which detection is executed.

Preset options: 1 minute, 5 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour
Default selection: 5 minutes
Crontab mode: Click "switch to Crontab mode" to configure a custom schedule. Scheduled task execution can be configured based on periods such as seconds, minutes, hours, days, months, and weeks.

Detection Range¶

Set the data time range queried by each detection (❗️The detection range must be greater than or equal to the detection frequency and must match the actual data reporting interval to avoid missed detections or false positives).

Detection Frequency	Detection Range (Dropdown Options)
30s	1m/5m/15m/30m/1h/3h
1m	1m/5m/15m/30m/1h/3h
5m	5m/15m/30m/1h/3h
15m	15m/30m/1h/3h/6h
30m	30m/1h/3h/6h
1h	1h/3h/6h/12h/24h
6h	6h/12h/24h
12h	12h/24h
24h	24h

Custom format: Enter a custom detection range, e.g., 20m (last 20 minutes), 2h (last 2 hours), 1d (last 1 day).

Detection Metrics¶

Set the metric data to be detected. You can configure metric data under a single application type in the current workspace (❗️Avoid selecting high-cardinality fields as detection dimensions. If configured improperly, the trigger conditions may become too loose and cause frequent alerts. The current query returns a maximum of 100,000 records).

Configuration Elements¶

Configuration Item	Description
Application Type	The application types supported by RUM, including: Web, Android, iOS, Miniapp, HarmonyOS
Application Name	Retrieves the corresponding application list based on the selected application type. You can select All or specific applications
Metric	Displays the corresponding performance metrics according to the application type. See the Metric Descriptions below for details
Filter Conditions	Filters the detection metric data based on metric tags to qualify the data range to be detected. Supports adding one or more tag filters, as well as fuzzy match and fuzzy mismatch filter conditions
Detection Dimensions	Any string-type (`keyword`) field in the configured data can be selected as a detection dimension. Currently, up to three fields can be selected as detection dimensions. A combination of multiple detection dimension fields identifies a specific detection object. The system determines whether the statistical metric corresponding to a detection object meets the trigger condition threshold; if so, an event is generated. (For example, if `host` and `host_ip` are selected as detection dimensions, the detection object can be `{host: host1, host_ip: 127.0.0.1}`.)
Additional Info	Additional fields are used only for supplementary queries and do not participate in trigger condition evaluation. You can include them in event notifications. If multiple matching values are detected, one record is returned at random

Web / Miniapp Metric Descriptions¶

Metric	DQL Query Example
JS Error Count	`R::error:(count(`__docid`) as`JS 错误数`) { app_id = '<应用 ID>' }`
JS Error Rate	Web: `eval(A/B, alias='页面 JS 错误率', A="R::view:(count(view_url)) {view_error_count > 0, app_id = '<应用 ID>'}", B="R::view:(count(view_url)) { app_id = '<应用 ID>'}")` Miniapp: `eval(A/B, alias='JS 错误率', A="R::view:(count(view_name)) {view_error_count > 0, app_id = '<应用 ID>' }", B="R::view:(count(view_name)) { app_id = '<应用 ID>' }")`
Resource Error Count	`R::resource:(count(resource_url) as`资源错误数`) {resource_status >=400, app_id = '<应用 ID>'}"`
Resource Error Rate	`eval(A/B, alias='资源错误率', A="R::resource:(count(resource_url)) { resource_status >= '400',app_id = '<应用 ID>' }", B="R::resource:(count(resource_url)) { app_id = '<应用 ID>' }")`
Average First Render Time	`R::page:(avg(page_fpt)){app_id = '<应用 ID>'}`
Average Page Load Time	`R::view:(avg(loading_time)){app_id = '<应用 ID>'}`
Slow Page Load Count	`R::resource:(count(resource_load)){app_id = '<应用 ID>',resource_load>8000000000,resource_type='document'}"`
Average Resource Load Time	`R::resource:(avg(resource_load) as`加载耗时`) {app_id = '<应用 ID>',resource_type!='document'}"`
LCP (largest_contentful_paint)	Supported aggregation functions: avg, percentile `R::view:(avg(largest_contentful_paint)){app_id = '<应用 ID>'}` `R::view:(percentile(largest_contentful_paint,75)){app_id = '<应用 ID>'}` `R::view:(percentile(largest_contentful_paint,90)){app_id = '<应用 ID>'}` `R::view:(percentile(largest_contentful_paint,99)){app_id = '<应用 ID>'}`
FID (first_input_delay)	Supported aggregation functions: avg, percentile `R::view:(avg(first_input_delay)){app_id = '<应用 ID>'}` `R::view:(percentile(first_input_delay,75)){app_id = '<应用 ID>'}` `R::view:(percentile(first_input_delay,90)){app_id = '<应用 ID>'}` `R::view:(percentile(first_input_delay,99)){app_id = '<应用 ID>'}`
CLS (cumulative_layout_shift)	Supported aggregation functions: avg, percentile `R::view:(avg(cumulative_layout_shift)){app_id = '<应用 ID>'}` `R::view:(percentile(cumulative_layout_shift,75)){app_id = '<应用 ID>'}` `R::view:(percentile(cumulative_layout_shift,90)){app_id = '<应用 ID>'}` `R::view:(percentile(cumulative_layout_shift,99)){app_id = '<应用 ID>'}`
FCP (first_contentful_paint)	Supported aggregation functions: avg, percentile `R::view:(avg(first_contentful_paint)){app_id = '<应用 ID>'}` `R::view:(percentile(first_contentful_paint,75)){app_id = '<应用 ID>'}` `R::view:(percentile(first_contentful_paint,90)){app_id = '<应用 ID>'}` `R::view:(percentile(first_contentful_paint,99)){app_id = '<应用 ID>'}`

Android / iOS Metric Descriptions¶

Metric	DQL Query Example
Launch Time	`R::action:(avg(duration)) { app_id = '<应用 ID>' ,action_type='app_cold_launch'}"`
Total Crash Count	`R::error:(count(error_type)) {app_id='<应用 ID>',error_source = 'logger' and is_web_view !='true'}"`
Total Crash Rate	`eval(A.a1/B.b1, alias='总崩溃率',A="R::error:(count(error_type) as a1) {app_id='<应用 ID>',error_source = 'logger',is_web_view !='true'} ",B="R::action:(count(action_name) as b1) { app_id = '<应用 ID>',action_type in [`launch_cold`,`launch_hot`,`launch_warm`]} ")"`
Resource Error Count	`R::resource:(count(resource_url) as`资源错误数`) {resource_status >=400, app_id = '<应用 ID>'}"`
Resource Error Rate	`eval(A/B, alias='资源错误率', A="R::resource:(count(resource_url)) { resource_status >= '400',app_id = '<应用 ID>' }", B="R::resource:(count(resource_url)) { app_id = '<应用 ID>' }")`
Average FPS	`R::view:(avg(fps_avg)) { app_id = '<应用 ID>' }"`
Average Page Load Time	`R::view:(avg(loading_time)) { app_id = '<应用 ID>' }"`
Average Resource Load Time	`R::resource:(avg(duration)) { app_id = '<应用 ID>' }"`
Freeze Count	`R::long_task:(count(view_id)) { app_id = '<应用 ID>' }"`
Page Error Rate	`eval(A/B, alias='页面错误率',A="R::view:(count(view_name)) {view_error_count > 0, app_id = '<应用 ID>' }",B="R::view:(count(view_name)) { app_id = '<应用 ID>' }")"`

Trigger Conditions¶

Configure trigger conditions and severity levels. When the query returns multiple values, an event is generated if any value satisfies the trigger condition.

Supports configuring thresholds for the four severity levels Critical, Error, Warning, Notice, as well as an OK recovery condition.

Severity	Configuration	Description
Critical	When Result >= `[值]`	Highest severity alert; requires immediate handling
Error	When Result >= `[值]`	High severity alert; requires priority handling
Warning	When Result >= `[值]`	Medium severity alert; requires attention
Notice	When Result >= `[值]`	Low severity alert; requires awareness
OK	`[N]` detections without events	After the detection rule takes effect, if within the configured custom number of detections the detection result changes from abnormal (Critical, Error, Warning, Notice) to normal, a recovery alert event is triggered. ❗️Recovery alert events are not subject to Alert Mute. If the detection count for recovery alert events is not configured, the alert event will not recover and will remain in Events > Unrecovered Events

For more details, see Event Level Descriptions.

Advanced Options¶

Consecutive Trigger Evaluation¶

When enabled, events are generated only when the trigger condition is continuously satisfied, avoiding false positives caused by transient fluctuations (❗️The maximum configuration limit is 10 times).

Bulk Alert Protection¶

Enabled by default.

When the number of alerts generated by a single detection exceeds the preset threshold, the system automatically switches to a status-based aggregation strategy: instead of processing alert objects one by one, it generates and pushes a small number of summary alerts based on the event status.

This ensures timely notification delivery while significantly reducing alert noise and avoiding the risk of timeouts caused by handling too many alerts.

When this toggle is enabled, such event details generated after subsequent monitors detect anomalies will not display historical records or related events.

Data Gap¶

The processing strategy when the detection metric returns empty query results within the detection range:

Option	Description
Do Not Trigger Events (Default)	Linked to the detection range, determines whether to generate events based on the query results of the detection metric over the most recent minutes. Suitable for scenarios where missing data is acceptable
Treat Query Results as 0	Linked to the detection range, treats the query results of the detection metric over the most recent minutes as 0, and compares them again with the thresholds configured in Trigger Conditions above to determine whether to trigger anomaly events
Custom Fill and Trigger Events	Supports custom filling of detection range values and separately triggering the following event types: Data Gap Event, Error Event, Warning Event, Notice Event, and Recovery Event. ❗️When this strategy is selected, it is recommended to configure the custom data gap duration as ≥ the detection range interval. If the configured duration is ≤ the detection range interval, both data gap and anomaly conditions may be satisfied simultaneously, in which case the data gap processing result takes precedence

When trigger conditions, data gap, and info event generation are configured together, the triggering priority is judged as follows: Data Gap > Trigger Conditions > Info Event Generation.

That is: first determine whether a data gap exists, then determine whether the threshold is triggered, and finally determine whether to generate an info event.

Info Event Generation¶

After enabling this option, configure the Info Event Generation Conditions. Only when the detection result does not trigger any of the Critical, Error, Warning, or Notice thresholds and satisfies the info event generation condition does the system write an "Info" event.

Suitable for scenarios where normal state changes or low-priority information needs to be recorded.

Subsequent Configuration¶

After completing the detection configuration above, continue with:

Event Notification: Define the event title, content, notified members, data gap handling, and related incidents;
Alert Configuration: Select an alert policy, and configure notification targets and mute periods;
Associate: Associate dashboards for quick navigation to view data;
Permissions: Set operation permissions to control who can edit or delete this monitor.