老计聊SRE 05告警不是越多越好,基于燃尽率的告警哲学本系列的示例应用和脚本开源在 GitHub(仓库地址见文末)。本篇所有数据来自对示例应用的真实压测。本篇目标上一篇留了个尾巴:错误预算不能等到月底才看,得实时盯着消耗速度,快烧完之前就得有人知道。靠什么知道?靠告警。但告警这东西,做不好比不做还糟。学完本篇你将掌握:为什么告警越多越没用,什么是告警疲劳该对着什么告警:症状(用户的痛)还是原因(机器的忙)什么是基于燃尽率的告警,它凭什么比固定阈值聪明用一段真实故障时间线,看好告警怎么该响时响,不该响时闭嘴一、告警太多,等于没有告警先说个很多团队都有的病。监控系统一天发几百条告警,群里消息响个不停。CPU 高了报一条、内存涨了报一条、某个接口慢了报一条。时间一长,大家养成了一个习惯:把告警当背景噪音,看都不看。于是真正致命的那条告警来的时候,淹没在几百条无关紧要的消息里,没人注意到。等发现的时候,故障已经烧了半小时。这就是告警疲劳。它的可怕之处在于,你以为自己有监控,其实那些告警早已失效,因为没有人再认真对待它们了。所以好告警的第一原则,反直觉但极其重要:宁可少,不可滥。每一条告警响起,都应该意味着有人需要立刻做点什么。如果一条告警响了你可以不管,那它就不该存在。告警太多,真正重要的那条就被淹没了二、对着用户的痛告警,别对着机器的忙第二个原则:告警要基于症状,而不是原因。原因型告警:CPU 到 90% 了、内存快满了、磁盘 IO 高了。这些是机器忙的表现。症状型告警:用户请求的错误率涨了、延迟变慢了、服务不可用了。这些是用户痛的表现。区别在哪?CPU 到 90%,用户不一定有感觉;可用户请求开始失败,那一定是真出事了。想想第02篇讲过的:一台 CPU 只用 20% 的服务器,用户请求照样可能大量失败。反过来,CPU 飙到 90% 但请求全都正常返回,用户根本不在乎。所以该对着告警的,是用户真正会痛的那些指标,也就是我们前几篇一直在讲的 SLI:可用性、延迟、错误率。CPU、内存这些原因型指标,留着排查用,别拿来当主力告警。不然你的告警会响个不停,而且大多是虚惊。一句话:告警对着 SLI,排查看资源指标。三、别用固定阈值,用错误预算的燃尽率第三个原则,也是最关键的:用燃尽率告警,而不是拍脑袋的固定阈值。传统做法是设个固定阈值,比如错误率超过 5% 就告警。这有两个问题:5% 这个数是怎么来的?拍的。而且它没跟你的 SLO 挂钩,可能服务早就在违约边缘了,阈值还没到。更聪明的做法,是把告警和上一篇的错误预算绑定。这里有个词叫燃尽率(burn rate):你消耗错误预算的速度,相对于正常该消耗的速度是多少倍。燃尽率 1:你正好按计划的速度消耗预算,一个月刚好用完,不快不慢。燃尽率 10:你正在以 10 倍的速度烧预算。本该一个月用完的额度,3 天就烧光了。燃尽率越高,说明出血越快,就越紧急。告警的紧急程度,直接挂钩燃尽率:烧得慢,发个低优先级提醒;烧得飞快,立刻呼叫值班的人起来处理。这样告警就有了明确的意义:它不再是某个数字超了,而是你的错误预算正在以危险的速度流失,再不管就要违约了。四、多窗口:把真出事和偶尔抖一下分开燃尽率告警还有个精妙的设计,叫多窗口。问题是这样的:如果只看很短的时间窗(比如1分钟),服务偶尔抖一下、错误率瞬间飙高又立刻回落,也会触发告警,又制造了噪音。可如果只看很长的窗(比如1小时),真出大事了你要等很久才反应过来。多窗口的解法是:同时看一个长窗和一个短窗,两个都超标才告警。长窗(比如1小时)确认这不是偶发抖动,是持续在烧。短窗(比如5分钟)确认这个问题现在还在发生,不是早就过去了。两个窗口同时满足,才说明确实出事了,而且还在继续,这时候告警才有意义。这样既不会被瞬时抖动骗到,也不会对已经自愈的问题穷追不舍。短窗防误报,长窗防漏报,两个都超才告警五、动手:用真实故障时间线验证理论讲完,我们用一段真实数据看看好告警是怎么工作的。我们对示例应用制造了一次完整的健康到故障再到恢复过程,记录了三个阶段的真实 SLI:t1 正常: 可用性 99.67% 错误率 0.33% t2 故障: 可用性 88.00% 错误率 12.00% P95 502ms t3 恢复: 可用性 100% 错误率 0%我们的 SLO 是可用性 99%(错误预算 1%)。拿这三个阶段对照告警逻辑看:阶段错误率相对1%预算燃尽率告警行为t1 正常0.33%远低于红线约 0.33 倍不告警(正常消耗)t2 故障12.00%红线的12倍约 12 倍立刻高优先级告警t3 恢复0%完全没消耗0不告警,并自动消警三个阶段的燃尽率,只有故障期触发告警这张表把前面几个原则全串起来了:t1 正常期,错误率 0.33%,比 1% 的红线低得多,燃尽率约 0.33 倍,预算烧得比计划还慢。这时候如果用错误率超 5% 才报的固定阈值,当然不报;而用燃尽率看,它也安安静静,不制造噪音。这就是不该响时闭嘴。t2 故障期,错误率飙到 12%,是预算红线的 12 倍,燃尽率约 12 倍。这意味着本该用一个月的预算,两三天就要烧光。燃尽率这么高,告警立刻拉响,而且是高优先级,直接叫人。这就是该响时响。t3 恢复期,错误率回到 0,燃尽率归零,告警自动解除。不需要人去手动关,因为触发它的条件已经不成立了。你看,整个过程里告警只在真正该响的 t2 响了一次。没有噪音,没有漏报,而且紧急程度和故障的严重程度是匹配的。这就是基于燃尽率的告警比固定阈值高明的地方。六、小结告警太多会导致告警疲劳,真正重要的被淹没;好告警的第一原则是宁少勿滥,每条都要求有人立刻行动对着症状(SLI:可用性/延迟/错误率)告警,别对着原因(CPU/内存)告警;资源指标留着排查用用燃尽率告警而不是固定阈值:燃尽率是预算消耗速度相对正常的倍数,越高越紧急多窗口(长窗防漏报、短窗防误报)把真出事和偶尔抖一下分开真实故障时间线验证:正常期(0.33%)不响、故障期(12%,燃尽率约12倍)立刻高优先级响、恢复期(0%)自动消警下一篇:告警响了,谁来接,怎么接,On-call 值班体系怎么设计才可持续、不把人熬垮。参考链接本系列开源仓库(示例应用 压测脚本):https://github.com/Jich1123/sre-aws-labGoogle SRE Book - Monitoring Distributed Systems:https://sre.google/sre-book/monitoring-distributed-systems/Google SRE Workbook - Alerting on SLOs(燃尽率与多窗口):https://sre.google/workbook/alerting-on-slos/Google SRE Book - Practical Alerting:https://sre.google/sre-book/practical-alerting/ 老计聊SRE 05告警不是越多越好,基于燃尽率的告警哲学本系列的示例应用和脚本开源在 GitHub(仓库地址见文末)。本篇所有数据来自对示例应用的真实压测。本篇目标上一篇留了个尾巴:错误预算不能等到月底才看,得实时盯着消耗速度,快烧完之前就得有人知道。靠什么知道?靠告警。但告警这东西,做不好比不做还糟。学完本篇你将掌握:为什么告警越多越没用,什么是告警疲劳该对着什么告警:症状(用户的痛)还是原因(机器的忙)什么是基于燃尽率的告警,它凭什么比固定阈值聪明用一段真实故障时间线,看好告警怎么该响时响,不该响时闭嘴一、告警太多,等于没有告警先说个很多团队都有的病。监控系统一天发几百条告警,群里消息响个不停。CPU 高了报一条、内存涨了报一条、某个接口慢了报一条。时间一长,大家养成了一个习惯:把告警当背景噪音,看都不看。于是真正致命的那条告警来的时候,淹没在几百条无关紧要的消息里,没人注意到。等发现的时候,故障已经烧了半小时。这就是告警疲劳。它的可怕之处在于,你以为自己有监控,其实那些告警早已失效,因为没有人再认真对待它们了。所以好告警的第一原则,反直觉但极其重要:宁可少,不可滥。每一条告警响起,都应该意味着有人需要立刻做点什么。如果一条告警响了你可以不管,那它就不该存在。告警太多,真正重要的那条就被淹没了二、对着用户的痛告警,别对着机器的忙第二个原则:告警要基于症状,而不是原因。原因型告警:CPU 到 90% 了、内存快满了、磁盘 IO 高了。这些是机器忙的表现。症状型告警:用户请求的错误率涨了、延迟变慢了、服务不可用了。这些是用户痛的表现。区别在哪?CPU 到 90%,用户不一定有感觉;可用户请求开始失败,那一定是真出事了。想想第02篇讲过的:一台 CPU 只用 20% 的服务器,用户请求照样可能大量失败。反过来,CPU 飙到 90% 但请求全都正常返回,用户根本不在乎。所以该对着告警的,是用户真正会痛的那些指标,也就是我们前几篇一直在讲的 SLI:可用性、延迟、错误率。CPU、内存这些原因型指标,留着排查用,别拿来当主力告警。不然你的告警会响个不停,而且大多是虚惊。一句话:告警对着 SLI,排查看资源指标。三、别用固定阈值,用错误预算的燃尽率第三个原则,也是最关键的:用燃尽率告警,而不是拍脑袋的固定阈值。传统做法是设个固定阈值,比如错误率超过 5% 就告警。这有两个问题:5% 这个数是怎么来的?拍的。而且它没跟你的 SLO 挂钩,可能服务早就在违约边缘了,阈值还没到。更聪明的做法,是把告警和上一篇的错误预算绑定。这里有个词叫燃尽率(burn rate):你消耗错误预算的速度,相对于正常该消耗的速度是多少倍。燃尽率 1:你正好按计划的速度消耗预算,一个月刚好用完,不快不慢。燃尽率 10:你正在以 10 倍的速度烧预算。本该一个月用完的额度,3 天就烧光了。燃尽率越高,说明出血越快,就越紧急。告警的紧急程度,直接挂钩燃尽率:烧得慢,发个低优先级提醒;烧得飞快,立刻呼叫值班的人起来处理。这样告警就有了明确的意义:它不再是某个数字超了,而是你的错误预算正在以危险的速度流失,再不管就要违约了。四、多窗口:把真出事和偶尔抖一下分开燃尽率告警还有个精妙的设计,叫多窗口。问题是这样的:如果只看很短的时间窗(比如1分钟),服务偶尔抖一下、错误率瞬间飙高又立刻回落,也会触发告警,又制造了噪音。可如果只看很长的窗(比如1小时),真出大事了你要等很久才反应过来。多窗口的解法是:同时看一个长窗和一个短窗,两个都超标才告警。长窗(比如1小时)确认这不是偶发抖动,是持续在烧。短窗(比如5分钟)确认这个问题现在还在发生,不是早就过去了。两个窗口同时满足,才说明确实出事了,而且还在继续,这时候告警才有意义。这样既不会被瞬时抖动骗到,也不会对已经自愈的问题穷追不舍。短窗防误报,长窗防漏报,两个都超才告警五、动手:用真实故障时间线验证理论讲完,我们用一段真实数据看看好告警是怎么工作的。我们对示例应用制造了一次完整的健康到故障再到恢复过程,记录了三个阶段的真实 SLI:t1 正常: 可用性 99.67% 错误率 0.33% t2 故障: 可用性 88.00% 错误率 12.00% P95 502ms t3 恢复: 可用性 100% 错误率 0%我们的 SLO 是可用性 99%(错误预算 1%)。拿这三个阶段对照告警逻辑看:阶段错误率相对1%预算燃尽率告警行为t1 正常0.33%远低于红线约 0.33 倍不告警(正常消耗)t2 故障12.00%红线的12倍约 12 倍立刻高优先级告警t3 恢复0%完全没消耗0不告警,并自动消警三个阶段的燃尽率,只有故障期触发告警这张表把前面几个原则全串起来了:t1 正常期,错误率 0.33%,比 1% 的红线低得多,燃尽率约 0.33 倍,预算烧得比计划还慢。这时候如果用错误率超 5% 才报的固定阈值,当然不报;而用燃尽率看,它也安安静静,不制造噪音。这就是不该响时闭嘴。t2 故障期,错误率飙到 12%,是预算红线的 12 倍,燃尽率约 12 倍。这意味着本该用一个月的预算,两三天就要烧光。燃尽率这么高,告警立刻拉响,而且是高优先级,直接叫人。这就是该响时响。t3 恢复期,错误率回到 0,燃尽率归零,告警自动解除。不需要人去手动关,因为触发它的条件已经不成立了。你看,整个过程里告警只在真正该响的 t2 响了一次。没有噪音,没有漏报,而且紧急程度和故障的严重程度是匹配的。这就是基于燃尽率的告警比固定阈值高明的地方。六、小结告警太多会导致告警疲劳,真正重要的被淹没;好告警的第一原则是宁少勿滥,每条都要求有人立刻行动对着症状(SLI:可用性/延迟/错误率)告警,别对着原因(CPU/内存)告警;资源指标留着排查用用燃尽率告警而不是固定阈值:燃尽率是预算消耗速度相对正常的倍数,越高越紧急多窗口(长窗防漏报、短窗防误报)把真出事和偶尔抖一下分开真实故障时间线验证:正常期(0.33%)不响、故障期(12%,燃尽率约12倍)立刻高优先级响、恢复期(0%)自动消警下一篇:告警响了,谁来接,怎么接,On-call 值班体系怎么设计才可持续、不把人熬垮。参考链接本系列开源仓库(示例应用 压测脚本):https://github.com/Jich1123/sre-aws-labGoogle SRE Book - Monitoring Distributed Systems:https://sre.google/sre-book/monitoring-distributed-systems/Google SRE Workbook - Alerting on SLOs(燃尽率与多窗口):https://sre.google/workbook/alerting-on-slos/Google SRE Book - Practical Alerting:https://sre.google/sre-book/practical-alerting/