【技术】聊聊告警

栏目: 服务器 · 发布时间: 6年前

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

一、背景

大家知道,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


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Numerical Linear Algebra

Numerical Linear Algebra

Lloyd N. Trefethen、David Bau III / SIAM: Society for Industrial and Applied Mathematics / 1997-06-01 / USD 61.00

Numerical Linear Algebra is a concise, insightful, and elegant introduction to the field of numerical linear algebra.一起来看看 《Numerical Linear Algebra》 这本书的介绍吧!

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具