Synthetic Testing Anomaly Detection¶

Used to monitor Synthetic Monitoring (dial test) data within the workspace. You can set a threshold range for a specified volume of data generated by Synthetic Tests within a time period. Once the data volume reaches these thresholds, the system triggers an alert. Supports monitoring based on performance metrics and count statistics for protocol types such as HTTP, TCP, ICMP, WEBSOCKET, and Multistep Tests.

Applicable to scenarios such as monitoring URL availability, service port connectivity, and network latency in production environments. For example, monitoring whether the average response time or availability rate of critical business APIs meets the expected target.

Detection Configuration¶

Detection Frequency¶

Set the time period for executing detection.

• Preset options: 1 minute, 5 minutes (default), 10 minutes, 15 minutes, 30 minutes, 1 hour, 6 hours, 12 hours, 24 hours

• Crontab mode: Click "Switch to Crontab Mode" to configure a custom period. Supports scheduled task execution based on periods such as seconds, minutes, hours, days, months, and weeks.

Detection Range¶

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

• 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 metrics for detection data. You can set the specified data generated by all or individual Synthetic Tests in the current workspace as detection metrics. (❗️Avoid selecting high-cardinality fields as detection dimensions. Improper configuration with overly loose trigger conditions may cause frequent alerts. The maximum number of records returned by a query is 100,000.)

Two query modes are supported:

• Dial test metrics (based on specific performance metrics)

• Count statistics (based on data source queries)

Dial Test Metrics¶

Performs detection based on specific performance metrics of Synthetic Monitoring.

Count Statistics¶

Performs statistical detection based on dial test data sources.

You can query and count Synthetic Tests based on different dial test types by selecting the corresponding data sources (http_dial_testing, tcp_dial_testing, icmp_dial_testing, websocket_dial_testing, multi_dial_testing, etc.).

Supports limiting the detection scope through keyword search or tag filtering.

In addition to simple queries, expression-based queries are also supported.

Additional Information¶

Additional fields are used only for supplementary queries and are not used for trigger condition evaluation. You can configure them into event notifications. If multiple matching values are detected, one record is returned at random.

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 four threshold levels — Critical, Error, Warning, Info — and the OK recovery condition.

For more details, refer to Event Level Descriptions.

Advanced Options¶

Consecutive Trigger Evaluation¶

When enabled, an event is generated only when the trigger condition is continuously satisfied, preventing false alarms caused by transient fluctuations. (❗️The maximum configurable 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 event status.

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

When this switch is enabled, the event details generated after the monitor detects anomalies will not display historical records or associated events.

Data Gap¶

Handling strategy when the detection metric returns no query results within the detection range:

When trigger conditions, data gap, and info generation are configured together, the trigger evaluation priority is as follows: Data gap > Trigger conditions > Info event generation.

That is: first determine whether there is a data gap, then determine whether thresholds are triggered, and finally determine whether an info event is generated.

Info Generation¶

When this option is enabled, you must configure the info generation condition. The system writes an "Info" event only when the detection result does not trigger any of the "Critical", "Error", "Warning", or "Info" thresholds and the info generation condition is satisfied.

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

Next Steps¶

After completing the above detection configuration, continue with:

1. Event Notification: Define the event title, content, notified members, data gap handling, and associated incidents;

2. Alert Configuration: Select an alert policy, set notification targets and the mute period;

3. Associate: Associate dashboards for quick navigation to view data;

4. Permissions: Set operation permissions to control who can edit or delete this monitor.