写点什么

摆脱无效报警?十年运维监控报警优化经验总结

  • 2019 年 8 月 31 日
  • 本文字数:5166 字

    阅读完需:约 17 分钟

摆脱无效报警?十年运维监控报警优化经验总结

运维工程师面试者第一个问题是:需要值班吗?笔者自己也曾经历过月入十万的时期,在那个时候,数个系统同时发布下一代版本,而老系统还需要过渡很长时间,工作量直接翻倍,大家只能勉强应付一线运维工作,团队成员开始陆续离职,而新人又无法在短时间内上手,整体情况不断恶化,持续半年左右才缓过劲来。


下面两张截图是我挑选的两个团队一周报警数的对比图,前者的单日报警量最高是 55348 条,后者单日的报警量最高为 34 条,两者相差 1600 倍,而前者才是国内很多互联网运维团队的真实写照。




在管理大规模集群的情况下,究竟有多少报警量才是合理的呢?Google SRE 每周只有十条报警,如果超过十条,说明没有把无效报警过滤掉(Google SRE 仅负责 SLA 要求为 99.99%的服务)。笔者所在的团队要求则是,每周至多两晚有报警,单日报警量不能超过 50 条(比 Google SRE 放水好多啊)。


通过控制单日报警数量,严格约束夜间报警天数,确保最少不低于四人参与值班,笔者所在的团队,近几年来,不仅少有因为值班压力而离职的同学,而且我们每年都能持续招聘到 985 前 20 名学校的多个研究生。那么,怎么做到呢,以下是笔者的一些经验分享。


运维工程角度看报警优化

报警值班和报警升级

基于值班表,每天安排两人进行值班处理报警,将值班压力从全团队压缩在两人范围内,从而让团队能够有足够的时间和人力进行优化工作。同时,为了避免两个值班人员都没有响应报警,可以使用报警升级功能,如果一个报警在 5min 内值班人员均未响应,或者 15min 内未处理完毕,或者有严重故障发生,都可以将报警进行升级,通告团队其他成员协助处理。


如果公司的监控系统暂不支持值班表功能,则通过人工定期修改报警接收人的方式进行。而对于监控系统不支持报警升级的问题,通过自行开发脚本的方式,也能在一定程度上得到解决。也可以将报警短信发送至商业平台来实现。总之一句话,办法总比问题多。


对于报警值班人员,需要随时携带笔记本以方便处理服务故障,这个要求,和报警数量多少以及报警的自动化处理程度并无关系,仅和服务重要性有关。对于节假日依然需要值班的同学,公司或者部门也应该尽量以各种方式进行补偿。


基于重要性不同,分级应对

一个问题请大家思考一下,如果线上的服务器全部掉电后以短信方式通知值班人员,那么线上一台机器的根分区打满,也通过短信来通知是否有必要。


上述的问题在日常工作也屡屡发生,对于问题、异常和故障,我们采取了同样的处理方式,因此产生了如此多的无效报警。


Google SRE 的实践则是将监控系统的输出分为三类,报警,工单和记录。SRE 的要求是所有的故障级别的报警,都必须是接到报警,有明确的非机械重复的事情要做,且必须马上就得做,才能叫做故障级别的报警。其他要么是工单,要么是记录。


在波音公司装配多个发动机的飞机上,一个发动机熄火的情况只会产生一个”提醒“级别的警示(最高级别是警报,接下来依次是警告,提醒,建议),对于各种警示,会有个检查清单自动弹出在中央屏幕上,以引导飞行员找到解决方案。如果是最高级别的警报,则会以红色信息,语音警报,以及飞机操纵杆的剧烈震动来提示。如果这时你什么都不做,飞机将会坠毁。



故障自愈

重启作为单机预案,在很多业务线,可以解决至少 50%的报警。没有响应,重启试试,请求异常,重启试试,资源占用异常,重启试试,各种问题,重启都屡试不爽。


换言之,针对简单场景具有明确处置方案的报警,自动化是一个比较好的解决方案,能够将人力从大量重复的工作中解放出来。


