【技术】聊聊告警

作者: | 更新日期:

今天,tiankonguse 终于决定修复这个问题了。修复完了,坐下来聊聊告警。

本文首发于公众号:天空的代码世界,微信号:tiankonguse
原文地址:https://mp.weixin.qq.com/s/5nKfGjbtpzPxHgYEh9jHVg

一、背景

大家知道,tiankonguse 是一个IT/计算机/互联网公司的一个技术开发人员。
之前曾分享过一系列技术文章(文章最后点击原文查看),其中介绍过《UNION系统的运营与运维》。
那篇文章讲的是 UNION 数据聚合缓存系统成长起来后,进行的运营优化。

其中面对几千个接入的业务,UNIOIN 系统做了自己的监控模块,从而做到了自动监控每个业务的访问情况,还可以做到异常告警。
自然,这个告警模块也是 tiankonguse 使用 Python 脚本 加 简单的 mysql 数据库实现的。
快速上线后,得到的好处是无数次提前帮业务发现问题。
然而也面临一个问题:告警持续发生时,每分钟就会收到一条告警,从而造成告警骚扰。

之前的两年时间内,都是通过手动调整告警阈值来处理问题的。
一旦短时间内有事没看到告警,微信消息就是99+了。

今天,tiankonguse 终于决定修复这个问题了。
修复完了,坐下来聊聊告警。

二、关键指标

开发一个服务,如果关键的指标没有上报,那就谈不上监控了。
常见的指标有请求量、失败量、平均耗时等,其他指标可以根据业务自身的特点来提取上报。

常见指标大家都会上报,业务自身相关的指标则经常被忘记上报,这个大家一定要留意。
比如突然有一天发现服务失败,想看具体是哪个模块失败的,结果发现相关模块没有上报,那就比较被动了。

对于通信服务,一般分为 上层来的请求 和 向下的请求。
上层来的请求监控,称为被调监控。向下请求的监控,称为主调监控。
通过被调监控,能够知道我们的服务出问题了。通过主调监控,能够知道是由于依赖的某个服务出问题才导致我们出问题。

不过到底该上报到哪个程度,这个也不好衡量。上面提到的主调监控和被调监控至少是要上报的。
一般是系统越大,上报的监控越多;系统越复杂,上报的监控越精细。

这里的目标是如果发生异常,能够快速发现问题,并解决问题。
具体上报指标,只能靠系统的负责人自己去思考了。

三、告警阈值

各种关键指标上报了,对于某些监控系统,还需要手动设置各维度的监控阈值才能真正有效的发出告警。
否则这个只是一个数据查询系统,并没有监控告警的效果。

没有告警的弊端也很容易推测出来:我们被投诉之后,去监控系统一看,确实发生异常了,而且持续好久了。
所以,告警的目的是出问题了,能够马上主动发现问题,甚至是被投诉之前就修复问题了。

如果一个系统上报的指标多了,经常会发生没有设置告警阈值的情况。
尤其是对于后来新增的监控指标,尤其要注意是否设置监控阈值。

这里有一个逻辑:上报的目的是为了快速发现问题,所以所有上报都应该尽量设置监控阈值。
否则还是会发生这样的场景:一个问题发生了,我们没有及时告警出来,后来发现上报了,但是没有设置告警阈值。
这样的场景,周围的小伙伴包括 tiankonguse 都遇到过,代价相当惨痛。

所以很多上报监控系统,都默认设置基础指标的监控阈值。
tiankonguse 做的 这个实时监控告警系统也支持有策略的给每个调用方设置监控阈值,当然目前的策略还比较挫,但有至少比没有好嘛。

四、告警处理

告警的目的是发现问题,那发现了问题自然要及时解决问题。
如果发现告警不合理(数据合理,阈值不合理),那就应该及时的调整告警阈值。

如果确实有问题,解决又需要一段时间,告警还在持续不断的发送,那可以临时的屏蔽告警。
逻辑是这样:我们已经知道问题存在了,告警再不断的发送就是骚扰我们。既然我们知道问题存在了,这个告警就没有意义了,因为告警的目的已经不满足了。

当然,如果短时间内就修复问题,那是否屏蔽都可以,如果长时间内才能修复问题,屏蔽就很有必要了。
屏蔽的代价也很容易想到:忘记取消屏蔽。
这个处理问题的流程如果规范化,其实还是可以避免的。
另外,系统支持指定时间段临时屏蔽,那就更好了。

五、告警收敛

告警最令人头疼的就是同样的告警,收到无数条。
前几条告警可以起到发现问题的作用,后面的告警只能起到信息骚扰的作用。
所以告警收敛是每个告警系统都要支持的功能。

告警收敛的算法很多,最简单的就是固定周期收敛,比如五分钟最多发一条。
当然,tiankonguse思考之后,采用了另外一个策略:指数周期收敛。

告警的目的是发现问题,而问题刚发生的时候,有可能没看到第一条告警。
所以告警初期,还需要多发送几条告警(问题急迫,告警频率较高)。
告警后期,如果负责人没发现告警,发送再多也没用,所以间隔很久发送一条就行了。
当然,这里面还有告警指数区间的增长算法与恢复算法,就不多说了。

对于复杂业务,也会遇到发生问题时,发出大量的不同的告警。
这种不同告警的收敛也是有必要的,做最初版本的时候我就考虑了,大家也要考虑一下。

六、阈值的合理性

一般情况下,告警都是设置的固定值,这就引入一系列问题。

比如目前的互联网业务,白天的量一般很大,后半夜的量很小。
往往设置一个波动告警,白天不满足,但是后半夜满足了。
这就导致我们只能调大波动告警的阈值,但是太大了白天异常了又发现不了了。
针对这种情况,比较有效的方法是按时间区间分别设置告警阈值。
波动告警和最大值最小值都可以按这个策略配置。

除了白天与黑夜的区别外,有些业务会在固定的时间点做活动,比如推tips。
这些也会临时出现异常的波动情况,这种也需要按照时间区间做特殊配置。

当然,针对特殊的趋势或者波动,靠人工去找特征避免不了漏掉特征或者特征变化。
业界已经有很多人开始使用机器学习进行智能识别特征、智能收敛告警、智能发送告警。
后面简单的告警系统也不简单了,而是AI告警系统了。

七、最后

简单的聊了聊告警系统,往深处思考发现这里面的学问还挺多的,你怎么看待这个问题呢?

-EOF-

本文首发于公众号:天空的代码世界,微信号:tiankonguse
原文地址:https://mp.weixin.qq.com/s/5nKfGjbtpzPxHgYEh9jHVg

点击查看评论

关注公众号,接收最新消息

关注小密圈,学习各种算法

tiankonguse +
穿越