Network Data Detection¶

Document Purpose

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

Used to monitor network performance metrics in the workspace. It allows users to set threshold ranges and trigger alerts when metrics exceed these thresholds. Supports configuring alert rules for a single metric and allows customizing alert severity levels.

Data scope: Supports metric data from the netflow and httpflow data sources.

Suitable for monitoring key performance metrics at the network layer. For example:

Monitor network-layer metrics such as TCP connection count, retransmission count, and latency for hosts with the netflow data source
Monitor application-layer metrics such as request count, error count, error rate, and response time for the httpflow data source

Detection Configuration¶

Detection Frequency¶

Set the execution period for detection.

Preset options: 1 minute, 5 minutes (default), 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 configuring scheduled task execution based on periods such as seconds, minutes, hours, days, months, and weeks.

Detection Interval¶

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

Detection Frequency	Detection Interval (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 interval, e.g., 20m (last 20 minutes), 2h (last 2 hours), 1d (last 1 day).

Detection Metrics¶

Set the metrics for detection. You can set metric data from all services or a single service in the workspace within a specified time range (❗️Avoid selecting high-cardinality fields as detection dimensions. Improper configuration may make trigger conditions too loose and cause frequent alerts. The current query returns a maximum of 100,000 records).

Configuration Elements¶

Configuration Item	Description
Data Source	Available options: • `netflow`: network traffic data (TCP-layer metrics) • `httpflow`: HTTP traffic data (application-layer metrics)
Metrics	Corresponding metrics are displayed based on the selected data source: netflow metrics: • Bytes sent • Bytes received • TCP latency • TCP jitter • TCP connection count • TCP retransmission count • TCP close count httpflow metrics: • Request count • Error count • Error rate • Average response time • P99 response time • P95 response time • P75 response time • P50 response time
Filter Conditions	Filters detection data based on metric tags to limit the data scope of detection. Supports adding one or more tag filters, and supports fuzzy match and fuzzy mismatch 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. Combinations of multiple detection dimension fields identify a specific detection object. The system determines whether the statistical metric corresponding to a detection object meets the trigger threshold; if so, an event is generated. (For example, selecting `host` and `host_ip` as detection dimensions means the detection object can be `{host: host1, host_ip: 127.0.0.1}`.)

Trigger Conditions¶

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

Supports configuring four severity thresholds — Fatal, Critical, Important, Warning — and a Normal recovery condition.

Severity	Configuration	Description
Fatal	When Result >= `[Value]`	Highest severity alert, requires immediate handling
Critical	When Result >= `[Value]`	High severity alert, requires priority handling
Important	When Result >= `[Value]`	Medium severity alert, requires attention
Warning	When Result >= `[Value]`	Low severity alert, take note
Normal	No event generated for `[N]` consecutive detections	After the detection rule takes effect, if the data detection result recovers from abnormal (Fatal, Critical, Important, Warning) to normal within the configured custom detection count, a recovery alert event is triggered. ❗️ Recovery alert events are not subject to alert muting. If no detection count is configured for the recovery alert event, the alert event will not recover and will remain in the Events > Unrecovered Events List

For more details, see Event Level Description.

Advanced Options¶

Continuous Trigger Evaluation¶

When enabled, an event is generated only when the trigger conditions are continuously met, 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 targets one by one, it generates and pushes a small number of summary alerts based on event status.

This ensures timely notifications while significantly reducing alert noise and avoiding timeout risks caused by processing too many alerts.

When this toggle is enabled, event details of this type generated after the monitor subsequently detects anomalies will not display historical records or related events.

Data Gap¶

Handling strategy when the query result for the detection metric is empty within the detection interval:

Option	Description
Do not trigger events (default)	Linked to the time range of the detection interval, determines whether to generate an event based on the query results of the detection metric in the most recent few minutes. Suitable for scenarios where missing data is acceptable.
Treat query result as 0	Linked to the time range of the detection interval, treats the query result of the detection metric in the most recent few minutes as 0, and compares it again with the thresholds configured in Trigger Conditions above to determine whether to trigger an anomaly event.
Custom fill and trigger events	Supports custom filling of the detection interval value and triggers the following event types respectively: Data Gap Event, Fatal Event, Critical Event, Important Event, Warning Event, and Recovery Event. ❗️When selecting this strategy, it is recommended that the custom data gap duration be configured as ≥ the detection interval. If the configured duration is ≤ the detection interval, both data gap and anomaly conditions may be met simultaneously, in which case the data gap handling result takes precedence.

When trigger conditions, data gap, and info generation are all configured, the trigger precedence is as follows: Data Gap > Trigger Conditions > Info Event Generation.

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

Info Generation¶

After enabling this option, configure Info Generation Conditions. Only when the detection result does not trigger any of the “Fatal,” “Critical,” “Important,” or “Warning” thresholds and the info generation conditions are met will the system write an “Info” event.

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

Subsequent Configuration¶

After completing the detection configuration above, continue to configure:

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