自动化处理报警的过程中,需要注意以下问题:


  • 自动化处理比例不能超过服务的冗余度(默认串行处理最为稳妥)

  • 不能对同一个问题在短时间内重复多次的自动化处理(不断重启某个机器上的特定进程)

  • 在特定情况下可以在全局范围内快速终止自动化处理机制

  • 尽量避免高危操作(如删除操作,重启服务器等操作)

  • 每次执行操作都需要确保上一个操作的结果和效果收集分析完毕(如果一个服务重启需要 10min)



报警仪表盘,持续优化 TOP-3 的报警

如下图示,全年 TOP-3 的报警量占比达到 30%,通过对 TOP-3 的报警安排专人进行跟进优化,可以在短时间大幅降低报警量。


TOP-3 只是报警仪表盘数据分析的典型场景之一,在 TOP-3 之后,还可以对报警特特征进行分析,如哪些模块的报警最多,哪些机器的报警最多,哪个时间段的报警最多,哪种类型的报警最多,进而进行细粒度的优化。


同时,报警仪表盘还需要提供报警视图的功能,能够基于各种维度展示当前有哪些报警正在发生,从而便于当短时间内收到大量报警,或者是报警处理中的状态总览,以及报警恢复后的确认等。



基于时间段分而治之

下图是国内非常典型的一类流量图,流量峰值在每天晚上,流量低谷在每天凌晨。从冗余度角度来分析,如果在流量峰值有 20%的冗余度,那么在流量低谷,冗余度至少为 50%。基于冗余度的变换,相应的监控策略的阈值,随机也应该发生一系列的变化。


举例来说,在高峰期,可能一个服务故障 20%的实例,就必须介入处理的话,那么在低谷期,可能故障 50%的实例,也不需要立即处理,依赖于报警自动化处理功能,逐步修复即可。


在具体的实践中,一种比较简单的方式就是,在流量低谷期,仅接收故障级别的报警,其余报警转为静默方式或者是自动化处理方式,在流量高峰期来临前几个小时,重新恢复,这样即使流量低谷期出现一些严重隐患,依然有数小时进行修复。这种方式之所以大量流行,是因为该策略能够大幅减少凌晨的报警数量,让值班人员能够正常休息。



报警周期优化,避免瞬报

在监控趋势图中,会看到偶发的一些毛刺或者抖动,这些毛刺和抖动,就是造成瞬报的主要原因。这些毛刺和抖动,至多定义为异常,而非服务故障,因此应该以非紧急的通知方式进行。


以 CPU 瞬报为例,如果设置采集周期为 10s,监控条件为 CPU 使用率大于 90%报警,如果设置每次满足条件就报警,那么就会产生大量的报警。如果设置为连续 5 次满足条件报警,或者连续的 10 次中有 5 次满足条件就报警,则会大幅减少无效报警。对于重要服务,一般建议为在 3min 内,至少出现 5 次以上异常,再发送报警较为合理。



提前预警,防患于未然

对于很多有趋势规律的场景,可以通过提前预警的方式,降低问题的紧迫程度和严重性。下图是两台机器一周内的磁盘使用率监控图,可以预见,按照目前的增长趋势,必然会在某一个时间点触发磁盘剩余空间 5%的报警,可以在剩余空间小于 10%的时候,通过工单或者其他非紧急方式提醒,在工作时间段内,相对从容的处理完毕即可,毕竟 10%到 5%还是需要一个时间过程的。



日常巡检

提前预警面向的是有规律的场景,而日常巡检,还可以发现那些没有规律的隐患。以 CPU 使用率为例进行说明,近期的一个业务上线后,CPU 使用率偶发突增的情况,但是无法触发报警条件(例如 3 分钟内有 5 次使用率超过 70%报警),因此无法通过报警感知。放任不管的话,只能是问题足够严重了,才能通过报警发现。这个时候,如果每天有例行的巡检工作,那么这类问题就能够提前发现,尽快解决,从而避免更加严重的问题发生。


