腾讯亿万量级告警是如何做到全、准、快的？(2)

多维,因为社交网络提供的业务类型、对用户的服务也是多种多样的,有QQ,有音乐,有图片、文件、微云,针对这些不同的服务场景,它其实都是多维的场景,我们就把它们按场景区分,分别统一几类通用的多维协议,然后我们的后台流处理集群可以针对每类多维监控的场景,定制流计算逻辑,按照用户使用数据的形式将多维数据做加工处理.

如果我们后台用了一个关系型数据库存储,过多的数据维度,会让在做监控可视化时,无法获得高效的查询性能.

我们怎么样解决其中的矛盾呢?如果数据的纬度特别大,随便列举一个维度大于30的案例,腾讯亿万级量所产生的监控数据绝对是“亿亿”级的.

为了解决这个问题,我们把每一块都设计成微服务化,我们用了开源的svr、kafka、Storm,再落地存储.

运营开发和运维人员其实关系一般不是特别好,如果按照以前我们的分工规则,一方提需求一方做需求.

运营开发按自己的思路做一套监控系统给运维来用,大部分运维是用得不爽,这是一个客观存在的事实,这是人性使然.

为了优化这个问题,我们微服务化的分工也是基于这种理念,运营开发更专注于对Storm逻辑的一些封装,专注于原始数据的高效加工处理,然后,告诉数据消费者(运维)有什么样的数据,在数据银行中提供了哪些数据的类型,提供了哪些丰富的接口,所有产品化的工作都是由运维来实现的.

整个架构图其实都是运营部来做的,但运营部内部又可以按照不同的功能模块孵化出各自负责工作的职责范围,基于这些职责范围我们就可以更好地相互协作,相互地分享各自的工作成果,这是为了达到快的目标,统一协议,优化我们的分工的一个架构.

准：智能监控

准,以告警举例,通常告警的产生基于阀值或算法的策略,把异常的监控数据点找出,然后系统把过去运维人员处理的异常问题的经验变成一个个自动化的工具,像自愈、收敛、根源分析这样的延伸功能特性,来达到我们对准的诉求.

如,大范围故障的场景,一个核心交换机坏了,会产生多少告警?如果所有监控点都发出告警,那这些告警对运维人员其实是骚扰的,是不准的.

但如果绝大多数的告警都不发了,就告诉运维是核心交换机故障这一条告警,这便是我们追逐的精准告警.

我们今天主要探讨一下怎么样找到根源的问题,让我们的告警变得更加智能,而不是“点”的告警.过去我们做了很多监控点,我们怎么样通过点的监控去做好“面”的告警呢?

其实做所有事情都是有一些机缘的,因为在业务上面临很大的挑战,过去我们一步一步去构建监控体系的时候,我们埋了很多监控点,当我们的业务体量一上来的时候,这些监控点就变成运维人员的负担,我们对业务逻辑监控、主机也监控、网络也监控,用户投诉过来的时候,我去查,很多点都在告警,究竟哪个点的告警最应该关注呢?

运维和研发人员的人数配比是相差巨大的,一个运维可能对应了上百号开发,我不可能要求一个运维关注到方方面面.在我们这么高可用架构的前提下是不是还应该关注一些“点”的问题呢?带着这个疑问,我们继续.

海量监控的困扰

这是一张腾讯广告其中的一个拓扑图,这张图想表达一个问题——像网一样,很乱.

当一个节点发生异常的时候,会把告警扩散到各个点,因此我们需要一个智能的监控分析的引擎,去帮我们解决这里的一些问题.

ROOT智能监控系统

腾讯的体量在中国互联网是用户最多的,QQ同时在线用户数,在2014年就已经突破2亿,创造了世界的吉尼斯记录.

2015年红包的时候甚至达到2.15亿同时在线,整个社交网络有大于十万台的服务器在支撑着这么大体量的业务,每天我们会产生4万条以上的告警,人均的告警量大于500条,有些比较极端的一天收3000条告警短信.

当告警量大于500条,你的所有问题都发现不了,上班只有看告警就什么事情别做了.

因为业务量的庞大复杂,而产生大量的告警,我们过去所有的收敛办法都是基于一个垂直监控点的收敛,但是监控点一旦多起来,点和点之间怎么收敛呢?

