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

《腾讯亿万量级告警是如何做到全、准、快的？》要点：
本文介绍了腾讯亿万量级告警是如何做到全、准、快的？，希望对您有用。如果有疑问，可以联系我们。

讲师简介

梁定安

10年运营开发、海量运维和架构规划经验,任腾讯社交平台运维团队负责人

主要负责Qzone、相册、音乐等社交平台类业务的运营开发和运维规划工作

精通海量服务的架构设计和自动化运维建设

目前专注于devops、APM、大数据的运维实践探索

自我介绍

我是来自于腾讯社交网络事业群的梁定安,今天我给大家带来的分享是关于我们做了几年的智能监控实践的分享.

我们事业群是负责社交网络的,就是传统的QQ、QQ空间、QQ音乐业务,跟游戏场景有些不同.

所以,我们在做社交应用监控的过程中,遇到了一些什么样的问题,我们做出了什么样的思考,最终落地的实践是什么样的,我今天希望重点跟大家探讨这些实践经验,以及在这个过程中的思考.

监控的意义

我们今天的主题运维自动化是效率提升的一个话题,今天早上也有嘉宾分享过,效率对产品、开发、业务价值来说其实没有特别地显性,运维自动化更多受惠的是运维自己,真正给运维带来价值的是我们对质量的保障.

通过我们做的一系列的监控、自愈等等运维功能,其实都是为了体现我们运维岗位能给业务带来的一个价值.所以,我认为质量是运维最重要最优先去关注的.

运维在关注质量方面主要是三个方面：可靠性、可用性、用户体验.

你的程序是不是可靠的,通过对可靠性的管理、监控来实现对可用性的评估,提出优化建议.通过不同功能、微服务的可靠性可以计算出业务可用性.

最终,所有对可靠性和可用性的度量,都是为了提升用户使用我们的产品的体验,让用户体验变得更快、要爽、更好,这是我们做监控的意义.

监控的手段

怎么样能够保证我们产品的服务质量和用户体验呢?

通过三种手段可以做到,也是我们谈监控经常谈到的手段,

主要分为三种：

1. 主动
2. 被动
3. 旁路

主动,所有的业务开发出来的应用程序,在上线之前能够按照运维的要求,或者自身对代码质量的监控,提前做好了很多埋点.

这是最好的开发和运维的合作模式,但却是可遇不可求的.

因为很多业务在专业运维团队接管之前就已经存在,运维面临的最大困难就是历史包袱,一个业务可以没有产品,可以没有开发,但是一定不能没有运维.

在腾讯社交网络的业务发展的十几年时间里,很多长尾业务真的是连研发团队、产品团队都已经没有了,但是服务仍然在对外提供正常的服务.

面对种种历史包袱或者规划不周全的问题,监控除了主动手段外,还需要第二种方案,就是被动监控,一种从外部探测而非自主上报的被动行为.

比如,判断一台设备是不是宕机了,我们可以部署几台探测机,持续的ping它,这就是被动的监控手段.

被动有一个先天性的好处,不是强依赖研发团队配合,我们无痛式的去监控,但是这种能监控的粒度往往却是有限的.

旁路监控,主动和被动监控做好了,不代表用户对我们的产品体验是满意的.

举一个例子,有可能我们的服务都是四个九,甚至是五个九,但是由于用户本身网络的问题,压根就访问不了我们的服务器.

这个时候就需要舆情监控等跟第三方的对比数据,来间接的反应我们外网服务的真实情况,作为对主动和被动监控手段的一个重要的补充.

监控的本质

掌握了监控的主要手段后,我们该怎样衡量各类不同的监控点呢?请求量、成功率、延时.

所有监控点的度量,都能收拢到这3类指标中.如CPU百分之百了,反馈在我们的服务上就是成功率的下降或者延时的上升.

这三个指标点怎么样产生数据的价值和反馈出问题呢?

通过趋势对比,同比、环比、波动分析、聚类等数据加工分析的策略,来更直观的突出数据中需要技术人员关注的焦点.

如,通过用户的来源IP聚类分析来判断是否有地域的汇聚,从而发现一些和地域相关的问题,类似的做法可以把种种隐藏在监控数值下的一些非显性问题暴露出来.

并且,我们所有的监控数据最终都是会以图、表、告警的形式,通知关注这些监控点的人.

监控系统的目标——全、快、准