比例为主,绝对值为辅

线上机器的规格不同,如果从绝对值角度进行监控,则无法适配所有的机器规格,势必会产生大量无意义的报警。以磁盘剩余空间监控为例,线上规格从 80GB 到 10TB 存在多种规格,从下图表格看,比例比绝对值模式能更好的适配各种规格的场景(EXT4 文件系统的默认预留空间为 5%,也是基于比例设置的并可通过 tune2fs 进行调整)



对于一些特殊场景,同样以磁盘剩余空间为例进行说明,例如计算任务要求磁盘至少有 100GB 以上空间,以供存放临时文件,那这个时候,监控策略就可以调整为:磁盘剩余空间小于 5%报警或磁盘剩余空间绝对值小于 100GB 报警


同环比监控

同环比监控适用于有明显时间特征规律的数据,和上述提到的基于时间段分而治之的策略,两者的区别为:同环比需要较为明显的基于时间的特征规律,从而提供精准的监控,而后者则以时间段为划分粒度,对特征的精度不做要求。在不具备同环比监控能力的时期,基于时间段分而治之未尝不是一种选择。



以同环比监控的典型场景流量图为例说明,在具体的一个时间点上,可以看到当前的 QPS,昨日该时间点的 QPS(环比),以及前几周相同时间点的 QPS(同比),因此当前时间的 QPS 是否异常,并不需要关注具体值,只需要和同环比的数据进行比较,其振幅在限定的范围即可,而振幅的大小则决定了监控的敏感程度。这样,通过同环比监控的使用,在不需要人工设置具体阈值以及频繁调整的情况下,就实现了流量小幅涨跌的精准监控,从而大幅减少报警数量。


同环比监控的落地需要一定的技术门槛和一定的业务体量,目前并非大部分公司监控系统的标配,且据笔者所知,误报率也是很多公司无法解决的硬伤。据我们落地的经验看,误报有如下来源,算法自身的有效性,对于节假日的处理,对于监控系统的数据缺失、数据不完整等的容错等。


Code Review

前人埋坑,后人挖坑。在解决存量问题的情况下,不对增量问题进行控制,那报警优化,势必会进入螺旋式缓慢上升的过程,这对于报警优化这类项目来说,无疑是致命的。通过对新增监控的 Code Review,可以让团队成员快速达成一致认知,从而避免监控配置出现千人千面的情况出现。


沉淀标准和最佳实践

仅仅做 Code Review 还远远不够,一堆人开会,面对一行监控配置,大眼瞪小眼,对不对,为什么不对,怎么做更好?大家没有一个标准,进而会浪费很多时间来进行不断的讨论。这时候,如果有一个标准,告诉大家什么是好,那么就有了评价标准,很多事情就比较容易做了。标准本身也是需要迭代和进步的,因此大家并不需要担心说我的标准不够完美。基于标准,再给出一些最佳的监控时间,那执行起来,就更加容易了。


以机器监控为例进行说明,机器监控必须覆盖如下的监控指标,且阈值设定也给出了最佳实践,具体如下:


  • CPU_IDLE < 10

  • MEM_USED_PERCENT > 90

  • NET_MAX_NIC_INOUT_PERCENT > 80 (网卡入口/出口流量最大使用率)

  • CPU_SERVER_LOADAVG_5 > 15

  • DISK_MAX_PARTITION_USED_PERCENT > 95 (磁盘各个分区最大使用率)

  • DISK_TOTAL_WRITE_KB(可选项)

  • DISK_TOTAL_READ_KB(可选项)

  • CPU_WAIT_IO(可选项)

  • DISK_TOTAL_IO_UTIL(可选项)

  • NET_TCP_CURR_ESTAB(可选项)

  • NET_TCP_RETRANS(可选项)


彻底解决问题不等于自动处理问题

