告警恢复时，如何拿到当前值

在夜莺新版本中，告警规则直接使用 promql 来配置，阈值就包含在 promql 里面，所以恢复时是无法拿到当前值的，因为恢复时监控数据不达阈值，不达阈值就不会返回数据，所以也就无法拿到当前值。Prometheus 也是类似的问题，不过可以通过 go template 中的 query 函数曲线救国，但是不够直观，学习曲线较高。今天给大家介绍两种实现思路来解决这个问题。

• 思路一：查询的 promql 中不包含阈值，只包含过滤条件，直接去查询原始数据，告警引擎查到原始数据之后做阈值判定，不管是否触发阈值，都可以拿到当前值。
• 思路二：查询的 promql 中包含阈值，恢复时拿着相关标签去做二次查询，这样也可以拿到当前值。这种方式和 go template 中的 query 函数类似，相对会直观一些。

下面我以 Flashduty 产品为例，截图说明具体配置方式。

Flashduty 是一个告警事件中心，其产品介绍地址：FlashDuty - 快猫星云 。核心提供两个能力：1）告警事件中心，可以把夜莺、Zabbix、Prometheus、云监控等各类监控系统的告警汇聚在一个地方，做统一的告警收敛、聚合降噪、排班、认领、升级、派发、协作；2）Flashduty 也直接提供告警引擎的能力，可以对接 VictoriaMetrics、M3DB、Prometheus、ClickHouse、MySQL、Oracle、Postgres 等数据源，直接查询数据源的数据做告警判定，不需要额外的监控系统，告警事件的产生和分发，Flashduty 一肩挑。

方案一

以 Memcached 的某个告警规则举例，查询条件里不写阈值，判定规则里写阈值，如下图所示：

这种方式需要先查到当前值，再拿着当前值去做判定，所以不管是告警时还是恢复时，都可以拿到当前值。这种方式非常直观，大部分场景都适用。对于一个查询条件过滤到很多时序的场景，这种方式会查到特别多的数据，对告警引擎也是个压力。可以尝试方案二。

方案二

在 Flashduty 中，方案二称为「数据存在」的告警方式，这种方式只要查到数据就告警。需要在查询条件的 promql 中写阈值，比如：

cpu_usage_active{ident=~"dev-n9e.*", cpu="cpu-total"} > 85

具体页面配置如下：

这种设置方式就和 Nightingale、Prometheus 的做法一样了，自然会面临一样的问题，无法在告警判定时拿到阈值。针对这种写法，Flashduty 提供了一种方法，通过配置关联查询语句曲线救国拿到触发时的值，还是以 cpu_usage_active 这个指标为例，可以配置这样的关联查询以及备注描述：

其中关联查询的名字设置为 X（当然，你可以设置为其他名字），关联查询的语句也是一个 promql，用于精确查询具体的值，这里的 promql 可以引用标签变量，比如上例中的 ident="${ident}"，${ident} 就表示告警事件中的 ident 标签。之后在备注描述中写 if else 语句，针对告警、恢复两种情况分别写不同的获取值的方式。

关联查询其实非常灵活，不止是用于获取恢复时的值。比如 A 指标告警的时候想顺带看到 B 指标的值，或者日志告警 Error 数量触发阈值时看到日志详情，都可以使用关联查询来做到。

Flashduty 的告警引擎功能当前是公测阶段，欢迎免费体验，注册地址：

https://console.flashcat.cloud/

欢迎加我好友，交流可观测性相关话题或了解我们的商业产品，我的微信号：picobyte，加好友请备注您的公司、姓名、来意

扩展阅读：

• 方法论：面向故障处理的可观测性体系建设
• 小总结：从CTO视角来看：如何搭建运维/SRE能力
• 鄙人专栏：运维监控系统实战笔记