仍然可以达成相同的效果。有时采集的监控数据格式设计的不好，一些本该用 label 的信息，放 到了 metric 名称中了，此时就可以用 __name__ 做一些正则匹配。 Offset 监控系统里，经常会有同环比的需求，比如，当前的值相比一周之前，是否有巨大变化，那怎么 才能获取历史数据呢？可以使用 offset 关键字。 offset 后面跟一个时间段，比如 5m、1d、7d、1w，offset 要紧跟查询选择器，比如： mem_total{app="clickhouse"} 也能找到5条，二者相除的逻辑姑且可以理解为，循环遍历 mem_available 的5条记录，对于每一条，去 mem_total 的5条记录中找标签相同的记录，进 行除法运算。除法运算得到5条结果（0~1之间的数字），然后跟100相乘（得到百分比大 小），100这个数字称为标量，5条结果和标量计算，会把每一条结果分别乘以100，得到最终 的结果，这个最终结果其实就是

警。但是具体怎么分级，却没有一个行业共识，大家各做各的。这里我也分享一下我的理解，你可以参考 借鉴。 首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 同，或者介入处理的人的范围不同，处理时效不同 ，如果某两个级别对应完全一样的处理逻辑，就可以 合并成一个级别。 我的做法是把告警分成 3 个级别。 级别 通知渠道 说明 Critical 发生之后没有对应的处理动 作，这个故障对应的告警规则可能就是不合理的，需要优化。 总结 告警事件的后续处理，不只是发往各个通知媒介那么简单。涉及到收敛、降噪、排班、认领、升级、协 同、IM 打通 等非常多的细节功能，各个监控系统通常不会在这个方面发力，但是告警的统一处理又是非 常强的需求，故而，我们推荐您使用 FlashDuty 来处理。下面是 FlashDuty 相关信息：