举两个例子,大家来分析一下这个问题是否得到彻底解决:


  • 如果一个模块经常崩掉,那么我们可以通过添加一个定时拉起脚本来解决该问题。那这个模块崩掉的问题解决了吗?其实并没有,你增加一个拉起脚本,只是说自己不用上机器去处理了而已,但是模块为什么经常崩掉这个问题,却并没有人去关注,更别提彻底解决了。

  • 如果一个机器经常出现 CPU_IDLE 报警,那么我们可以将现在的监控策略进行调整,比如说,以前 5min 内出现 5 次就报警,现在可以调整为 10min 内出现 20 次再报警,或者直接删除这个报警策略,或者将报警短信调整为报警邮件,或者各种类似的手段。但这个机器为什么出现 CPU_IDLE 报警,却并没有人去关注,更别提解决了。


通过上面两个例子,大家就理解,自动化处理问题不等于解决问题,掩耳盗铃也不等于解决问题,什么叫做解决问题,只有是找到问题的根本原因,并消灭之,才能确保彻底解决问题,轻易不会再次发生。还是上面自动拉起的例子,如果仔细分析后,发现是内存泄露导致的进程频繁崩掉,或者是程序 bug 导致的 coredump,那么解决掉这些问题,就能够彻底避免了。


如何解决团队内部的值班排斥情绪

每个运维团队早晚都会面对团队高工对值班工作的排斥,这也是人之常情。辛辛苦苦干了几年了,还需要值班,老婆孩子各种抱怨,有时候身体状况也不允许了,都不容易。不同的团队,解决方式不同,但有些解决方案,会让人觉得,你自己都不想值班,还天天给我们打鸡血说值班重要。更严重一些的,会让团队成员感受到不公平,凭什么他可以不值班,下次是不是我们大家也可以找同样的理由呢。


笔者的团队是这样明确说明的:


  • 保证值班人员数量不低于四人,如果短时间内低于四人,那么就需要将二线工程师短暂加入一线值班工作中,为期不超过三个月

  • 对于希望退出值班列表的中级工程师,给三个月不值班时间,如果能将目前的报警短信数量优化 20%-50%,则可以退出值班序列,但如果情况反弹,则需要重回值班工作

  • 团队达到一定级别的工程师,就可以转二线,不参与日常值班工作,仅接收核心报警,且对核心报警的有效性负责,若服务故障核心报警未发出,则每次罚款两百

  • 团队负责人不参与值班工作,但需要对单日报警数量负责,如果当周的日报警数量大于要求值,则每次罚款两百元。如果团队成员数量低于四人时,则需要加入值班列表


写在最后

在团队的报警量有了明显减少后,就需要对报警的准确性和召回率进行要求了,从而才能持续的进行报警优化工作。所谓的准确性,也就是有报警必有损,而召回率呢,则是有损必有报警。


最后,祝愿大家都不在因为值班工作而苦恼!


2019 年 8 月 31 日 09:0051569

评论 11 条评论

