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

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

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

我们希望把系统的告警是分级的,根据不同的告警优先级走不同的告警渠道,有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：这确实是一个很好的问题,告警的收敛,收敛之后的告警是只给运用运维看的,原生监控点产生的问题应该是开发看的,还是会有人看,只是说相对的优先级不会那么高,被我收敛后的告警的优先级更高.

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

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

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

文章出处：高效运维

（编辑：ASP站长网）