SLS

Monitors retrieves data through SLS SQL query interface (GetLogsV3) and triggers alerts based on query results.

​

Core Concepts

​

1. Threshold Evaluation Mode

This mode is suitable for scenarios requiring threshold comparison on aggregated values.

​

Configuration

1. Query Statement: Write SLS SQL aggregate query.

• Example: Count error log quantity by host in the last 15 minutes.
  * | SELECT host, count(*) as error_cnt WHERE level = 'ERROR' GROUP BY host
  

2. Query Parameters:

• sls.project: (Required) Project name.
• sls.logstore: (Required) Logstore name.
• sls.timespan.value: (Optional) Time span value, default is 15.
• sls.timespan.unit: (Optional) Time span unit, supports s (seconds), m (minutes), h (hours), d (days). Default is m.

3. Field Mapping:

• Value fields: Select error_cnt for threshold evaluation.
• Label fields: Select host to identify the alert object. After you select label fields, other non-value fields are carried with the alert as additional information.
• See Query Result Field Mapping for the complete behavior.

4. Threshold Conditions:

• Use $A.field_name to reference values.
• Example: Critical: $A.error_cnt > 50, Warning: $A.error_cnt > 10.

​

How It Works

Monitors runs the SLS query for the configured time range, distinguishes alert objects by their label fields, and evaluates thresholds with their value fields. If Label fields is empty, every returned field except the value fields becomes a label.

​

Recovery Logic

​

2. Data Exists Mode

This mode is suitable for scenarios where filter logic is written directly in SQL.

​

Configuration

1. Query Statement: Use HAVING clause to filter anomalous data.

• Example: Query hosts with error count exceeding 50.
  * | SELECT host, count(*) as error_cnt WHERE level = 'ERROR' GROUP BY host HAVING error_cnt > 50
  

2. Query Parameters: Same as above, need to configure sls.project and sls.logstore.
3. Evaluation Rules: As long as query returns data, triggers alert.

​

Pros and Cons Analysis

​

Recovery Logic

• Recovery When Data Disappears: When query result is empty, determines recovery
• Recovery Query: Supports configuring additional query statements
• Manual Close: Keep the alert active until it is closed manually

​

3. No Data Mode

This mode is used to monitor scenarios where “data is expected but actually missing”.

​

Configuration

1. Query Statement: Write a query that is expected to continuously return data.

• Example: Query log reporting heartbeat from all hosts.
  * | SELECT host, max(__time__) as last_seen GROUP BY host
  

2. Evaluation Rules: If a host appeared in previous cycles but cannot be found in current and N consecutive cycles, triggers “No Data” alert.

​

Recovery Logic

No-data alerts support configuring the alert ending mode, which decides how the alert ends:

​

4. Advanced Configuration