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

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

本文讲讲笔者的个人理解，仅供参考。

首先，请大家看一下上一篇文章《CPU负载高，到底应不应该告警？》，其中提到一个点：只有 actionable 的告警规则才有意义！

所以，要看你们的情况：

1，如果你的服务是单机房部署，这些基础设施和服务出问题你无能为力，只能被动等待恢复，即你没有 SOP，那收这些告警意义不大。

此时推荐的做法是：做一个可视化页面，把你依赖的基础设施和服务的关键 SLI 放上去，你能通过查看 UI 趋势图，了解到各个基础设施和服务的健康状况即可。Facebook 有个内部产品叫 SLICK，就是类似的逻辑，我们创业做的 Flashcat 里有个功能叫“灭火图”，也有类似的效果。这算是一个惯常做法。

2，如果你有 SOP，比如可以切流，那么去订阅这类告警是有意义的。

但是，很多底层服务的关键指标你也未必看得懂，此时最好有个规范。比如，每个底层服务的负责人，在配置告警规则时，如果觉得那个告警规则很重要，对应的告警会影响上层服务，那就给那个规则打上一个特殊标签，比如 advertise=mysql 表示所有 MySQL 相关的需要周知的告警，比如 advertise=k8s 表示所有 Kubernetes 相关的需要周知的告警，之后上层应用的 DEV、SRE 就可以订阅这类标签，知悉相关的告警。

另外

MySQL、收银台这类服务，相比去订阅它们的 SLI 告警，更好的方式是在上层应用里自行埋点，主要是采集一下请求数、失败数、延迟就可以了。

因为从 MySQL 的视角来看，其 SLI 指标是面向整个实例的，而如果在上层应用埋点，其指标就可以细化到与这个服务相关，甚至与这个服务的特定业务场景相关，做得更精细化。