底层的告警,上层业务应该收吗?

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

本文讲讲笔者的个人理解,欢迎大家留言一起探讨实践经验。

首先,请大家看一下上一篇文章《CPU负载高,到底应不应该告警?》,其中提到一个点:只有 actionable 的告警规则才有意义,网友的留言也很直白有效:没有 SOP 的告警都是垃圾!

所以,要看你们的情况:

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

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

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

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

另外

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

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

本文作者:秦晓辉,夜莺开源项目创始人,极客时间专栏《运维监控系统实战笔记》作者,目前在监控、可观测性领域创业。

相关推荐
SRETalk3 天前
CPU 负载高,到底应不应该告警?
监控告警·运维监控
SRETalk1 个月前
夜莺监控V8发版,内置支持 DeepSeek 对接
aiops·监控告警·夜莺监控·运维监控·deepseek
夜莺云原生监控4 个月前
夜莺监控 v8.0 新版通知规则 | 对接企微告警
企业微信·监控告警·夜莺监控·企微·企微告警
迷茫运维路9 个月前
golang开发alertmanagerWebhook,实现prometheus+alertmanagerWebhook告警
golang·prometheus·webhook·alertmanager·监控告警
观测云1 年前
观测云突变告警,精准预测云原生的系统异常
云原生·监控告警
Coder-D1 年前
Kafka-exporter监控消费速度与生产速度差异规则
kafka·promql·监控告警
架构成长指南2 年前
Prometheus 与 VictoriaMetrics对比
云原生·prometheus·监控告警·victoriametrics
架构成长指南2 年前
如何使用Promethues监控系统指标并进行告警
云原生·prometheus·可观测性·监控告警
架构成长指南2 年前
一文搞定K8S监控告警平台选型
云原生·k8s·监控告警