发布
用户头像
请问 [报警周期优化,避免瞬报] 小节中的 UI 图是什么工具呀?
2020 年 07 月 03 日 15:10
回复
用户头像
个人体会,希望能帮助大家~。
1、报警类,可以分为灰色报警、黄色报警(重要)、红色报警(高危);如使用zabbix;
2、每类报警单独一个报警群,黄色、15分钟必须有SRE回复,红色必须10分钟内回复;后台埋点使用自动化标记统计 报警与回复时间差,超期没有人员回复跟进,直接自动电话通知相关人员,在自动电话后5分钟未回复 处理中,那么直接后台记录超时;每日、周统计按产品线、或人员 统计总报警数、及超时数、进行考核。可以使用某钉的api接口二次开发实现用户是否恢复记录,及自动电话通知。
3、有些异常类,报警后 + 自愈自动处理。 或 巡检类 + 自愈自动处理。
所有报警类消息,及 回复记录 全部自动搜集入库,如回复信息 ,进行分类 ,如:更新,cpu 、内存、故障、系统bug等 ,在一个报警时候,通过消息中心发到相关群里,然后后面加上最近 1天、3 天、7天出现次数; 及 之前此类报警的 人员回复的信息数据展示,如 之前人员回复 更新 60%, 内存30%; 推荐 最高值操作。
4、报警类的回复统计,进行分类后查看每日、周 的排名情况 ,若是更新类报警较多,那么直接在每次更新时候,通过屏蔽消息通道接口 屏蔽此类更新相关的报警(屏蔽5分钟、10分钟自定),这样更新时候 就不报警到 相关报警群里了,但是 监控工具如zabbix还要继续展示出来。减少了更新导致的报警;
5、因为自愈、自动处理,给隐瞒了部分问题。
”如果一个机器经常出现 CPU_IDLE 报警,那么我们可以将现在的监控策略进行调整,比如说,以前 5min 内出现 5 次就报警,现在可以调整为 10min 内出现 20 次再报警,或者直接删除这个报警策略,或者将报警短信调整为报警邮件,或者各种类似的手段。但这个机器为什么出现 CPU_IDLE 报警,却并没有人去关注,更别提解决了“
每日、周统计 自愈处理的名称、次数; 按人员、 部门业务线 进行维度统计,某个自愈较多的,就要优化程序或其他问题,来减少自愈次数;某个机器突然出现同类报警数增多,有可能就有问题的预兆,报警类较多,直接有报警仪表盘展示各类报警曲线,通过曲线也发现问题。~~ 后期报警少了后,再返回来跟进为啥能引起自愈的问题,如磁盘报警一直报警就自动处理,那么某个时间自愈较多了是否代码debug日志了或者 有异常了导致日志多,导致频繁清理?
占焦哥的平台,说下个人体会,希望能帮助大家~~
展开
2020 年 01 月 11 日 22:57
回复
用户头像
报警优化的统计,应该仅统计短信和电话的报警,需要和邮件类的区分出来
2020 年 01 月 06 日 18:31
回复
用户头像
报警值班和报警升级中,常见的问题是,大家担心值班同学没有响应,而报警升级又需要一定的时间,导致一部分报警没人处理。这个担心和顾虑,在目前基于电话作为报警通告的方式下,其实就不用太过担心。电话和短信不同,短信如果未响应,可能是忘记了,也可能真是没有收到,这个不好判断,需要值班人员手工服务认领短信。而电话就不一样了,打通就代表值班人员响应了,没有打通,就表示值班人员没有响应,这是可以立即升级到备份人员处,从而将报警升级的时延彻底取消。
2019 年 12 月 23 日 15:17
回复
用户头像
报警仪表盘,持续优化 TOP-3 的报警。 这一段应该调整为数据分析和数据记录,并且位置放在最前面,任何的优化工作,都应该是以数据分析为基础和前提的,用数据说话!
2019 年 11 月 25 日 10:16
回复
用户头像
CloudFlare 团队使用 jiralerts 实现 JIRA 工单系统与 Alertmanager 的集成。
2019 年 09 月 23 日 16:14
回复
用户头像
Actionable alerts are the only alerts
2019 年 09 月 05 日 10:34
回复
赞同!最近在做监控,基本也是遵循这条原则:需要处理的告警才发出来,发出来的告警必须得到处理。
2019 年 09 月 09 日 15:08
回复
用户头像
感谢分享,不过有点疑问:“例如计算任务要求磁盘至少有 100GB 以上空间,以供存放临时文件,那这个时候,监控策略就可以调整为:磁盘剩余空间小于 5% 报警且磁盘剩余空间绝对值小于 100GB 报警“,
这里的5%是做什么用的?理解是至少100,那条件是且,5%如果小于100,比如等于80,那在80-100区间因为且条件不会报警,但是计算任务要求至少100,这时候应该会出问题?
求解,感谢。
2019 年 09 月 02 日 10:14
回复
笔误,已经联系编辑帮忙修改了。
应该是或而不是且。
且的话,本质上就是100G报警了,和5%没关系
或的话,就可以兼顾大小磁盘规格了,以10TB和1TB为例来讲,10TB的5%是500G,前者5%的监控条件即可满足要求。1TB的5%是50G,前者5%的监控条件就无法满足,但100G可以搞定。这样就不需要产生多条监控策略来维护了。
2019 年 09 月 02 日 11:27
回复
没有更多了
发现更多内容