我们做任何一个监控系统都希望做到全、快、准,就是无盲点,360度无死角,并且又快又准,没有误告警.

但是实现起来很困难,从某种意义上来讲,监控速度要快又要准是有点相矛盾的.

举一个例子,监控突然产生一个毛刺,因为一个网络丢包,它的成功率马上就掉了,这个时候产生告警,可能下个时间片就马上恢复了.

如果这样产生的告警是不是运维人员会觉得不准呢?因为等我上机去看的时候已经恢复了.

我们怎么样能够权衡,能够做到又快、又准、覆盖全呢?一旦全了,数据量就很多,数据多产生的告警点就很多,怎么做到呢?我们带着这个疑点,看看我们在实践中是怎么做到的.

全链路监控

随着移动互联网的兴起,用户在访问到我们社交服务的时候,全景的链路大概是这样的(图),首先用户在自己终端设备上发起的访问,会经过很多不同的网络到达我们的后台服务中.

移动互联网让这个网络变得更复杂化,我们有不同的接入方式,有不同的运营商.

同时,移动互联网又把我们暴露在用户侧的客户端的版本碎片化,有很多版本,有很多不同厂家不同型号的智能手机,有安卓,有IOS等等不同的系统.

因此,我们要做到全面的监测,就必须在整个全景链路中设置很多功能不同的监控点.

腾讯在我们的社交业务场景下设置了很多的监控点,这是一张全景图,图上有很多小字母,每个小字母代表了不同的监控类型,我们分为网络类、服务端类、基础类.

又专门针对移动互联网的特殊性做了很多,比如卡慢分析、多维度分析、舆情监测,这些都是具体的监控点.

监控的速度

有了这么多监控点,怎么样保证所有监控点的监控数据能够快速地被加工、处理,最终传递到最需要关注的人手中呢?

我把监控数据从采集到最终终端用户收到产生的异常信息及单个监控点的数据从采集到最终产生告警的耗时做成瀑布流.

大家可以很直观的看到一个监控点的数据怎么样加工计算才能保证最优最快或者最性价比最高,怎么样让我们的告警又快又准?

可以优化的点需要我们深入探讨和挖掘,由于时间关系,只能简单列举一二.

统一上报协议

为了降低计算的复杂度.我们把所有的数据归为三维数据和多维数据.

三维的数据就是一个ID,你上报的监控是什么类型的,你的ID、你的时间、你的值,我们就可以做针对性的告警或者图形展示的一些优化,让我们的处理速度会变得更快.

多维,因为社交网络提供的业务类型、对用户的服务也是多种多样的,有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超时了,我们希望得出一个告警的结果是这样的,直接告诉我一个结论.

质量体系：生态构建

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

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

通过报警能力的建设,把质量生态建设起来,光靠运维团队自己是没有办法做好这个事情的,我们为了更好地做好监控,为了能够让产品给到用户最好的体验,需要有更多的角色与运维配合着一起去做很多事情.

天网体系

我们把不同的监控点,按照一个业务架构层级的不同做了一个分类.这个分类就代表了每一类最应该由谁负责跟进,相当于是给每个人负责一大堆的监控点的现状做了减法.

以前我们做监控的时候,经常说这个监控点是这个业务逻辑影响的,配上他的开发总监,对口的运维也对上,导致一个告警产生首先辐射了一大堆人,很多人收到这个告警不知道要做什么,他可能就看手机震动得快不快.

为了优化这样的问题,我们专门对所有的监控点按照不同的角色要关注的内容不同做了一个分类,就像用户端舆情的监控,舆情的监控拿手机应用举例,更多的是产品体验的一些问题,说不定用户喷的是按钮摆在右面不习惯,我要摆在左面,或者说他喷的功能性的问题.

我们希望把系统的告警是分级的,根据不同的告警优先级走不同的告警渠道,有QQ、短信、微信、电话,不同的人不同的告警,不同优先级的告警渠道来分发.

运维是主要构建一个监控的能力,并不是运维会收所有的告警,运维只收最关键的告警.

这里还有一个DLP(生死点),是下面三层所有监控点,这么多监控点如果放在一个模块里,这个模块所有的点可能都告,但是我们希望这个模块只告一个,这就是它的DLP.

你的一个agent告警不是决定服务生死的关键,那就是agent的负责人去跟进,选定一个能够决定这个模块生死的监控点作为模块的唯一运维负责的监控点,质量由运维来负责.

