底层的告警，上层应用应该收吗？

有朋友问：

我是业务应用的 DEV 或 SRE，我的应用依赖了底层服务和基础设施，比如基础网络、Kubernetes、MySQL、收银台服务。这些基础服务如果出问题，我应该收告警吗？夜莺里有个订阅规则，是不是就是为此设计的？

我的判断很简单：不要按“是否依赖”来决定是否收告警，要按“收到之后能不能行动”来决定。

前一篇《CPU负载高，到底应不应该告警？》里提到过一个原则：只有 actionable 的告警规则才有意义。网友的留言更直接：没有 SOP 的告警都是垃圾。

这篇文章继续沿着这个原则，讲清楚上层业务团队该不该订阅底层告警，以及订阅规则、SLI 看板和业务埋点各自应该解决什么问题。

核心结论

上层应用依赖基础网络、Kubernetes、MySQL、收银台服务，并不等于这些底层告警都应该推给上层 DEV 或 SRE。

关键问题只有一个：这个告警来了以后，你有没有可执行动作？

场景	是否建议订阅底层告警	原因	更适合的做法
单机房部署，底层故障时只能等待恢复	不建议作为强打扰告警订阅	没有 SOP，收到也无法止损	做 SLI 可视化页面，观察依赖健康
有切流、降级、限流、业务通知等 SOP	建议订阅关键告警	告警能触发明确动作	订阅带周知标签的关键规则
底层指标业务团队看不懂	不建议直接订阅全部规则	噪音大，语义不清	由底层负责人标注可周知规则
依赖 MySQL、收银台等服务	不能只依赖底层 SLI	底层视角通常是实例级或全局级	在上层应用采集成功率、延迟

如果你的服务是单机房部署，基础设施或底层服务出问题时，你无能为力，只能被动等待恢复，那就说明你没有可执行 SOP。

这种情况下，强行订阅底层告警意义不大。它只会让上层团队更早知道“坏了”，但不能带来更快止损。

更推荐的做法是做一个可视化页面，把业务应用依赖的基础设施和服务关键 SLI 放上去。业务团队可以通过 UI 趋势图了解各个依赖对象的健康状况，在事故沟通和影响判断时有共同视图。

Facebook 内部产品 SLICK 是类似逻辑。Flashcat 里的“灭火图”也有类似效果：把依赖对象、健康状态和下钻入口组织在一个页面里，让团队知道当前依赖链路是否健康。

如果业务团队有明确 SOP，比如可以切流，那么订阅底层关键告警是有意义的。

但这里也不建议订阅全部底层规则。很多底层服务的关键指标，上层应用团队未必看得懂。更好的做法是建立一套规则标注规范：

比如 MySQL 负责人可以给需要周知的规则打上 advertise=mysql 标签，表示所有 MySQL 相关、需要上层知悉的告警。上层应用团队订阅这个标签即可。

这类标签的价值，是把“底层系统自己关心的告警”和“上层业务需要感知的告警”分开。订阅规则不是为了扩大通知范围，而是为了把真正需要协同的告警送到正确的人。

对于 MySQL、收银台这类依赖，只订阅它们的 SLI 告警还不够。更好的方式，是在上层应用里自行埋点，重点采集：

原因很简单：从 MySQL 的视角看，SLI 指标通常面向整个实例；从收银台服务的视角看，指标也可能面向整体服务。但上层应用更关心的是“我的这条业务链路是否受影响”。

同一个 MySQL 实例可能承载多个业务。实例级 SLI 正常，不代表某个业务的查询路径正常；实例级 SLI 异常，也不一定代表你的业务已经受到影响。上层应用侧埋点可以把成功率和延迟细化到具体服务、接口或业务动作，判断会更准。

不应该。订阅范围应该由 SOP 决定，而不是由依赖关系决定。没有处置动作的告警，最多用于可视化观察，不适合作为强打扰通知。

订阅规则适合把需要周知的关键告警推给上层团队。前提是底层负责人要把这类规则标注清楚，比如使用 advertise=mysql 这样的标签。

不要让上层团队直接理解所有底层指标。由底层服务负责人筛选并标注需要周知的关键规则，上层团队订阅标签即可。

可视化页面用于理解依赖健康状况，告警订阅用于触发行动。没有 SOP 时优先做可视化；有 SOP 时再订阅关键告警。

底层告警要不要推给上层应用团队，本质不是监控工具问题，而是责任边界和处置能力问题。

没有 SOP，就做 SLI 可视化和灭火图，帮助团队理解依赖健康；有 SOP，就订阅底层负责人明确标注的关键告警；对 MySQL、收银台这类依赖，还要在上层应用侧埋点，用成功率和延迟判断自己的真实业务影响。