年中面试经历:美团2面+字节3面+阿里4面+腾讯Java面经,终入字节

Java 程序员 架构 面试

双非渣硕,开发两年,苦刷算法47天,四面字节斩获offer

Java 程序员 架构 面试 算法

🌏【架构师指南】分布式技术知识点总结(中)

浩宇天尚

分布式架构 架构师技能 分布式技术 6月日更

万字长文详解HiveSQL执行计划

五分钟学大数据

sql 大数据 hive Hive SQL

阿里P8大佬码出25大后端面试指南,2000道面试题解析助力金九银十

Crud的程序员

Java spring 编程 架构

面试官问我:如何减少客户对交付成果的质疑

华为云开发者社区

Scrum 敏捷开发 项目 用户故事 研发

2021斩获45K月薪的Spring全家桶:文档+面试题+学习笔记+思维导图

Crud的程序员

Java spring springboot SpringCloud

K8S调试利器:telepresence2使用文档

互联网架构师小马

联邦学习—金融数据壁垒和隐私保护的解决之道

索信达控股

大数据 金融科技 联邦学习 金融 数据隐私

阿里P8架构师(花名:霍州)Java程序性能优化“学习日记”

Java架构追梦

Java 阿里巴巴 架构 面试 性能优化

云小课 | 华为云KYON之ELB混合负载均衡

华为云开发者社区

负载均衡 华为云 云网络 KYON企业级云网络 弹性负载均衡ELB

和12岁小同志搞创客开发:设计一款亮度可调节灯

不脱发的程序猿

DIY pwm 创客开发

最新阿里+头条+腾讯大厂Android笔试真题,附详细答案

欢喜学安卓

android 程序员 面试 移动开发

如何基于MindSpore实现万亿级参数模型算法?

华为云开发者社区

算法 mindspore 万亿级参数 大模型

有状态应用如何在Kubernetes平台上快速迁移和重建

焱融科技

云计算 Kubernetes 容器 云原生 高性能

Python——默认字典 (defaultdict)

在即

6月日更

继BAT之后,又一头部厂商开始构建低代码生态!=

优秀

低代码

Vue-3-生命周期管理

Python研究所

Vue 大前端 签约计划

最新大厂Android校招面试经验汇总,看完没有不懂的

欢喜学安卓

android 程序员 面试 移动开发

在云原生场景下构建企业级存储方案

青云技术社区

云原生

在windows上用Nginx做正向代理

Python研究所

网络 Proxy 正向代理

卧薪尝胆30天!啃透京东大牛的高并发设计进阶手册,终获P7意向书

Java 程序员 架构 面试 高并发

奇亚节点分币系统搭建,Bzz节点分币APP搭建

13823153121

中国政府大数据市场,我们又是第一

浪潮云

云计算

冷门科普类自媒体如何才能脱颖而出

石头IT视角

使用 VideoToolbox 探索低延迟视频编码 | WWDC 演讲实录

网易云信

低延时

澳鹏Appen:用高质量的训练数据,赋能更好的智能驾驶

澳鹏Appen

人工智能 自动驾驶 训练数据

基于 Kubesphere 的 Nebula Graph 多云架构管理实践

青云技术社区

KubeSphere

jenkins-01 | 安装

Python研究所

持续集成 jenkins CI/CD

接口全面重构TypeScript ,让uni-app 具备出色的基础音视频能力

ZEGO即构

typescript uni-app 音视频

高可用 | Xenon:后 MHA 时代的选择

青云技术社区

摆脱无效报警?十年运维监控报警优化经验总结_运维_焦振清_InfoQ精选文章