Log Detection¶
Current Document Location
This document is the second step in the detection rule configuration process. After completing the configuration, please return to the main document to continue with the third step: Event Notification.
The Log Detection feature is used to monitor all log data generated by log collectors within a workspace. It supports setting alert rules based on log keywords to quickly identify abnormal patterns that deviate from expected behavior (such as abnormal tags appearing in log text, excessively high error rates, etc.), enabling timely detection and response to potential security threats or system issues.
It is suitable for scenarios such as code exception monitoring or task scheduling detection in IT monitoring. For example, monitoring for excessively high log error rates.
Detection Configuration¶
Detection Frequency¶
Set the time period for executing the 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, supporting scheduled task execution based on seconds, minutes, hours, days, months, weeks, etc.
Detection Interval¶
Set the data time range queried for each detection (❗️ The detection interval should be greater than or equal to the detection frequency, and should match the actual data reporting cycle to avoid missed detections or false positives).
- Preset options:
| Detection Frequency | Detection Interval (Dropdown Options) |
|---|---|
| 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: Manually input the detection interval, e.g., 20m (last 20 minutes), 2h (last 2 hours), 1d (last 1 day).
Detection Metrics¶
Define the detection data source and aggregation method based on DQL, monitoring the number of logs containing the specified keywords within a certain time range on the log list of the specified detection object (❗️ Avoid selecting high-cardinality fields as detection dimensions. If configured improperly, overly lenient trigger conditions may cause frequent alerts. The current query returns a maximum of 100,000 records).
Configuration Elements¶
| Configuration Item | Description |
|---|---|
| Index | The index to which the current detection metric belongs; multiple selections are allowed. ❗️ After setting up indexes in LOG > Index, when selecting "LOG" as the data source for chart queries, you can choose log content corresponding to different indexes. The default is the default index. |
| Source | The data source for the current detection metric, supporting selection of all (*) or a specified single data source. |
| Keyword Search | Supports keyword search to match specific content within the log text. |
| Filter Conditions | Filters the data of the detection metric based on the metric's tags to limit the data scope of the detection; supports adding one or multiple tag filters; supports fuzzy match and fuzzy not-match filter conditions. |
| Aggregation Algorithm | By default, "*" is selected, corresponding to the count function (counting the number of logs). If another field is selected, the function automatically changes to count distinct (counting non-repeating data points). |
| Detection Dimension | Any string-type (keyword) field in the configuration data can be selected as a detection dimension. Currently, a maximum of three fields can be selected as detection dimensions. The combination of multiple detection dimension fields determines a specific detection object. The system will determine whether the statistical metric corresponding to a detection object meets the threshold of the trigger condition. If the condition is met, an event is generated.(For example, selecting detection dimensions host and host_ip, the detection object could be {host: host1, host_ip: 127.0.0.1}.)❗️ When the detection object is "LOG", the default detection dimensions are status, host, service, source, filename. |
| Query Method | Supports simple query and expression query. ❗️ If the query method is expression query and contains multiple queries, the log detection object is the same. For example, if the detection object for expression query A is "LOG", then the detection object for expression query B is also "LOG". |
Click to view Query Method Details.
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-level thresholds: Fatal, Severe, Important, Warning, as well as a Normal recovery condition.
| Level | Configuration | Description |
|---|---|---|
| Fatal | When Result >= [value] |
Highest level alert, requires immediate handling. |
| Severe | When Result >= [value] |
High-level alert, requires priority handling. |
| Important | When Result >= [value] |
Medium-level alert, requires attention. |
| Warning | When Result >= [value] |
Low-level alert, requires noting. |
| Normal | No events generated for [N] consecutive detections |
After the detection rule takes effect, if the data detection result changes from abnormal (Fatal, Severe, Important, Warning) back to normal within the configured custom number of detections, a recovery alert event is triggered. ❗️ Recovery alert events are not restricted by Alert Mute. If the number of detections for recovery alert events is not set, the alert event will not recover and will remain in the Incident > Unrecovered Events List. |
For more details, refer to Event Level Description.
Consecutive Trigger Judgment¶
When enabled, events are generated only when the trigger condition is continuously met, avoiding false positives due to instantaneous fluctuations (❗️ The maximum configuration limit is 10 times).
Bulk Alert Protection¶
Enabled by default in the system.
When the number of alerts generated by a single detection exceeds a preset threshold, the system automatically switches to a summary-by-status strategy: Instead of processing each alert object individually, it generates a small number of summary alerts based on the event status and pushes them.
This ensures the timeliness of notifications while significantly reducing alert noise and avoiding timeout risks caused by processing too many alerts.
When this switch is enabled, subsequent event details generated by the monitor after detecting anomalies will not display historical records and related events.
Data Gap¶
The handling strategy when the query result for the detection metric is empty within the detection interval:
| Option | Description |
|---|---|
| Do Not Trigger Event (Default) | Links to the time range of the detection interval. Determines whether to generate an event based on the query results of the detection metric within the last several minutes. Suitable for scenarios where data gaps are allowed. |
| Treat Query Result as 0 | Links to the time range of the detection interval. Treats the query results of the detection metric within the last several minutes as 0, and re-compares them with the thresholds configured in the Trigger Conditions above to determine whether to trigger an abnormal event. |
| Custom Fill and Trigger Event | Supports custom filling of the detection interval value and triggers the following event types respectively: Data Gap Event, Fatal Event, Severe Event, Important Event, Warning Event, and Recovery Event. ❗️ When selecting this strategy, it is recommended that the configured custom data gap time be ≥ the time interval of the detection interval; if the configured time is ≤ the detection interval time, situations where both data gap and anomaly conditions are met may occur. In such cases, the data gap handling result will be applied first. |
When trigger conditions, data gap, and information generation are configured simultaneously, the triggering priority is judged as follows: Data Gap > Trigger Conditions > Information Event Generation.
That is: first determine if there is a data gap, then determine if the threshold is triggered, and finally determine if an information event should be generated.
Information Generation¶
When this option is enabled, the system writes all detection results that do not match the above trigger conditions as "Information" events.
Suitable for scenarios where recording normal state changes or low-priority information is needed.
Subsequent Configuration¶
After completing the above detection configuration, please continue to configure:
-
Event Notification: Define event title, content, notification members, data gap handling, and associated faults.
-
Alert Configuration: Select alert strategies, set notification targets, and mute periods.
-
Association: Associate dashboards for quick navigation to view data.
-
Permissions: Set operation permissions to control who can edit/delete this monitor.