智能运维 | 我在百度对抗报警风暴（上）

百度智能云

于 2018-08-15 20:27:22 发布

阅读量265

点赞数

百度云Noah智能监控平台保障了百度内外产品服务的高可用，并对百度的报警进行了有效治理，使得百度的报警量下降了九成以上。《我在百度对抗报警风暴》系列文章将会介绍运小博如何在实践中运用智能报警合并、故障维度分析、报警关注度分析、轮值与逐级通告和报警回调等技术对抗报警风暴的故事。

本文是该系列文章的第一篇，将主要介绍报警风暴形成的原因和智能报警合并中的简单合并策略。

报警风暴

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

三年前，百度每一个运维工程师都被报警风暴所困扰。白天，百度的运维工程师们平均十几分钟就会收到一次短信报警，在夜间也不例外。但通过报警数据统计分析发现，有效短信报警占比不到15%。因此短信报警的冗余度是非常高的，已经造成了无效报警风暴。

经过分析，报警风暴的形成主要有如下几个原因：

报警重复度高

分析其原因，首先报警策略执行周期计算不精细，因此会持续产生重复报警，部分策略甚至会导致持续报警达小时级。更严重的情形是，一次故障可能引发多个相关策略报警。比如一台机器死机，首先机器层面报警，然后实例层面报警，接着服务上游也可能会报警。

报警关注度不足

我们把报警发送后有实际处理的比例作为报警关注度的度量指标，发现实际关注度并不高，而在夜间短信报警关注率则两成左右。但事实上夜间短信报警的级别一般都是比较高的。这就意味着很多报警策略的发送方式和实际的报警等级已经相违背了。这是因为报警的关注度随着业务发展发生变化，但是这些关注度的变化没有及时的在报警系统中修改，导致已经变得不那么重要紧急的报警，却还在以短信的形式给值班工程师发送报警。

报警接收人冗余

每个报警策略平均有3-4个接收人，部分报警甚至超过了10个。监控报警策略的接收人往往会填写某个运维团队中的所有人，但实际值班或在处理问题的只有一个人，大家按周期轮转。因此，对于一个特定的报警，大部分同学是不需要及时关注的。

报警有效性不足

单实例报警的频繁发生也是造成困扰的主要因素，我们研究发现，实际报警中有近九成的报警是单实例报警，这里面有接近一半的异常只需要简单的处理即可恢复，比如磁盘打满或者内存泄露等。因此我们在Noah监控中增加了自愈机制，自愈成功后，报警也就无需继续发送了。

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

报警合并策略

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

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

简单的报警合并策略

最简单的报警合并方法可以基于报警策略的自然属性，包含策略名或者部署维度等。百度的生产系统使用了虚拟化技术混布各项服务，因此部署的逻辑维度包含了实例、模块、集群等层次，物理维度包含机器和机房等层次。一个层次同时刻的报警，大多数都存在着一定联系，因而可以将这些报警合并。举一个实际的例子，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://noah.xxx/… }

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

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