首先，并不是所有的告警都需要升级成故障协同处理。一般来讲，如果告警可以被值班人员直接处理掉， 对别的团队负责的服务没有影响，不需要通知别的团队，通常是不需要升级成故障的，在告警层面来协同 就可以了，自己团队内部消化掉；如果值班人员和他所在的团队没办法独自处理告警，才需要升级成故 障，拉其他团队的人进来一起处理。 多个团队共同处理一个故障，不同团队的人会发现一些不同的线索，需要及时同步给所有相关的人，这个 Webhook，当告警触发之后自动回调某个 HTTP 接口，来串联一些自动化的 逻辑，让告警事件无人值守自动处理。比如某个机房的某个服务挂掉了，Webhook 的逻辑是自动调用切 流的接口，把服务流量切走，这样来达到止损的目的。 告警自动处理的这段逻辑，未必一定能够做到告警自愈，有的时候只是使用这个机制来抓现场，也是非常 有价值的。比如某个进程挂掉了，在挂掉的时候我想知道当时机器的一些运行情况，比如各项资源的占用 Critical 的事件，Info 的就被忽略了。 相关策略配置好之后，就可以收告警了，比如利用钉钉发送，会呈现为一张告警消息卡片： 我们可以直接在钉钉（或飞书、企微等 IM）内部点击跟进，或直接关闭、临时屏蔽，方便地移动办公。 当然，也可以登录 FlashDuty，在 WEB 上查看，需要有个非常直观的页面告诉用户您当前有哪些告 警，分成了几类，每一类有多少条之类的。

告警阈值需要随着流量量变化⽽而调整 wrong 建议: 告警规则: 业务A 慢请求⽐比例例 > 80% 案例例2 告警规则: 磁盘容量量可⽤用率 <10% 告警规则: 磁盘容量量预计将于3⼩小时后饱和 0 now -1h +3h predict_linear(node_filesystem_free{}[1h], 3 * 3600) < 0 异常检测 异常流量量 abs(requests

一个值和第一个值做数据外 推，一些毛刺现象就会被平滑掉，如果想要得到更敏感的数据，可以使用 irate 函数。irate 是 拿时间范围内的最后两个值来做计算，变化就会更剧烈，我们还是拿网卡入向流量这个指标来做 个对比： 蓝色的更变化更剧烈的线是 irate 函数计算的，紫色的相对平滑的线是 rate 函数计算得到的。 histogram_quantile 要了解 histogram_quantile