第八十二期:掌握这些监控报警优化技巧，百万年薪不在话下！
运维工程师面试者第一个问题是：需要值班吗?笔者自己也曾经历过月入十万的时期，在那个时候，数个系统同时发布下一代版本，而老系统还需要过渡很长时间，工作量直接翻倍。
作者：焦振清
运维工程师面试者第一个问题是：需要值班吗?笔者自己也曾经历过月入十万的时期，在那个时候，数个系统同时发布下一代版本，而老系统还需要过渡很长时间，工作量直接翻倍。
图片来自 Pexels
大家只能勉强应付一线运维工作，团队成员开始陆续离职，而新人又无法在短时间内上手，整体情况不断恶化，持续半年左右才缓过劲来。
下面两张截图是我挑选的两个团队一周报警数的对比图，前者的单日报警量最高是 55348 条，后者单日的报警量最高为 34 条，两者相差 1600 倍，而前者才是国内很多互联网运维团队的真实写照。
在管理大规模集群的情况下，究竟有多少报警量才是合理的呢?
Google SRE 每周十条故障报警
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 报警。
⑩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%，则可以退出值班序列，但如果情况反弹，则需要重回值班工作。
团队达到一定级别的工程师，就可以转二线，不参与日常值班工作，仅接收核心报警，且对核心报警的有效性负责，若服务故障核心报警未发出，则每次罚款两百。
团队负责人不参与值班工作，但需要对单日报警数量负责，如果当周的日报警数量大于要求值，则每次罚款两百元。如果团队成员数量低于四人时，则需要加入值班列表。
写在最后
在团队的报警量有了明显减少后，就需要对报警的准确性和召回率进行要求了，从而才能持续的进行报警优化工作。
所谓的准确性，也就是有报警必有损，而召回率呢，则是有损必有报警。
阅读目录（置顶)(长期更新计算机领域知识）
阅读目录（置顶)(长期更新计算机领域知识）
阅读目录（置顶)(长期科技领域知识）
歌谣带你看java面试题
第八十二期:掌握这些监控报警优化技巧，百万年薪不在话下！相关推荐
- ULAM公链第八十二期工作总结
能用实力解决的,就别想着去碰运气,如果不能运气爆棚,那就努力做到实力过人. 2022年08月01日-2022年09月01日关于ULAM这期工作汇报,我们通过技术板块,推广板块,运营板块进行汇总. UL ...
- 第八十四节，css布局小技巧及font-awesome图标使用
css布局小技巧及font-awesome图标使用 图片鼠标放上去遮罩效果,显示文字 当鼠标放上去时 /*最外层div*/ .a{width: 384px;height: 240px;backgrou ...
- DockOne微信分享（八十四）：Docker在B站的实施之路
本文讲的是DockOne微信分享(八十四):Docker在B站的实施之路[编者的话]B站一直在关注Docker的发展,去年成功在核心SLB(Tengine)集群上实施了Docker.今年我们对比了各种 ...
- 【知云】第十二期：处于风口浪尖上的直播视频网站，如何快速部署直播监管？...
摘要:广电总局要求视频直播网站的视频内容保存两个月以上,针对于这样的要求,视频直播网站有没有简单快捷的部署方式呢?本文中阿里云布道师爅冉将与大家分享阿里云直播监管冷存储解决方案. 想要看视频版?请点击 ...
- 平安科技移动开发二队技术周报（第十二期）
平安科技移动开发二队技术周报(第十二期) @author ASCE1885的 Github 简书 微博 CSDN 业界新闻 1)无人机将带领程序员进入一个新开发者时代 将无人机和不同行业结合起来想象空 ...
- 达芬奇密码 第八十五章
达芬奇密码 第八十五章[@more@] 第八十五章 "你们寻找的圆球,本应在这位骑士的墓里." 圣殿教堂里的骑土石像无一例外地仰面躺着,头靠在呈长方形的石枕上.索菲只觉得一阵透心凉 ...
- zabbix监控系统下——zabbix实现数据库监控、对JMX的支持、server和agent的关系、zabbix监控报警平台
目录 五.zabbix实现数据库监控 1.在agent端设置 2.在浏览器前端设置 六.zabbix对JMX(Java)应用的支持 七.server和agent的关系 1.agent端的信息采集变被动 ...
- 【浪潮之上，你我同行】云和恩墨大讲堂电子期刊第十二期
致亲爱的读者朋友们, 我们正站在一个千载难逢的时代的入口处.互联网时代的到来,给各个行业都带来了巨大的冲击,一方面,企业面临着传统经营模式不可持久的挑战,IT架构.业务模式的变革刻不容缓,另一方面,互 ...
- 鲁大师电动车智能化测评报告第十二期
鲁大师第十二期智能化电动车测评排行榜数据来源于鲁大师智慧实验室,测评的车型均为市面上主流品牌的主流车型.截止目前,鲁大师智能化电动车测评的车型高达60余种,且还在不断增加和丰富中. 1. 测评依据 鲁 ...
最新文章
- 激辩：机器究竟能否理解常识？
- R语言在直方图条（柱形）上添加计数（count）或者百分比（percent）标签
- AI Studio ： 利用Paddle框架中的极简框架识别MNIST
- Meteor的临时的存储:Session
- 彻底理解 Spring 容器和应用上下文
- [云炬创业基础笔记]第六章商业模式测试1
- 500 lines or less_堂杰支招 卫生间or阳台，洗衣机放哪更合适？
- 【深度学习】Tensorflow的基本操作
- libcurl使用easy模式阻塞卡死等问题的完美解决---超时设置
- 细说show slave status参数详解（最全）【转】
- 什么是智能门锁，智能门锁主要有哪些优点？
- python把两张图片合成一张_怎么合成图片-利用Python将两张图片合成为一张图
- 使用SINet进行伪装目标检测
- ubuntu 安装caj阅读器
- Redis key过期策略
- Cat4模块SIM7600CE介绍
- Unity Shader 常规光照模型代码整理
- URLreWriterFilter的使用
- 物联网试点炼狱阶段就此结束了吗？
- 如何查找session过期时间