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

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

讲师简介

梁定安

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

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

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

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

自我介绍

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

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

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

监控的意义

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

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

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

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

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

监控的手段

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

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

主要分为三种：

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

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

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

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

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

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

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

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

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

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

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

监控的本质

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

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

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

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

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

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

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

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

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

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

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

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

全链路监控

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

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

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

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

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

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

监控的速度

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

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

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

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

统一上报协议

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

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

（编辑：ASP站长网）