[comment]: # ({9b69cf77-8c8b2e0b})
# 4 触发器的最佳实践

[comment]: # ({/9b69cf77-8c8b2e0b})

[comment]: # ({93fa4fb9-814b1677})
触发器是一个强大的工具，但它们也可能产生不必要的告警噪音。为了看到更多真实信号、减少噪音，请遵循以下建议：

1. 降低触发器敏感度。与其根据最新值（过高/过低）发出告警，不如使用 **`avg`**、**`min`** 和 **`max`** 等函数，分析较长时间段内的平均值。

2. 如果你希望避免因随机尖峰和骤降而触发告警，可以考虑在触发器中使用 **`percentile`** 函数（将其设置为 95% 或 5%）。

3. 使用 [滞后](#hysteresis) 来避免触发器抖动——即触发器状态频繁变化（OK ↔ Problem）。可以通过添加恢复表达式（用于问题恢复的单独条件）来为问题状态定义一个连续区间。

4. 使用触发器[依赖关系](/manual/config/triggers/best_practices/dependencies)，以避免与根本原因无关的告警。

5. 使用触发器[严重性](/manual/config/triggers/best_practices/severity)，仅对更严重的问题发出告警。

6. 定义[维护](/manual/maintenance)时间窗口。

[comment]: # ({/93fa4fb9-814b1677})

[comment]: # ({bae4792f-3f1b1c81})
#### 滞后

有时，问题状态与恢复状态之间需要一个区间，而不是一个简单的阈值。
例如，如果我们想定义一个触发器：当服务器机房温度高于 20°C 时报告问题，并且希望它保持在问题状态，直到温度降到 15°C 以下，那么仅设置一个 20°C 的简单触发器阈值是不够的。

相反，我们需要先为问题事件定义一个触发器表达式（温度高于 20°C）。
然后还需要定义一个额外的恢复条件（温度低于 15°C）。
这可以通过在[配置](/manual/config/triggers/trigger)触发器时定义一个*恢复表达式*来实现。

在这种情况下，问题恢复分两步进行：

-   首先，问题表达式（温度高于 20°C）必须计算为 FALSE
-   其次，恢复表达式（温度低于 15°C）必须计算为 TRUE

恢复表达式仅在问题事件被解决后才会进行计算。仅恢复表达式为 TRUE 并不会解决问题，如果问题表达式仍然为 TRUE！

[comment]: # ({/bae4792f-3f1b1c81})

[comment]: # ({fe73812a-942a7e0e})
**示例**

服务器机房温度过高。

问题表达式：

```default
last(/server/temp)>20
```

恢复表达式：

```default
last(/server/temp)<=15
```

:::noteclassic
在恢复表达式中使用 {TRIGGER.VALUE} 宏没有实际意义，因为该表达式仅在触发器处于“问题”状态时才会被求值。因此，在对表达式求值时，{TRIGGER.VALUE} 始终会解析为“1”（表示“问题”状态）。
:::

[comment]: # ({/fe73812a-942a7e0e})