Network Data Monitoring¶

Current Document Positioning

This document is the second step in the monitoring rules configuration process. After configuration, please return to the main document to continue with the third step: Event Notifications.

Used to monitor network performance metrics within a workspace. It allows users to set threshold ranges and trigger alerts when metrics exceed these thresholds. Supports configuring alert rules for individual metrics and allows customizing the severity level of alerts.

Data Range: Supports metric data from data sources netflow and httpflow.

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

Monitor host data source netflow for network layer metrics such as TCP connection count, retransmission count, latency, etc.
Monitor data source httpflow for application layer metrics such as request count, error count, error rate, response time, etc.

Monitoring Configuration¶

Detection Frequency¶

Sets the time interval for executing the detection.

Preset options: 1 min, 5 min (default), 15 min, 30 min, 1 hour, 6 hours, 12 hours, 24 hours.
Crontab mode: Click "Switch to Crontab mode" to configure a custom schedule, supporting periodic task execution based on seconds, minutes, hours, days, months, weeks, etc.

Detection Interval¶

Sets the data time range for each detection query (❗️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).

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: Custom input the detection interval, e.g., 20m (last 20 minutes), 2h (last 2 hours), 1d (last 1 day).

Detection Metrics¶

Sets the metrics for detection data. Supports setting metrics data for all or individual services within the workspace over a specified time period (❗️Avoid selecting high-cardinality fields as detection dimensions. Improper configuration with overly loose trigger conditions may result in frequent alerts. The current query returns a maximum of 100,000 records).

Configuration Elements¶

Configuration Item	Description
Data Source	Supported selections: • `netflow`: Network traffic data (TCP layer metrics) • `httpflow`: HTTP traffic data (application layer metrics)
Metrics	Displays corresponding metrics 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 the detection metric data based on metric tags to limit the data range; supports adding one or more tag filters; supports fuzzy match and fuzzy not match filter conditions
Detection Dimensions	Any string type (`keyword`) field in the data can be selected as a detection dimension. Currently, a maximum of three dimensions can be selected. By combining multiple detection dimension fields, a specific detection object can be determined. The system determines whether the statistical metric for that detection object meets the trigger condition threshold. If it meets the condition, an event is generated. (For example, if detection dimensions `host` and `host_ip` are selected, 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 meets the trigger condition.

Supports configuring four levels of thresholds: Critical, Major, Important, Warning, and a Normal recovery condition.

Level	Configuration	Description
Critical	When Result >= `[value]`	Highest severity alert, requires immediate action
Major	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, requires awareness
Normal	`[N]` consecutive detections with no event generated	After the monitoring rule takes effect, if the data detection result changes from abnormal (Critical, Major, Important, Warning) to normal within the configured custom number of detections, a recovery alert event is triggered. ❗️ Recovery alert events are not limited by alert muting. If the recovery alert event detection count is not set, the alert event will not recover and will always appear in Events > Unrecovered Events List

For more details, refer to Event Level Description.

Advanced Options¶

Consecutive Trigger Judgment¶

When enabled, events are only generated when the trigger condition is continuously met, avoiding false positives from transient fluctuations (❗️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 each alert object individually, a small number of summary alerts based on the event status are generated and pushed.

This ensures timely notifications while significantly reducing alert noise, avoiding timeout risks due to excessive alert processing.

When this switch is enabled, the event details generated by subsequent monitor detections of anomalies will not display historical records or related events.

Data Gap¶

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

Option	Description
No event triggered (default)	Linked to the detection interval time range, determines whether to generate an event based on the query results of the detection metric within the last few minutes. Suitable for scenarios where data can be missing.
Treat query result as 0	Linked to the detection interval time range, treats the query result of the detection metric within the last few minutes as 0, and re-compares it with the thresholds configured in the Trigger Conditions above to determine whether to trigger an anomaly event.
Custom fill and trigger event	Supports custom filling of the detection interval value and separately triggering the following event types: Data Gap Event, Critical Event, Major Event, Important Event, Warning Event, and Recovery Event. ❗️When selecting this strategy, it is recommended to configure the custom data gap time ≥ the detection interval time. If the configured time is ≤ the detection interval time, both data gap and anomaly conditions may be satisfied simultaneously, in which case the data gap handling result will take precedence.

When Trigger Conditions, Data Gap, and Information Generation are configured simultaneously, the priority for judgment is: Data Gap > Trigger Conditions > Information Generation.

That is: first determine if there is a data gap, then determine if the threshold is triggered, and finally determine if an info event should be generated.

Information Generation¶

When this option is enabled, the Information Generation Condition must be configured. The system will only write an "Info" event if the detection result does not trigger any of the thresholds (Critical, Major, Important, Warning) and meets the information generation condition.

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

Subsequent Configuration¶

After completing the above monitoring configuration, continue to configure:

Event Notifications: Define event title, content, notification members, data gap handling, and related faults;
Alert Configuration: Select alert strategies, set notification targets and mute periods;
Association: Associate dashboards for quick access to view data;
Permissions: Set operation permissions to control who can edit or delete this monitor.