tencent cloud

Cloud Log Service

DokumentasiCloud Log ServiceOperation GuideMonitoring AlarmManaging Alarm PoliciesTrigger Condition Expression

Trigger Condition Expression

Download
Mode fokus
Ukuran font
Terakhir diperbarui: 2026-05-15 21:59:57
The trigger condition expression is used to determine if an alarm should be triggered. It takes the statement execution results as input variables, and when the expression evaluates to true, the alarm is triggered.

Syntax Description

Operator
Description
Example
$N.__QUERYCOUNT__
Number of execution statement results, where N is the ID of the corresponding execution statement.
For different use cases, the specific meanings are as follows:
Log Topic
When the execution statement does not contain SQL: number of raw logs that match the search criteria
When the execution statement contains SQL: Number of SQL results (Note: When limit is not specified in SQL, a maximum of 100 results is returned by default).
Metric Topic: number of PromQL query results
$1.__QUERYCOUNT__
$N.keyname
References the result of the execution statement, where N is the ID of the corresponding execution statement and keyname is the field name in the execution statement result.
Note:
The first character of keyname must be a letter. It can contain letters, digits, and underscores. If it contains special characters:
The AS syntax is supported in Log Topic execution statements to alias field names.
Enclose the entire reference in square brackets, for example [$1.@value].
When the monitoring target is a Metric Topic, in addition to metric dimensions (labels), the system predefines the following built-in variables:
$N.__name__: metric name
$N.value: metric value
$N.time: time corresponding to the metric, as a second-level UNIX timestamp
If the field name of a metric dimension (label) conflicts with the above variables, an @ symbol will be automatically added before the original field name, for example [$1.@value]
$1.ErrCount
$1.value
+
Summation operator.
$1.ErrCount+$1.FatCount>10
-
Subtraction operator.
$1.Count-$1.InfoCount>100
*
Multiplication operator.
$1.RequestMilSec*1000>10
/
Division operator.
$1.RequestSec/1000>0.01
%
Modulo operator.
$1.keyA%10==0
==
Comparison operator: equal to.
$1.ErrCount==100
$1.level=="Error"
>
Comparison operator: greater than.
$1.ErrCount>100
<
Comparison operator: less than.
$1.pv<100
>=
Comparison operator: greater than or equal to.
$1.ErrCount>=100
<=
Comparison operator: less than or equal to.
$1.pv<=100
!=
Comparison operator: not equal to.
$1.level!="Info"
()
Parentheses for controlling the operation priority.
($1.a+$1.b)/$1.c>100
&&
Logical operator: AND.
$1.ErrCount>100 && $1.level=="Error"
||
Logical operator: OR.
$1.ErrCount>100 || $1.level=="Error"
A comparison operator must be used to compare variables, and an alarm is triggered only when the result is a Boolean value of true. For example, when the value of $1.a is 80 and the value of $1.b is 20:
Expression $1.a+$1.b: The result is 100, which is not a Boolean value, so no alarm is triggered.
Expression $1.a+$1.b>=100: The result is true, and an alarm is triggered.
An alarm policy can contain multiple execution statements (up to 3), each with a sequentially assigned number starting from 1. For example, $1.key1 refers to the key1 field from the execution statement numbered 1, and $2.key2 refers to the key2 field from the execution statement numbered 2.
When the monitoring target is a metric topic, configure the alarm condition directly in the execution statement. For the trigger condition, use $N.__QUERYCOUNT__ > 0 directly (replace N with the execution statement number). For details, see Example 3.
When an execution statement returns multiple results, the system will perform up to 1,000 sequential calculations to determine if the trigger conditions are met. The calculation process halts immediately when any result evaluates to true. For example, given the expression $1.a+$2.b>100, if execution statement 1 returns m results and execution statement 2 returns n results, the system will perform up to m x n calculations. The process stops when the condition $1.a+$2.b>100 is satisfied, or when the total calculations exceed 1,000. If no condition is met after 1,000 calculations, the result is evaluated as false, and no alarm is triggered.

Example

Example 1: Triggering an Alarm When Error-Level Logs Appear in the Last 5 Minutes

Monitoring Target: Log Topic
Execution statement:
level:error
Query time range: Select the last 5 minutes.
Trigger condition: The number of results of execution statement 1 is greater than 0.
$1.__QUERYCOUNT__>0

Example 2: Triggering an Alarm When the Average Request Latency for a Specific VIP User (uid:10001) Exceeds 10 Seconds

Monitoring Target: Log Topic
Execution statement:
uid:10001 | select avg(request_time) as latency
Query time range: Select the last 5 minutes.
Trigger condition: The latency of execution statement 1 is greater than 10.
$1.latency>10

Example 3: Triggering an Alarm When File System Space Usage Exceeds 50%

Monitoring Target: Metric Topic
Execution statement:
filesystem_usage_pct > 0.5
Trigger condition: The number of results of execution statement 1 is greater than 0.
$1.__QUERYCOUNT__>0
__QUERYCOUNT__ is a system preset variable that indicates the number of results from an execution statement. Since the execution statement has already filtered the metrics using > 0.5, an alarm must be triggered whenever the number of results from the execution statement is greater than 0.

Topik sebelumnya: Configuring Alarm PoliciesTopik selanjutnya: Alarm Policy Templates

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan