腾讯 SNG 监控数据的创新应用

微信邦

监控是运维领域的重要组成部分，我们把监控形容为运维的眼睛、耳朵和嘴巴。整个运行的质量状况要靠监控来发现异常，通过告警来通知大家。在这里，我将向大家分享SNG监控十年来变革背后的驱动因素和立体化的监控方案，最后给大家展示最新的智能监控的应用场景。

腾讯 SNG 监控数据的创新应用

1

IDC异常案例

腾讯 SNG 监控数据的创新应用

给大家分享一个最近的真实案例，2018年春节前的最后一个周末2月10号凌晨6点29分，已有同学休假回家，大部分人还在被窝里熟睡的时候，深圳某个机房的机架掉电。

直到7点20分，负责机房的同学才告诉我们机房的温度异常升高。

26分的时候反馈温度异常原因是空调故障，需要几个小时的恢复时间。

来看一下我们的业务监控。6月21分业务视图告警通知到业务运维同学，6点30分，在10分钟之内把相关业务的运维同学召集起来，启动了大范围故障处理流程。

虽然业务在天津、上海和深圳这三地有容灾策略，为了保障业务的有效运行，在6点50我们评估出影响的范围，决定启动业务迁移。7点40分受影响的业务全量恢复。

可见，告警的及时性和数据的准确性，对保障业务质量发挥了重要的作用。

腾讯 SNG 监控数据的创新应用

一开始我做网络管理系统OSS，当时管理1万个节点的网元和交换机，就觉得这是很牛的事情。

当进入到互联网的监控领域，管理的服务器的数量和节点数量达6万个节点，系统已经不堪重负，经常出现误判的情况。

我们花了大量时间做服务器监控的优化，对架构进行重构升级，到现在已经管理了20万个节点。

在做完升级后，又踏上了移动化的浪潮，因此基于大数据体系做了应用层的监控。

当做完这部分，发现应用层监控能最快、最直接反应业务质量的，它是从应用层的角度去发现问题，触达用户，是最全面的用户体验，比下面两层的准确性更高。

现在的业务场景都会做相关的容灾设备，服务器挂一个其实不会影响业务，但是到底有没有影响业务，从下面两层很难判断。由此我们建立了从整体到局部的立体化全链路的监控体系。

腾讯 SNG 监控数据的创新应用

监控在DevOps里面的应用，随着我们运维理念的变化而变化。一开始监控主要为运维服务，对运维的质量负责。同时也关注业务质量的变化，监控开始触及产品发布这个环节。对业务质量负责的同学不仅仅是业务运维，一个产品的好坏，开发同样承担了重要的责任。

产品如果失败了，整个开发团队也就失败了。因此开发也开始来关注业务质量的监控数据，并且通过监控数据，对线上的业务架构进行优化。

从设计到开发的流程，我们监控贯穿了整个的DevOps流程体系。

2

三大驱动力

腾讯 SNG 监控数据的创新应用

跟大家谈一下背后升级的三个因素。一开始，我们的服务节点跑在腾讯自研的IDC环境，机器大部分是实体机器，做的监控主要是网络监控、服务器监控以及DNS、http，对我们的业务来说，机器量已经足够多了。

当我们走入到“云”环境的时候，需要管理的节点数量量突然剧增到20万，仅仅一年时间服务节点从6万到20万。

以前在独立的IDC的类似私有云环境运行的时候，管理的对象的标识可以用IP作为唯一标识，当我们进入到私有云环境，还涉及到海外的机房，也会去采购其他厂商的云服务，用IP已经不能唯一的标识一个服务节点了，这时候就涉及到混合云如何标识一个服务节点的问题，这就促进了整个监控背后数据模型的变化。

另外，在这么多服务器节点里面，如何去准确的定位出问题，做一个集中化的操控，这个因素驱动了整个服务监控的架构升级。

腾讯 SNG 监控数据的创新应用

这张图是监控系统的微服务架构，对顶层提供了单机和视图两个存储服务，对外提供了数据查询的接口，在这个基础上构建了画图服务、告警服务、统计服务。

这个架构里面表现出来的问题在哪些地方呢？我们的底层服务要考虑到容灾和背后的特性，至少要准备这个情况，下面的各服务节点的服务实例和量非常庞大，我们必须通过事务流的角度来看，来明确获知某一个请求是否异常。

右下角是UGC流程，从博客的发送到Web接收、到数据存储，经历了3个节点，这里面涉及到多台服务器，要查一个问题变得非常困难。

腾讯 SNG 监控数据的创新应用

2010年移动化开始出现，到现在已经完成了移动化的改造，大家使用的频率已经从PC和Web时代转向手机，体验发生了根本的变化，打开一个APP超过10秒时间基本上就会放弃。打开一个APP看视频，如果频繁的出现卡顿，会造成用户剧烈的流失。

对我们来说，关注的指标从当时的成功率到了用户体验，采集的数据量也发生了巨大变化。

我们对服务器进行监控管理20万个节点，数据量还可控。当我们要处理2亿用户的数据的时候，监控系统架构需要做相关升级和改造了。

另外，国内的移动化环境造成了我们需要有多维度的场景。

国内的网络至少有移动、电信和联通这三大运营商，他们的网络是割裂开来的，并且各自的网络质量不一样，需要关注运营商的质量，还要关注我们发布的版本对机型的要求，这对多维度提出了更高的要求。

3

立体化监控方案

腾讯 SNG 监控数据的创新应用

这张图是我们建立的立体化覆盖体系。最下面是传统监控使用的OS服务器网络的监控。

在它之上是对数据层进行相关的数据访问性能的采集。中间是逻辑处理和Web层，都可以纳入到服务器体系来。

新增的是用户端监控，包括卡、慢、多维和舆情监控。舆情监控做的事情是：对于腾讯的QQ体系来说，有一些用户可能会打腾讯的投诉电话，会对用户的反馈进行记录并做相关的文本分析，建立异常的指标，发出业务告警。

腾讯 SNG 监控数据的创新应用

立体化监控数据如何采集，需要注意哪些地方？对于用户端监控来说，关注最多的是H5、http的响应，DNS查询耗时、TCP链接耗时等等。有很多开源的方案，把指标采集上报到接入端，也做了一个插件去采集CGI的响应情况。

上面是靠用户数据来驱动，另外还有拨测，是我们业务主动的行为。在每个厂商的IDC机房都部署了拨测的服务，对这些CGI建立拨测任务，通过拨测的方式采集CGI的响应时间和不同厂商机房的CGI响应时间，这样就可以在第一时间知道上线的服务是否正常。

腾讯 SNG 监控数据的创新应用

服务端监控有两种方式，被动采集和主动探测。对于主机通过主动探测SNMP和IPMI的方式探测是否正常。

主机运行的服务用了侵入式API上报方式，类似于业务埋点，只需要上报一个特性，经过这个行数的次数或者处理分支的次数。API上报会对业务性能产生影响，本来代码能跑10几万qps，监控上报之后降到5万，相应的成本就增加。

这要怎么解决呢？我们在上面做了共享内存，上报的时候直接写内存，数据采集使用原子操作，定时10秒一次的采集数据，报到后端的接入机，这样API的调用次数可以达到7000万。也就是说，这种方式对程序性能的影响是最微弱的。

右上角是是单属性的上报，这里我们看到只上报了一个特征值，可以用10多台服务器扛住20万台服务器的上报量。对于多维度的上报，如右下角，是用多个key来组成一个维来上报。