Log Detection¶
Current Document Positioning
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 the workspace. It supports setting alert rules based on log keywords to quickly identify abnormal patterns that deviate from expected behavior (such as error tags in log text, high error rates, etc.), and promptly detect and respond to potential security threats or system issues.
This feature is suitable for detecting code exceptions or task scheduling issues in IT monitoring scenarios, such as monitoring excessively high log error rates.
Detection Configuration¶
Detection Frequency¶
Set the time interval for executing 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 custom cycles, supporting scheduled task execution based on seconds, minutes, hours, days, months, weeks, etc.
Detection Interval¶
Set the time range for data queries in each detection (❗️The detection interval must be greater than or equal to the detection frequency, and should match the actual data reporting cycle to avoid missed detections or false alarms).
- 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: Custom input for 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. Monitor the number of logs containing the specified keywords in the log list of the designated detection object within a certain time range (❗️Avoid selecting high-cardinality fields as detection dimensions. Improper configuration with overly lenient trigger conditions may cause frequent alerts. The current maximum number of query results returned is 100,000 records).
Configuration Elements¶
| Configuration Item | Description |
|---|---|
| Index | The index to which the current detection metric belongs; multiple selections allowed. ❗️After setting indexes in Logs > Indexes, when selecting "Logs" as the data source in chart queries, you can choose different indexes corresponding to log content. The default index is default. |
| Source | The data source of the current detection metric, supporting selection of all (*) or a specific single data source. |
| Keyword Search | Supports keyword search to match specific content in log text. |
| Filter Conditions | Filter the data of the detection metric based on metric tags, limiting the scope of detection data; supports adding one or more tag filters; supports fuzzy match and fuzzy not match filter conditions. |
| Aggregation Algorithm | Default selection is "*", with the corresponding function being count (counting the number of logs). If another field is selected, the function automatically becomes count distinct (counting distinct data points). |
| Detection Dimensions | Fields of string type (keyword) in the data can be selected as detection dimensions. Currently, up to three fields can be selected as detection dimensions. By combining multiple detection dimension fields, a specific detection object can be identified. The system determines whether the statistical metric of a detection object meets the trigger condition threshold. If it does, an event is generated.(For example, selecting detection dimensions host and host_ip results in a detection object like {host: host1, host_ip: 127.0.0.1}.)❗️When the detection object is "Logs", the default detection dimensions are status, host, service, source, and filename. |
| Query Method | Supports simple queries and expression queries. ❗️If the query method is expression query and contains multiple queries, the log detection object is the same. For example, if the detection object of expression query A is "Logs", then the detection object of expression query B is also "Logs". |
Click to view Query Method Details.
Trigger Conditions¶
Configure trigger conditions and severity levels. When the query result has multiple values, an event is generated if any value meets the trigger condition.
Supports configuring four levels of thresholds: Critical, High, Medium, Low, and a Normal recovery condition.
| Level | Configuration | Description |
|---|---|---|
| Critical | When Result >= [Value] |
Highest priority alert, requiring immediate action. |
| High | When Result >= [Value] |
High priority alert, requiring priority handling. |
| Medium | When Result >= [Value] |
Medium priority alert, requiring attention. |
| Low | When Result >= [Value] |
Low priority alert, requiring awareness. |
| Normal | [N] consecutive detections with no events generated |
After the detection rule takes effect, if the data detection result returns to normal from abnormal (Critical, High, Medium, Low) within the configured custom number of detections, a recovery alert event is triggered. ❗️ Recovery alert events are not subject to alert muting. If the number of recovery alert event detections is not set, the alert event will not recover and will remain in the Events > Unrecovered Events List. |
For more details, refer to Event Level Description.
Continuous Trigger Judgment¶
After enabling, an event is generated only when the trigger condition is continuously met, avoiding false alarms from transient fluctuations (❗️Maximum configuration limit is 10 times).
Mass 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-status strategy: Instead of processing each alert object individually, a small number of summary alerts are generated based on event status and pushed.
This ensures timely notifications while significantly reducing alert noise, avoiding the risk of timeouts caused by processing too many alerts.
When this switch is enabled, the event details generated by subsequent monitor detections of anomalies will not display history records and related events.
Data Gap¶
The processing strategy when the query result of the detection metric is empty within the detection interval:
| Option | Description |
|---|---|
| Do not trigger event (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 within the last few minutes. Suitable for scenarios where data gaps are allowed. |
| Treat query result as 0 | Linked to the time range of the detection interval, treats the query result of the detection metric within the last few minutes as 0, and re-compares it with the threshold 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 triggering the following event types separately: Data Gap Event, Critical Event, High Event, Medium Event, Low Event, and Recovery Event. ❗️When selecting this strategy, it is recommended that the custom data gap time configuration be ≥ the detection interval time interval; if the configured time is ≤ the detection interval time interval, both data gap and anomaly conditions may be met simultaneously, and the data gap processing result will be applied first. |
When configuring Trigger Conditions, Data Gap, and Information Generation simultaneously, the trigger priority is: 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¶
After enabling this option, you need to configure the Information Generation Condition. When the detection result does not trigger any of the "Critical", "High", "Medium", or "Low" thresholds, and the information generation condition is met, the system will write an "Information" event.
This is suitable for scenarios where normal state changes or low-priority information need to be recorded.
Subsequent Configuration¶
After completing the above detection configuration, continue with the following:
-
Event Notification: Define the event title, content, notification members, data gap handling, and related faults.
-
Alert Configuration: Select an alert strategy, set notification targets and mute periods.
-
Association: Associate dashboards for quick navigation to view data.
-
Permissions: Set operation permissions to control who can edit or delete this monitor.