显，其次就是告警分级原则。 每个告警都应该合理分级 基本每个监控系统都支持为告警规则配置不同的级别，基本上每个监控系统的用户也都知道应该做分级告 警。但是具体怎么分级，却没有一个行业共识，大家各做各的。这里我也分享一下我的理解，你可以参考 借鉴。 首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 同，或者介入处理的人的范围不同，处理时效不同 中的告 警和故障建立完美的对应关系，不过从降噪收敛角度来看，够用了。 3、根据时间 + 文本相似度做收敛 文本相似度需要引入算法，但是算法总得有个规律，我们很想把某个故障相关的告警聚拢到一起，但是显 然，很难有个行之有效的规律，没有规律的算法效果自然好不到哪儿去。 既然没办法把告警自动收敛成故障，那就手工来做。一个故障关联的关键告警，还是相对容易区分的，只 要把关键告 告警聚合 事件到告警的聚合比较容易，通常是用类似下面的算法来计算不同事件的关联关系： hash(32 + ["__name__=cpu_usage_idle", "host=host1"]) 这个值姑且称为事件 Hash，相同 Hash 的事件就被聚合为一条告警。更复杂的是告警到故障的合并，当 前我们支持基于规则的聚合，后面会基于算法聚合： 比如基于告警规则标题做聚合，某一时刻，基础网络故障，有

increase，无非就是最后一个值减去第一个 值，即965323899880-965304237246=19662634，很遗憾，实际结果是23595160.8，差别 有点大，显然这个直观理解的算法是错的。 实际上，increase 这个 promql 发起请求的时间是1661570909，时间范围是[1m]，相当于告 诉Prometheus，我要查询1661570849（16615709 le="+Inf" 桶里，即值一定是大于60秒的，因为 le="+Inf" 这个桶没有上 界，导致我们无法区分这几个分位值。 1 2 3 4 5 6 7 8 下面我们假设一个指标及其数据，做一个算法演示，假设指标名是 http_request_duration_seconds_bucket ，其各个 bucket 的值如下： http_request_duration_seconds_b 9=900，第900个请求，显然，第 900个请求落在了10~20这个区间，即90分位的延迟是10秒~20秒，那具体是多少？其实是无 法知晓的，不过 Prometheus 的 histogram_quantile 有个估计算法，它假设落在各个 bucket 的数据是均匀分布的，即10~20这个区间的150个请求，延迟最小的那个请求是10s，延迟最大 的那个请求是20秒，总的第900个请求，就是这个区间的第50个请求，其延迟数据大概是：