我在百度对抗报警风暴（一）_文化 & 方法_运小博



 写点什么

百度监控系统 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 即将到达最长存留时间，按照合并策略，黄色的报警可以一起合并为一条发送，这样实际的报警信息中包含了三条报警。