【技术】聊聊告警

一、背景

大家知道，tiankonguse 是一个IT/计算机/互联网公司的一个技术开发人员。

之前曾分享过一系列技术文章（文章最后点击原文查看），其中介绍过《 UNION系统的运营与运维 》。

那篇文章讲的是 UNION 数据聚合缓存系统成长起来后，进行的运营优化。

其中面对几千个接入的业务，UNIOIN 系统做了自己的监控模块，从而做到了自动监控每个业务的访问情况，还可以做到异常告警。

自然，这个告警模块也是 tiankonguse 使用 Python 脚本 加 简单的 mysql 数据库实现的。

快速上线后，得到的好处是无数次提前帮业务发现问题。

然而也面临一个问题：告警持续发生时，每分钟就会收到一条告警，从而造成告警骚扰。

之前的两年时间内，都是通过手动调整告警阈值来处理问题的。

一旦短时间内有事没看到告警，微信消息就是99+了。

今天，tiankonguse 终于决定修复这个问题了。

修复完了，坐下来聊聊告警。

二、关键指标

开发一个服务，如果关键的指标没有上报，那就谈不上监控了。

常见的指标有请求量、失败量、平均耗时等，其他指标可以根据业务自身的特点来提取上报。

常见指标大家都会上报，业务自身相关的指标则经常被忘记上报，这个大家一定要留意。

比如突然有一天发现服务失败，想看具体是哪个模块失败的，结果发现相关模块没有上报，那就比较被动了。

对于通信服务，一般分为 上层来的请求 和 向下的请求。

上层来的请求监控，称为被调监控。向下请求的监控，称为主调监控。

通过被调监控，能够知道我们的服务出问题了。通过主调监控，能够知道是由于依赖的某个服务出问题才导致我们出问题。

不过到底该上报到哪个程度，这个也不好衡量。上面提到的主调监控和被调监控至少是要上报的。

一般是系统越大，上报的监控越多；系统越复杂，上报的监控越精细。

这里的目标是如果发生异常，能够快速发现问题，并解决问题。

具体上报指标，只能靠系统的负责人自己去思考了。

三、告警阈值

各种关键指标上报了，对于某些监控系统，还需要手动设置各维度的监控阈值才能真正有效的发出告警。

否则这个只是一个数据查询系统，并没有监控告警的效果。

没有告警的弊端也很容易推测出来：我们被投诉之后，去监控系统一看，确实发生异常了，而且持续好久了。

所以，告警的目的是出问题了，能够马上主动发现问题，甚至是被投诉之前就修复问题了。

如果一个系统上报的指标多了，经常会发生没有设置告警阈值的情况。

尤其是对于后来新增的监控指标，尤其要注意是否设置监控阈值。

这里有一个逻辑：上报的目的是为了快速发现问题，所以所有上报都应该尽量设置监控阈值。

否则还是会发生这样的场景：一个问题发生了，我们没有及时告警出来，后来发现上报了，但是没有设置告警阈值。

这样的场景，周围的小伙伴包括 tiankonguse 都遇到过，代价相当惨痛。

所以很多上报监控系统，都默认设置基础指标的监控阈值。

tiankonguse 做的 这个实时监控告警系统也支持有策略的给每个调用方设置监控阈值，当然目前的策略还比较挫，但有至少比没有好嘛。

四、告警处理

告警的目的是发现问题，那发现了问题自然要及时解决问题。

如果发现告警不合理（数据合理，阈值不合理），那就应该及时的调整告警阈值。

如果确实有问题，解决又需要一段时间，告警还在持续不断的发送，那可以临时的屏蔽告警。

逻辑是这样：我们已经知道问题存在了，告警再不断的发送就是骚扰我们。既然我们知道问题存在了，这个告警就没有意义了，因为告警的目的已经不满足了。

当然，如果短时间内就修复问题，那是否屏蔽都可以，如果长时间内才能修复问题，屏蔽就很有必要了。

屏蔽的代价也很容易想到：忘记取消屏蔽。

这个处理问题的流程如果规范化，其实还是可以避免的。

另外，系统支持指定时间段临时屏蔽，那就更好了。

五、告警收敛

告警最令人头疼的就是同样的告警，收到无数条。

前几条告警可以起到发现问题的作用，后面的告警只能起到信息骚扰的作用。

所以告警收敛是每个告警系统都要支持的功能。

告警收敛的算法很多，最简单的就是固定周期收敛，比如五分钟最多发一条。

当然，tiankonguse思考之后，采用了另外一个策略：指数周期收敛。

告警的目的是发现问题，而问题刚发生的时候，有可能没看到第一条告警。

所以告警初期，还需要多发送几条告警（问题急迫，告警频率较高）。

告警后期，如果负责人没发现告警，发送再多也没用，所以间隔很久发送一条就行了。

当然，这里面还有告警指数区间的增长算法与恢复算法，就不多说了。

对于复杂业务，也会遇到发生问题时，发出大量的不同的告警。

这种不同告警的收敛也是有必要的，做最初版本的时候我就考虑了，大家也要考虑一下。

六、阈值的合理性

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

比如目前的互联网业务，白天的量一般很大，后半夜的量很小。

往往设置一个波动告警，白天不满足，但是后半夜满足了。

这就导致我们只能调大波动告警的阈值，但是太大了白天异常了又发现不了了。

针对这种情况，比较有效的方法是按时间区间分别设置告警阈值。

波动告警和最大值最小值都可以按这个策略配置。

除了白天与黑夜的区别外，有些业务会在固定的时间点做活动，比如推tips。

这些也会临时出现异常的波动情况，这种也需要按照时间区间做特殊配置。

当然，针对特殊的趋势或者波动，靠人工去找特征避免不了漏掉特征或者特征变化。

业界已经有很多人开始使用机器学习进行智能识别特征、智能收敛告警、智能发送告警。

后面简单的告警系统也不简单了，而是AI告警系统了。

七、最后

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

-EOF-

本文首发于公众号：天空的代码世界，微信号：tiankonguse-code。

原文地址： https://mp.weixin.qq.com/s/XaUKqhoT2-UPKVopsJ4FPg