其他的如网络问题,负责基础网络的运维去看.

应用运维,负责业务的质量,应该投入100%的精力处理好DLP监控点的所有异常.通过DLP监控点再去与智能监控分析做整合,再对链路中各个模块的DLP进行一次收敛,每条链路只看一个点,每条链路根据相关性进行收敛之后,得出一条链路.

通过这个,我们把监控点做一个减法,很好地把告警收敛掉.

天网：质量体系

我们的监控体系是闭环的：监控能力、业务可用性、用户体验、技术解决、统计分析、持续改进.

我们希望构建这样一个质量体系,把开发、运维、客服、QA、老板、产品都卷进来,运维在这里搭这样一个舞台,让大家共同参与演出,贡献力量.

 

监控其实就是一座很高的雪山,这里的坑很深,很难挖.我们正在探索不同的方法去攀登征服这座雪山,今天分享的这个系统未必能够解决所有的问题.

但在我们实战一年多的时间里,确实能够真正帮助运维解决一些问题,我们的告警没有以前那么多了,重新梳理了我们整个体系的生态,让更多的人进入我们的生态贡献自己的一份力量.

我今天的分享结束了,谢谢大家!

Q&A

Q1：主动、被动、旁路,这三种在整个告警量的范围内,比例分别是怎样的?这三路产生的效果分别怎样?

A：其实要看不同的场景,具体的占比没有计算过,旁路肯定是最少的,但是旁路往往最能说明问题,我们做监控的目标是为了监控用户体验有没有受影响.

我提到的旁路监控就是舆情,监控用户口碑,在用户反馈的论坛,你的APP有一些快速反馈通道的时候,用户反馈的自然语言会被分析,分析完了发现异常

例如QQ发不了消息,这个关键词被命中很多就会告警,确实是有用户遇到这种问题.

但是并不是说它就是万能的,有些情况下用户不会反馈,直接卸掉了.

这个时候我们需要结合主动和被动,我们技术能做的就是把主动和被动做好,舆情作为我们的一个辅助手段

要说占比的话,主动当然是做得越多越好,但是这里往往有一个问题,拿日志举例,我们日志的规范是不是一开始就能够设计好?

随着业务的发展,我们未必考虑得那么清晰

现在在腾讯社交网络事业群,其实我们没有一套通用的标准化日志,因为从腾讯刚成立就想规划清晰标准日志体系.

公司发展壮大后,QQ打一份自己觉得是规范的,QQ空间又打一份自己觉得是规范的,以谁的为准呢?

如果研发团队能够配合运维做好这里的规范和准则,并且按照运维的要求主动上报,我们的监控点肯定是全的,

但是事实上,我们不得不面对这些客观的问题,我们只能退而求其次用被动的方法.

Q2：请教一下,报警之后就可以做自愈吗?

A：当你的报警精准度很高之后,就可以对告警做分类,做自愈了.

Q3：有没有一个类似的指标来说?我刚才听说92%,已知告警92%以后,自愈的报警比例是多少?

A：我们所有的基础告警都是自愈的,机器宕机等这些都是要求自愈的.业务侧的一些告警,目前我们还没有严格的要求你自愈率一定要达到多少,因为这真的是跟研发投入相关的,但是我们也正在朝这个方向去做.

我之前还分享过我们自动化的一个平台,如果是容量导致的业务成功率低的话,我们会有一个自动上线的过程,就跟腾讯的蓝鲸平台的是一样,这些是归为自愈的,但是这些比较可控.

Q4：怎么保证告警收敛不会收掉有用的告警?你们制订的规则中怎么让它制订得全?

A：这确实是一个很好的问题,告警的收敛,收敛之后的告警是只给运用运维看的,原生监控点产生的问题应该是开发看的,还是会有人看,只是说相对的优先级不会那么高,被我收敛后的告警的优先级更高.

怎么样解决覆盖全的问题,凡事都有一个过程,在我们完全到达巅峰的情况下,还是要兼顾整体的.

目前这条路是不是百分之百覆盖了社交业务所有的场景?

我其实是不敢这么说的,因为随着业务的逻辑、架构的不断变化,有可能会产生新的问题,但是目前我们还在不断地建设,把我们的门槛降低,就能够持续地优化它.

文章出处：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4476.html