续往上升级。 告警升级机制需要认领功能的配合，也就是一线人员收到告警之后要通过某种机制告诉系统：“我已知晓 告警，现在我开始处理了，你不要升级了”。典型的认领功能一般是做在页面上的，告警后打开告警事件 管理中心，选中相关告警一键认领，也可以通过上行短信或即时通讯工具中的上行回调机制来完成。 升级机制会给值班人员很大的压力，毕竟谁也不想稍不留神就把电话打到老板那里，所以一般只有严重的 incident。举个例子，最原始的告警事件，比如 host1 在 timestamp1 产生了一条 cpu_usage_idle 的告警，我们称为一个 event。如果没有恢复，一段时间之 后，比如 timestamp1 + 60min，一般会再发出一个告警，还是 host1，还是 cpu_usage_idle 这个指 标。很明显，这两个告警事件是有关联关系的，指代的是一个问题，只是时间戳不同，这样的两个 钉、企微、电话、短信、邮箱等。 通知了之后，相关的人可能没注意到，可以配置重复通知，比如 10 分钟之后再次通知。如果多次通知， 接收人一直没有响应，就要启动升级策略了，比如 30 分钟后，告警仍然没有恢复而且没有被人工处理， 则升级到下一个通知环节（通知环节可以有多个）。 通知的触发，最为推荐的是值班表（OnCall 排班是践行 SRE 的有效手段），其次是团队（团队可以降低人

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