我在百度对抗报警风暴（一）

本文做者：AIOps智能运维

做者简介

运小博    百度高级研发工程师

从事有关运维数据分析相关的工做，负责异常检测系统和报警收敛等工做，重点关注时序数据分析、故障诊断等相关领域技术。

干货概览

百度监控系统Argus保障了百度内外产品服务的高可用，《我在百度对抗报警风暴》系列文章将会介绍百度高级研发工程师运小博在实践中如何运用报警合并、机房故障分析、报警关注度分析、值班与逐级通告平台和报警回调技术等对抗报警风暴。本文将主要介绍报警风暴造成的缘由和报警合并策略中简单的报警合并策略。

 

Argus名字含义：希腊语“Argus”的意思是“明亮的”、“明察秋毫的”，在古代希腊神话里面的巨人Argus长有一百只眼睛，所以能够观察到全部方向的事物与动静；后世以此来比喻机警、机灵的护卫，咱们但愿百度监控系统可以如巨人Argus全面洞察异常并报警，故命名为Argus。

报警风暴

百度监控系统（Argus）是保障百度内外产品服务高可用的利器。小到机器的磁盘是否打满、虚拟机实例上的进程或端口是否存活，大到产品的流量是否稳定、机房网络是否联通，尽在Argus的掌握之中。

两年前，百度每个运维工程师都被报警风暴所困扰。白天，百度的运维工程师们平均11分钟就会接收一次短信报警，在夜间则是平均14分钟一次，而实际数据统计发现，有效短信报警占比不到15%。所以短信报警的冗余度是很是高的，已经形成了报警风暴。

通过分析，报警风暴的造成主要有这么几个缘由：

报警重复度>58%

分析其缘由，首先报警策略执行周期计算，所以会持续产生重复报警，部分策略甚至会致使持续报警达1小时以上。更严重的情形是，一次故障可能引起多个相关策略报警。好比一台机器死机，首先机器层面报警，而后实例层面报警，接着服务上游也可能会报警。

报警关注度不足

咱们把报警发送后有实际处理的比例做为报警关注度的度量指标，发现实际关注度并不高，而在夜间短信报警关注率则低至25%。但事实上夜间短信报警的级别通常都是比较高的。这就意味着不少报警策略的发送方式和实际的报警等级已经相违背了。这是由于报警的关注度随着业务发展发生变化，可是这些关注度的变化没有及时的在报警系统中修改，致使已经变得不那么重要紧急的报警，却还在以短信的形式给值班工程师发送报警。

报警接收人冗余

每一个报警策略平均有3个接收人，部分报警甚至超过了7个。报警策略的接收人每每会填写了运维团队中的全部人，但实际值班人只有一我的，你们按周期轮转。所以，对于一个特定的报警，大部分同窗是不须要即时关注的。

报警有效性不足

超过88%以上的报警都是单实例报警，40%以上只须要简单的处理便可恢复，好比磁盘打满或者内存泄露等。所以咱们在Argus中增长了自愈机制，自愈成功后，报警也就无需继续发送了。

针对上面的这些问题，咱们在设计Argus时使用了智能报警合并策略、基于报警数据挖掘的机房故障分析、报警关注度分析、值班与逐级通告平台和报警回调技术等。Argus的功能逐渐完善，并把周级报警短信总量削减了85%。

 

报警合并策略

报警合并对不少作监控的同窗来讲并不陌生，大部分介绍报警收敛的文章都提到了这个过程，但大多数说起的报警合并都是将某个时间窗口内的报警简单的合并成为一条，此举对削减报警数量当然有效，但不利于值班工程师进行故障诊断。咱们但愿把若干描述同一故障的报警合并在一块儿，让值班工程师能够快速捕捉到故障本质，甚至故障根因，而并不是一味的削减报警量。

在本文中，咱们先介绍一个合并来源于相同报警策略或者相同模块的重复报警的策略，下一篇文章中将讨论如何合并跨模块、跨策略的报警和一个消除机房网络故障期间报警风暴的方法，这一方法也能够用来检测机房的网络故障。

 

简单的报警合并策略

最简单的报警合并方法能够基于报警策略的天然属性，包含策略名或者部署维度等。百度的生产系统使用了虚拟化技术混布各项服务，所以部署的逻辑维度包含了实例、模块、集群等层次，物理维度包含机器和机房层次。一个层次同时刻的报警，大多数都存在着必定联系，于是能够将这些报警合并。举一个实际的例子，A模块在bj机房部署有100个实例，统一为每一个实例配置了端口存活报警策略rule1，某个时刻这个策略在0.A.bj（A模块在bj机房的0号实例）和1.A.bj（A模块在bj机房的1号实例）上都报警了。这两个报警属于同一个模块的同一个策略，于是能够合并在一块儿，便于值班工程师了解总体状况。最终发送的报警样式以下：

 

{A:instance:rule1}{整体异常实例比例:2%}{异常(2):0.A.bj,1.A.bj}{05-02 16:49:36 - 16:54:09} {http://dwz.cn/… }

简单介绍一下这条报警的意思：

◤A:instance:rule1表明的是报警策略rule1属于A模块，而且是实例级别的报警；

◤整体异常实例比例是使用异常实例数量除以实例总数量计算出来的；

◤0.A.bj和1.A.bj属于A服务下的两个异常实例，异常时间段是05-02 16:49:36 到16:54:09；

◤后面有个短链，用户能够打开短链查看更详细的报警内容。

当合并的内容过多时，咱们将最主要的报警或者报警的总结汇总到短信内容里面，具体的每一条细节报警、报警起始结束时间、报警持续时间、报警配置内容等细节信息都会在短链的页面中展现。

了解了报警合并的策略，接下来介绍一下实际合并的机制。一个报警产生之后，咱们先把这个报警插入一个发送等待队列而非当即发送。每个报警策略都有一个在等待队列里的最长存留时间，换言之，是这条报警能够容忍的最长延迟发送时间。报警产生后先插入等待队列里面去，在队列里等进行延迟计时，当达到了可以容忍的延迟时间之后，咱们在等待队列中找到能够和该报警一块儿合并发送的报警，根据实际的合并维度渲染成不一样的报警短信内容，而后合并成一条报警短信发送。在下面的例子里，A，B，C表明了3个不一样的模块，A模块上配置了两条报警策略分别为rule1，rule2，B模块上配置了rule3，C模块上配置了rule4，红色的报警A:rule1即将到达最长存留时间，按照合并策略，黄色的报警能够一块儿合并为一条发送，这样实际的报警信息中包含了三条报警。

总结

在今天的故事里，咱们从多个角度分析了报警风暴的问题，并重点介绍了报警合并技术中简单的报警合并策略。以后的故事里咱们会继续介绍关联规则的报警合并策略、基于报警数据挖掘的机房故障分析、报警关注度分析、值班与逐级通告平台和报警回调技术等，请持续关注AIOps智能运维！

若您有其余疑问或者想进一步了解百度监控系统Argus，欢迎留言或评论！

原文连接地址：https://developer.baidu.com/topic/show/290328