Process Anomaly Detection¶

Document Scope

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

Used to monitor process data in the workspace, it supports configuring alert trigger conditions for one or more field types in the process data. By monitoring process count statistics, process anomalies (such as process disappearance or abnormal increases in process count) can be detected in a timely manner, ensuring the stability of system services.

Data scope: Supports the Process data type.

Suitable for scenarios where you need to monitor the running status of specific processes. For example:

Monitor whether critical business processes (such as nginx, mysql, java) are running normally
Monitor whether the number of processes in a specific pattern is abnormal (for example, too many zombie processes)
Monitor whether scheduled task processes start normally

Detection Configuration¶

Detection Frequency¶

Set the time period at which detection is performed.

Preset options: 1 minute, 5 minutes (default), 10 minutes, 15 minutes, 30 minutes, 1 hour
Crontab mode: Click "Switch to Crontab Mode" to configure a custom period. Supports configuring scheduled task execution based on seconds, minutes, hours, days, months, weeks, and other periods.

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 period to avoid missed detections or false alarms).

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, such as 20m (last 20 minutes), 2h (last 2 hours), or 1d (last 1 day).

Detection Targets¶

Set the process data to be detected (❗️Avoid selecting high-cardinality fields as detection dimensions. If improperly configured, overly loose trigger conditions may cause frequent alerts. The current query returns a maximum of 100,000 records).

Supports setting the number of occurrences of one or more field-type keywords in process data within the current workspace during a specified time range.

Configuration Elements¶

Configuration Item	Description
Detection Type	Fixed to Process Count Statistics, used to count the number of processes matching the conditions
Process	Enter the process name manually. Wildcards are supported for fuzzy matching (for example, `k8s`, `C:\\Windows\\`). Special characters do not need to be escaped. Separate multiple values with commas (`,`)
Filter Conditions	Supports filtering process data fields to limit the data range of the detection; 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 configured data can be selected as a detection dimension. Currently, a maximum of three fields can be selected as detection dimensions. By combining fields from multiple detection dimensions, a specific detection object can be identified. The system determines whether the statistical metric corresponding to a detection object meets the threshold in the trigger conditions; if the condition is met, an event is generated. (For example, if you select `host` and `host_ip` as detection dimensions, the detection object can be `{host: host1, host_ip: 127.0.0.1}`.)

Trigger Conditions¶

Configure the 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 the four-level thresholds of Critical, Error, Warning, and Info, as well as the Normal recovery condition.

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

For more details, see Event Severity Levels.

Advanced Options¶

Consecutive Trigger¶

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

High-volume 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 summarization strategy: instead of processing alert objects one by one, it generates a small number of summary alerts based on event status and pushes them.

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

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

Data Gap¶

Handling policy when the query result of the detection metric is empty within the detection range:

Option	Description
Do not trigger events (default)	Use the detection range time window and determine whether to generate events based on the query results of the detection metric in the most recent minutes. Suitable for scenarios where missing data is acceptable
Treat query result as 0	Use the detection range time window, treat the query result of the detection metric in the most recent minutes as 0, and re-compare it with the thresholds configured in the Trigger Conditions above to determine whether to trigger an anomaly event
Custom fill and trigger events	Supports custom values to fill the detection range, and separately triggers the following event types: Data Gap Event, Critical Event, Error Event, Warning Event, Info Event, and Recovery Event. ❗️When this policy is selected, it is recommended to configure the custom data gap time as ≥ the detection range interval. If the configured time is ≤ the detection range interval, a data gap and an anomaly may be satisfied at the same time. In this case, the data gap handling result takes priority

When trigger conditions, data gap, and info event generation are configured together, the trigger is evaluated in the following priority order: Data Gap > Trigger Conditions > Info Event Generation.

That is, the system first determines whether a data gap exists, then whether the threshold is triggered, and finally whether an info event should be generated.

Info Event Generation¶

After enabling this option, configure the info event generation condition. Only when the detection result does not trigger any of the Critical, Error, Warning, or Info thresholds and the info event generation condition is met will the system write an Info event.

Suitable for scenarios that require recording normal state changes or low-priority information.

Subsequent Configuration¶

After completing the detection configuration above, continue with the following configuration:

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