On this page
4 触发器的最佳实践
触发器是一个强大的工具，但它们也可能产生不必要的告警噪音。为了看到更多真实信号、减少噪音，请遵循以下建议：
-
降低触发器敏感度。与其根据最新值（过高/过低）发出告警，不如使用
avg、min和max等函数，分析较长时间段内的平均值。 -
如果你希望避免因随机尖峰和骤降而触发告警，可以考虑在触发器中使用
percentile函数（将其设置为 95% 或 5%）。 -
使用 滞后 来避免触发器抖动——即触发器状态频繁变化（OK ↔ Problem）。可以通过添加恢复表达式（用于问题恢复的单独条件）来为问题状态定义一个连续区间。
-
使用触发器依赖关系，以避免与根本原因无关的告警。
-
使用触发器严重性，仅对更严重的问题发出告警。
-
定义维护时间窗口。
滞后
有时，问题状态与恢复状态之间需要一个区间，而不是一个简单的阈值。 例如，如果我们想定义一个触发器：当服务器机房温度高于 20°C 时报告问题，并且希望它保持在问题状态，直到温度降到 15°C 以下，那么仅设置一个 20°C 的简单触发器阈值是不够的。
相反，我们需要先为问题事件定义一个触发器表达式（温度高于 20°C）。 然后还需要定义一个额外的恢复条件（温度低于 15°C）。 这可以通过在配置触发器时定义一个恢复表达式来实现。
在这种情况下，问题恢复分两步进行：
- 首先，问题表达式（温度高于 20°C）必须计算为 FALSE
- 其次，恢复表达式（温度低于 15°C）必须计算为 TRUE
恢复表达式仅在问题事件被解决后才会进行计算。仅恢复表达式为 TRUE 并不会解决问题，如果问题表达式仍然为 TRUE！
示例
服务器机房温度过高。
问题表达式：
last(/server/temp)>20恢复表达式：
last(/server/temp)<=15在恢复表达式中使用 {TRIGGER.VALUE} 宏没有实际意义，因为该表达式仅在触发器处于“问题”状态时才会被求值。因此，在对表达式求值时，{TRIGGER.VALUE} 始终会解析为“1”（表示“问题”状态）。