微博广告系统全景运维大法( 六 ) _微博

运维人员需要关注所有部分，从系统到服务、接口等等，维度很多，一旦有问题，各种策略都会触发报警，报警数量多到一定程度，基本上等于没有报警。
②重复告警率高
告警策略一般会周期性执行，一直到告警条件不被满足，如果服务一直不恢复，就会重复报下去，另外，同一个故障也可能引发不同层次的告警。
比如，我们有一个业务线叫超粉，会有 360 台服务器，流量高峰时 360 台服务器会同时发送告警，这种告警的重复率很高。
③告警有效性不足
很多时候，网络抖动、拥堵、负载暂时过高或者变更等原因，会触发报警，但这类报警要么不再重现，要么可以自愈。
比如一个硬盘在接近 80% 的时候开始告警了，你让它告吗？好像得告，但似乎不告也可以。
④告警模式粗放
无论是否重要、优先级如何，告警都通过邮件、短信、App PUSH 发送到接收人，就像暴风一样袭击着接收人，接收人没有办法从中获取到有效的信息，经常会让真正重要的告警淹没在一大堆普通告警中。

文章插图
针对这些问题，我们采取了以下措施：
①抖动收敛
对于这种大规模服务器的维护，抖动是非常常见的现象。网络抖一抖，整个服务单元就会向你告警。
针对这种抖动，我们增加了一些策略，抖动的时候会前后比较，监测重复性，看看是不是具备告警的意义，通过增加告警策略这种方式来进行收敛。
比如说流量突增的时候，需要查看是不是同单元都出现了这个情况。
②告警的分类和分级
详细定义告警级别，发送优先级、升级策略等，可有效减少粗放模式下告警接收量。比如，一些低优先等级的告警会让它告，处理的级别会低一点。
③同类合并
同一个原因可能会触发一个服务池里面的所有实例都报警，比如同时无法连接数据库，其实只需要报一次即可。
④变更忽略
我们的好多变更都是在 Kunkka 平台上操作的，开发有时候会选中一个通知，现在是变更，告警请忽略。
以上措施能解决告警问题中 80% 的问题，现在大家都在朝着更高级的方向发展，我们也简单做了一些探索。
在原有告警数据流情况下引入了工具 SkyLine ，这个工具包含了多种算法，在异常检测环节中，能够通过它内置的算法将我们传入的数据自动去抖动，提供平滑的数据，等你再拿到这个数据时就不需要再检测是不是告警。
这个工具避免了人工操作，通过 Skyline 将数据进行平滑，提供一份准确的数据，我们只需要通过这份数据，进行规则判断，决定是否需要告警就好了，减少了对数据准确性判断的复杂过程。
接着是根因分析部分，随着监控的覆盖面越来越广，监控精确性越来越高。
等故障出现的时候，开发人员就会去翻监控图，去查看大概是哪些原因导致了故障。
随着 Dashboard 越来越多，即便是经验非常丰富的工作人员也很难快速地定位到原因会出现哪个方面、该去看哪张监控图。
出现流量突增的情况时， Skyline 会通过内部的算法 Luminosity 寻找相似的情况，查看相同的时间内是否有其他地方出现流量异常，并将根源问题展示在 TOPN 上。
这样就能够快速查看在故障出现的前后哪些业务也出现了流量变化，方便对故障原因进行分析和定位。