因此端到端的智能监控应运而生,基于业务架构,结合数据流的关系,通过时间相关性、面积权重等算法,将监控告警进行分类筛选,发掘有业务价值的告警,并直接分析出告警根源.

假设我们在这个架构图上发现了一个问题,我们的DB挂了,会层层往前推,我们的逻辑层、接入层、负载均衡,甚至到我们的用户端报上的成功率都会受到影响.

但是运维并不希望收到这N个现象告警,我们希望把DB宕机的根源告警发出来,其他告警都收敛掉.

首先,我们基于我们的业务拓扑图,根据时间的相关性,把告警都叠加在链路上,把一些不需要关注的点都过滤掉,最后得到一个经过经验分析的模型.

很简单的一个例子,变更容易引起告警,DB更容易是根源告警,越靠后的告警越容易是根源的告警,通过这个模型算出根源的问题.

降维策略

我们采用自动生成拓扑图的方法,利用社交网络事业群的通用路由组件L5、模块间服务调用监控的基础数据作为我们绘制业务拓扑图的基础数据源.

还有一个靠tcpdump抓包的方式,TCP的请求是有序的,UCP的连接也是可以加工的,虽然它发起的端口是随机的,但我们通过对数据的积累一段时间,就可以清楚地知道这个UDP服务的主调和被调的关系是什么样的.

随后,把网状的拓扑变成一条一条的访问关系链,得到这条线之后,我们开始做相对应的关联分析的逻辑.

我们把相关时间的告警叠加上来,我举一个例子,10:20到10:30分钟之间产生了这样一些业务告警,在这些模块都有发生,B这个模块产生了业务告警,E产生了发布变更告警,D这个模块产生了基础告警.

通过权重算法对这些链路进行排序,再套上模型分析,找到我们最需要关注的一条链路.

如果这里按照过去监控点的玩法,我们会产生大于10条的告警,但是我们是希望把这十条告警收敛成这个链路的告警.

其实我们现在在举例试图让大家更好地理解我们设计这个面监控的思路.

时间相关性分析

这张图是我们的系统截图,把我们的链路从横向换成纵向,有一些模块在很长一段时间内都会有一些监控的异常.

我举一个实际存在的例子,我们的服务器上装了一些Agent,不去深究这个Agent应不应该存在,它有一些挂了,挂了但是不一定影响我的服务.

在一个大的集群下每天都会有一些东西挂掉,但是又不影响,它的处理优先级很低,但它一直产生告警,因为它有监控点.

这些监控点怎么不跳出来影响系统的分析呢?

通过时间相关性的分析,长期存在的红点都是监控到异常,究竟有没有发出来被收敛掉了是监控系统自身的问题,但是全盘分析中这些监控点会被过滤掉,它的权重是很低的,这个告警是可以忽略掉的,因为它一直都存在.

通过时间相关性的分析,系统会把持续性的,跟延时等等相关的问题,都会过滤掉.

权重面积分析

过滤完没有用的告警,还是有很多告警,怎么样能够在众多的链路中找到我们最应该关注的链路呢?

面积权重的算法有一个口诀,越靠后的模块越有可能是根源的问题,相连产生的告警越可能是根源的问题.

基于这样的一个原则,我们把它变成了每条链路都可以算出一个面积值.

这样把各个功能模块介绍完之后,我们的架构基本上就可以出来了.

首先,要做这个事情,我们必须要有一些基础数据,就是我们的业务拓扑、我们的访问关系连,通过日积月累的数据整理可以得到.

当我们各个告警渠道有异常产生的时候,就开始过滤的动作,最终把我们筛选出的链路做排序,再套用我们以前遇到的一些模型、经验去分析它,最终给出根源问题.

举例说明,6个时间片内我们收到了4条告警,在关系链路中叠加出一个告警的情况,B告警延时高,有可能是网络拥塞的问题,没有那么快解决,它是长期存在的,必然不是影响这个时间片的问题,我们把它过滤掉.

还有一个是B毛刺,马上又恢复了,最后我们关联到A和D是有关系的,D可能在发布,A超时了,我们希望得出一个告警的结果是这样的,直接告诉我一个结论.

质量体系：生态构建

回到我们做监控的本身,是不是光有监控能力就能解决一切的问题呢?

大家可以想一下,运维能做的是最大程度地帮助你降低影响,但是不能保证这个问题如果是程序代码的问题也能被根治.

（编辑：ASP站长网）