深入浅出分布式技术原理
陈现麟
伴鱼技术中台负责人,前小米工程师
21241 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
深入浅出分布式技术原理
15
15
1.0x
00:00/00:00
登录|注册

14|可观测性(二):如何设计一个高效的告警系统?

分级机制提高处理效率
相信工程师,责任到人
解决方法的探讨
遇到告警通知信噪比低的情况
独立程序监控告警系统
故障复盘中严肃讨论
简单易懂,可解释性强
“正在处理”机制抑制过度骚扰
逐级上升,组织架构依赖
对分布式系统或服务运维治理的重要元数据
电话报警规则,基于服务等级
告警排名竞争,公开发布
开会强调问题,提高重视度
信噪比低,告警系统形同虚设
告警通知数量过多导致恶性循环
评估“报对人”问题
被转交的告警通知数占全部告警通知数的比例
评估“漏报”问题
告警系统通知的故障占全部线上故障的比例
评估“多报”问题
有效告警通知数与无效告警通知数的比例
设计经验的运用
告警治理案例的思考
评价指标的应用
个人经历
告警缺失问题
告警规则
告警信息处理流程
服务等级信息
解决方法
案例背景
转交率
覆盖率
信噪比
结论
思考题
告警系统的设计经验
告警治理案例
告警系统的评价指标
可观测性(二):如何设计一个高效的告警系统?

该思维导图由 AI 生成,仅供参考

你好,我是陈现麟。
通过上节课的学习,我们掌握了在可观测性体系中,监控的位置和重要性,以及设计一个监控系统的基本原则,这样我们就可以为极客时间搭建一个可观测体系,并且设计一个简洁有效的监控系统了。
但是,只有监控还是不够的,因为我们不能一直盯着监控系统,所以需要通过一些规则,自动从监控的信息中发现问题,实时通知给负责的工程师,让工程师实时接入来处理。
那么解决这个问题的有效方法就是告警,你作为工程师,应该收到过各种各样的告警信息,并且及时解决了很多线上问题。但是,你也一定收到过很多无效的报警信息,这些信息浪费了我们的精力;有时线上故障真的发生了,反而会出现收不到告警信息的情况,导致我们错过了最佳的修复时间。
其实这是因为告警系统的设计不够高效,那么在本节课中,我们将一起来解决这个问题。我们会先讨论一个告警系统的评价指标,然后基于我的亲身经历,来讨论如何进行告警的治理,最后再来总结告警系统的设计经验。

告警系统的评价指标

告警系统的作用是把线上已经出现,或即将出现的故障及时通知给我们,所以一个理想的告警系统应该是不多报,不漏报,报对人。即所有的通知都是有效的,是需要立即处理的;所有的故障或即将出现的故障,都有告警通知;所有通知的接受对象,应该是处理这个问题的最佳人选。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

告警系统设计经验 告警系统的设计对于保障系统稳定运行至关重要。本文从评价指标、告警治理案例和设计经验三个方面介绍了如何设计一个高效的告警系统。 首先,文章提出了评价告警系统的三个指标:信噪比、覆盖率和转交率。这为读者提供了评估告警系统高效性的依据。 其次,通过一个实际案例,分享了在工程师数量快速增长、告警通知过多导致忽略处理的情况下,如何通过告警治理来解决问题。作者提出了通过电话报警规则和服务等级来提高告警处理效率,避免频繁骚扰工程师的方法。 最后,结合工作中对告警系统的设计经验,强调了相信工程师并责任到人、利用服务等级信息建立告警规则、避免告警通知的单点问题等设计原则。同时,强调了告警规则的简单易懂和告警缺失的严重性。 总的来说,本文通过评价指标、案例分享和设计经验,为读者提供了评估告警系统高效性的依据,以及解决告警通知过多问题的实际方法和设计经验。这些内容对于需要设计或改进告警系统的技术人员具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入浅出分布式技术原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • peter
    请教老师两个问题: Q1:告警系统和可观测系统是两个独立的系统吗? 在可观测系统上添加告警功能,可以吗? Q2:告警系统是从ELK中获取日志信息吗? 如果是,是将Logstash的数据直接导流到告警系统吗?或者从ES获取数据?如果不是,那告警系统是自己独立获取日志信息吗?

    作者回复: Q1:告警系统是可观测性的一部分,上一节课在介绍可观测性的图片中有介绍。 Q2:这个问题是问课程中基于日志数量的报警实现吗?这个可以将日志的数据按等级的 Metric 上报到 Prometheus,然后基于 Prometheus 的数量来设置报警规则来报警。直接通过ELK查日志的话,数据量太大,链路长,时延可能会比较大

    2022-02-28
    3
    2
  • 不吃辣👾
    思考题:我们的通知方式不是电话,收到告警后,针对核心服务,采用轮班制,每天一位责任人负责识别是否为有效告警,告警有效,催促别人的修复或者调整不合理的预警规则。针对非核心服务,就采用钉钉消息推送,靠个人自觉。

    作者回复: 这个是 oncall 机制。 优化好报警的信噪比就可以了。

    2022-04-08
  • 不吃辣👾
    老师,如果应用服务不在打印日志,有可能长时间gc,这种是否也应该告警一次? 因为elk并不知道是因为服务宕机了还是触发了gc。

    作者回复: 这个规则也可以,不过探活也有告警的,会更直接。

    2022-03-30
  • 不吃辣👾
    基于日志的告警,如果日志不再打印是不是可以认为服务不可用了,应告警。一分钟内两次这种告警就P0级别告警。

    作者回复: 告警一般是网状的,会交叉覆盖,一般服务不可用还有服务的探活等告警

    2022-03-30
  • 极客
    请教一个问题: 我们的业务是toB的,不同接入方申请的qps不同,我们基于当前的qps 同比前一分钟,对比昨天的qps来触发告警。 但是不同的接入方实际调用qps不同,比如我设置qps增量100%触发告警 A公司目前qps 1000,也就是到了2000要告警 B公司目前qps 10000, 不能到了20000才告警,期望在12000左右就要触发告警了(希望有个科学一点的公式) 不知道老师有什么经验吗

    作者回复: 对于第三方阈值的定义,这个一般在sla里面有描述的。一般以这个为准就行。

    2022-03-12
  • xmr
    转交率是指什么?没看懂
    2023-06-14归属地:广东
  • 波波安
    有些什么方法或者经验可以避免漏报呢
    2023-04-23归属地:广东
  • includestdio.h
    有个问题想请教下老师,我们目前是用告警监控增量,我觉得不太合理。具体是这样:比如一个机器的cpu常年cpu是30,然后设置一个阈值是40,如果超过40需要去确认下是否业务正常增量,如果是正常增量的话调高阈值,如果异常的话解决问题,但是这样搞的话 我觉得告警信噪比太低了,无效告警一大堆,影响业务的告警可能会被忽略,所以我的想法是cpu阈值全部调整到会影响业务的阈值,比如90 95,但是增量的监控我觉得也是有必要的,但是用告警的方法不太合理,哪怕是把告警等级降低 频率降低我也觉得不是很合理,毕竟这本质上不算“告警”,但是告警好像又是及时发现增量排除隐患的最快方法,以上是我目前告警收敛工作中遇到的障碍
    2022-09-30归属地:陕西
  • 罗东就
    告警精准推动到负责人,这个老师有什么思路吗
    2022-08-12归属地:广东
    1
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部