Synthetic Testing Anomaly Detection¶

Used to monitor synthetic test (dialing test) data within the workspace. You can set threshold ranges for the specified data volume generated by dialing test tasks within a certain time period. Once the data volume reaches these thresholds, the system will trigger an alert. Supports monitoring based on performance metrics and quantity statistics for protocol types such as HTTP, TCP, ICMP, WEBSOCKET, and multistep tests.

Suitable for monitoring scenarios such as URL availability deployed in production environments, service port connectivity, and network latency. For example, monitor whether the average response time or availability rate of key business interfaces meets the standards.

Detection Configuration¶

Detection Frequency¶

Set the time period for executing the 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, supporting scheduled task execution based on seconds, minutes, hours, days, months, weeks, etc.

Detection Interval¶

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

• Custom format: Custom input detection interval, e.g., 20m (last 20 minutes), 2h (last 2 hours), 1d (last 1 day).

Detection Metrics¶

Set the metrics for detection data. Supports setting the specified data generated by all or a single dialing test task 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 returned records for a single query is 100,000).

Supports two query modes:

• Dialing test metrics (based on specific performance metrics)

• Quantity statistics (based on data source query)

Dialing Test Metrics¶

Detect based on specific performance metrics of synthetic tests.

Quantity Statistics¶

Perform statistical detection based on synthetic test data sources.

You can query and count dialing test tasks based on different dialing test types by selecting the corresponding data source (http_dial_testing, tcp_dial_testing, icmp_dial_testing, websocket_dial_testing, multi_dial_testing, etc.).

Supports limiting the detection range through keyword search or label filtering.

In addition to simple queries, expression query methods are also supported.

Additional Information¶

Additional fields are only used for extra queries and will not be used for trigger condition judgment. You can configure them in event notifications. If multiple matching values are detected, one record will be returned randomly.

Trigger Conditions¶

Configure trigger conditions and severity levels. When the query result has multiple values, if any value meets the trigger condition, an event will be generated.

Supports configuring four levels of thresholds: Critical, Error, Warning, Info, and OK recovery conditions.

For more details, refer to Event Level Description.

Advanced Options¶

Consecutive Trigger Judgment¶

When enabled, an event is generated only when the trigger condition is continuously met, avoiding false positives from 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 summary-by-state strategy: Instead of processing alert objects one by one, it generates a small number of summary alerts based on the event state and pushes them.

This ensures timely notification while significantly reducing alert noise, avoiding the risk of timeout due to processing too many alerts.

When this switch is enabled, subsequent events detected by the monitor will not display historical records and related events in the event details.

Data Interruption¶

The handling strategy when the query result of the detection metric is empty within the detection interval:

When trigger conditions, data interruption, and information generation are configured simultaneously, the priority for triggering is: Data Interruption > Trigger Conditions > Information Event Generation.

That is: first determine whether there is a data interruption, then determine whether the threshold is triggered, and finally determine whether to generate an information event.

Information Generation¶

When this option is enabled, you need to configure the Information Generation Condition. The system will only write an "Information" event when the detection result does not trigger any of the thresholds "Critical", "Error", "Warning", or "Info", and the information generation condition is met.

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

Subsequent Configuration¶

After completing the above detection configuration, please continue to configure:

1. Event Notifications: Define the event title, content, notification members, data interruption handling, and related incidents;

2. Alert Configuration: Select an alert strategy, set notification targets and mute periods;

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

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