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

本文由 吴树生 发表于 腾讯织云公众号

引言

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

1、IDC异常案例

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

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

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

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

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

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

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

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

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

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

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

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

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

产品若是失败了，整个开发团队也就失败了。所以开发也开始来关注业务质量的监控数据，而且经过监控数据，对线上的业务架构进行优化。

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

2、 三大驱动力

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

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

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

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

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

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

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

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

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

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

另外，国内的移动化环境形成了咱们须要有多维度的场景。

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

3、立体化监控方案

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

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

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

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

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

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

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

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

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

这对后端带来了新的挑战，这里key的组合数比上面单属性成倍的增长，还用10多台服务器就扛不住了。对于多维的上报，key和指标的聚合计算放在上报端的机器去作，API上面会按1分钟的维度作聚合，聚合以后经过Agent传出去，流量降了接近一半，性能可达80万/秒。

对于数据层的监控，咱们最担忧的问题是数据存储不均匀，也就是解决数据倾斜的问题。这一块的数据采集没有啥办法，只能依靠存储自身内置的特性来采集。

上面说了下数据采集，接下来总结一下织云监控的理念，最核心的是创建数据银行。数据银行要作到普适性，所以数据银行的模型就必需要足够抽象。咱们创建了三类数据模型：

• 第一类模型是海量KPI指标的TSDB存储引擎，能够达到每秒万级别请求的毫秒级响应；

• 第二类模型是海量多维的OLAP-TSDB存储引擎，它的复杂度比前面要求高不少，只能作到秒级的响应；

• 第三类模型是海量日志存储引擎。

咱们在内部作完预研和应用，把场景提炼出来，而后再传递出去。接下来跟你们介绍一下咱们的数据银行是怎么作的。

KPI型的TSDB，全部的数据均可以抽象几个特性，一是时间，二是监控对象是什么，这个对象能够有不少个指标来表达，因此咱们把指标称做特性。对象的值经过四个属性来表达，就是KPI的对象数据存储模型。

当咱们把这个场景用于服务端监控的时候，业务模型监控的对象是单机或者单个虚拟节点。咱们的业务是分布式的服务，因此在单机上面还要再聚合成业务视图。整个存储数据上报以后，会先把数据写到单机的内存里面，只保留2天的数据，作热查询。据咱们统计，80%的数据应用查询都是查询2天内的数据，所以天天会定时的存储到文件上。

另外，咱们还创建了对象和特性的存储结构。数据层和数据应用层分离，提供proxy和worker的架构，数据计算层使用了类MR的方案来提供高效率的数据查询，也就是万并发下面的毫秒级查询。内存的数据存储采用了多阶hash的共享内存结构。

OLAP的数据模型关的时间、对象拓展，拓展成一个维度的概念。举个例子，某一个运营商的客户端IP，能够被认为是运营商的维度，客户端的请求还带有相关的版本信息，以及对应接收段IDC的信息，这些信息都是维度。

指标就是客户端的请求和请求的响应时间。由对象扩充到维度，前面一天百万级的对象能够存储，如今有30亿的维度组合的数据怎么存呢？这时咱们选的是druid查询。采用druid作存储，有如下几方面考虑：一是存储成本低。

更重要的一点是，咱们监控系统的维护对象的减小，druid只有5个组件维护对象，而基于Hadoop体系，涉及到维护对象成倍的增长，对于监控系统开发人员来讲，这些组件的学习成本也是不可承受的痛。对于这一块，咱们不只仅是用，还作了相关的优化，一是压测以后的druid调优，二是容灾优化，三是控制成本。

咱们作LOG的时候是采用相关的开源组件来存储业务上报日志，当业务渐渐上线的时候，发现开源的方案扛不住。

你们知道，开源一开始用的时候很爽，可是深刻去用的时候，须要不断的去改它的BUG，这会致使投入到开源里面的时间比本身写的时间还要多，成本高。假如说数据量是100T，用了开源的方案，加上索引的数据，数据量至少要乘上1.5。

为了解决性能和成本的问题，咱们自研了一个LOG的查询存储服务。数据进来以后，它会按照key作查询的分片，先放到数据缓存。若是直接写入磁盘，磁盘也存不住，因此加了数据缓存，先把数据按照1M大小缓存成一个块，而后放到服务器上，相关的块的分段和数据放到这里面来记录。

数据读取的时候，怎样作到秒级的数据响应和低延迟的数据查询呢？延迟是在数据缓存这一块，由于要缓存1M的数据大小，若是上报的数据量小，须要等待很长时间到文件存储。

为了解决这两个问题，一方面数据会从文件服务器上拿过来，另外一方面会从缓存模块提取数据。建一个数据过滤模块，专门负责数据的解压和查询。

对于这种方案，首先作到技术上的把控。二是架构上面维护对象和模块要足够少，毕竟一个团队的精力有限。三是成本，通过这样处理存储成本下降了，查询性能也有提高。

咱们的数据如何处理呢？在SNG里面有各类考验，上报的数据格式多样，大多不是规范化、标准化的，毕竟前面有十多年的技术架构发展，相关的方案也不可以统一。

除了监控成本，还要考虑效率，咱们对整个过程作了数据的抽象，也就是数据的翻译、过滤、统计、告警等功能，经过配置化的方式去实现，再转化成页面的配置化方式，提升效率。

也就是说，咱们对一个业务的支持，以前须要专业的开发大数据开发同窗一周时间完成开发，如今减小到产品开发同窗半小时完成业务监控的数据处理配置。

这里有几个比较有特点的点：一个是消息队列，咱们以前用Kafka，因为磁盘和机器不稳定，消息队列变得不稳定。

后端数据处理流程若是异常了，若消息队列在，会把以前挤压的数据从新消费，要从新启动，系统恢复时间须要三十分钟。

如今咱们采用的方案是建设稳定的后端，若是后端异常，之前积累的数据都是能够抛弃的，咱们要保证后面的数据。数据落地存储以后，数据银行提供一个查询的API网关。

刚才提到，对数据模型处理进行抽象。它的数据模型是如何创建的？全部的数据均可以表达为原子数据列表，好比一行数据的第几个字段，数据名称是什么、数据值是什么，把这个成为原始单元，而后去过滤、聚合和转发，对这四类操做进行抽样处理，最终依赖的实际上是Storm数据传输能力。

这里有一个好处，假如哪一天Storm再也不维护了，咱们开发的这一块代码还能够用新的框架去跑，由于它并不强依赖Storm的特性，仅仅用了Storm的传输特性。

咱们几大平台有monitor特性监控、哈勃多维监控、全链路日志和告警平台，其上都创建了统一的API层。在这个基础上，各个业务运维团队去构建场景化的监控。

统一API之上的东西是大有可为的，运维的经验沉淀就是最上面的这部分，并不须要掌握下面那么专业的大数据处理的工具，把上面的场景开发构建起来。

4、智能监控应用场景

谈AIOps，数据是前提，先得把数据银行构建起来。有了数据该怎么用、能够怎么用？咱们对监控目标进行全新的定义和阐释。

• 全。要作到无盲点的覆盖，刚才我列举的立体化监控体系里面，每一层都要有监控。如今新的监控需求来了，要求的是全链路的监控，每个请求、每个处理节点都须要链路的状态信息。

• 准。咱们一直在强调怎么作到无误告警，监控系统误告太可能是有缘由的。这时候咱们除了作到无误告以外，还要把异常根源给推导出来。

• 快。咱们追求的是数据的低延时，告警发现的速度快，分析也要足够快。

告警检测传统的作法是经过阈值检测。阈值检测有什么问题呢？

• 第一，告警不许。咱们统计了，告警的业务故障自动发现率40%。你们一般是敲着代码再看监控系统有没有异常，还会出现漏告警或者误告警，阈值告警没法解决这个问题。

• 第二，维护困难。业务的发展，须要持续开发代码，业务发生变化，配置得不到变动，必然会致使大量告警出现。

• 第三，告警量大。咱们曾经人均一天收100条告警。有部分同窗我的的告警量达到1000条，一天有1440分钟，每一分钟都是在收告警，手机的耗电量和流量是很大的。

这里涉及到无监督算法，咱们的张戎博士会给你们分享下的。

告警里面若是带上根源，此异常是根据某个数据服务异常致使的，处理效率会更快。从这张图上看，告警异常的出现必定有时间相关性。

发生告警以后，异常的曲线和状态也是出现的时间点，各类监控系统处理的告警密度和时延不同，可是这个持续的时间是相近的，由于有时间相关性。不只如此，还要知道链路的调用关系。

这个调用关系怎么去作的呢？刚刚提到的微服务理念有模块的调用关系和路由调用关系，咱们有配置信息。

没有微服务的系统怎么办？经过定时抓包的方式，也能获取到网络的流量关系，再加上业务经验和人工清洗的功能，以及一些AI算法，整理出一个带圈中的调用关系对，里面会叠加时间相关的告警，而后推荐出告警根源。

异常根因分析这个案例应用在多维监控的场景。以前咱们对成功率进行判断，由于你们标准同样。

我想说为何运维的AI那么难作？

图片的AI和语音的AI有一个特色，就是标准是同样的，与咱们人眼的视觉评判标准是相似的。而业务运维的AI难作，由于每一个业务的异常业务特性是不同的，也就是标准是各异的。

成功率的好处是成功率的标准是一致的，因此能够找出异常维度的组合。

可是，不能只知足于这个反馈，会出现请求量卡顿数的异常，咱们要扩展到累计量的指标。异常分析推荐出来的准确率，要考虑到总量的权重和异常的权重。

还有一点是性能，咱们经过算法去计算出某个异常，无法像广告系统那样作离线计算，跑一个算法，等着晚上出结果，对运维来讲，咱们但愿能作到秒级的响应。

所以，对于异常根源的分析挑战，一是通用性，二是准确率，三是性能。

上面介绍了三类应用场景，已经可以覆盖咱们大部分运维监控的应用。接下来给你们讲一下咱们运维智能监控的具体案例。

上面这张图是咱们常常看到的一个KPI的曲线，也就是成功率的曲线。

在这里8月31号21点发生了一个异常，若是这个数据的基点不是从97%看，而是从0开始看的话，是看不出这里有异常的，它仅仅掉了2个百分点。

这是很是棒的，即便2个百分点或者零点几个百分点的降低，咱们也可以识别出来，而且还能识别出微小降低的缘由。

上面的是如何作到的呢？靠人工的办法，首先由全局从大到小的概念去看，先选一个最少的维度来看，看下面的成功率哪一个掉了。手机QQ的成功率在这个时间点最低，同时总的请求数占比最大，毫无疑问，先分析手机QQ的每个维度。

算法是能够模拟人的操做，可是怎么去判断成功率的这个权重呢？咱们是参考了微软的一篇论文。分析完异常以后，咱们可看到空间点播业务异常，找到一些访问码，须要客户端的同窗去查相关代码，拿到这些信息仍是不够的，还须要日志。

在这个异常的点相关的信息上，咱们跟日志挂钩，跳转到日志的节点来看，这时候就有足够多的信息来支持开发去定位和快速恢复问题。

谢谢你们。

做者介绍

吴树生：腾讯高级工程师，负责腾讯SNG大数据监控平台建设以及织云多为监控，近十年监控系统开发经验，具备构建基于大数据平台的海量高可用分布式监控系统研发经验。

欢迎你们关注腾讯织云微信公众号（TencentCOC），第一时间获取更多运维技术实践干货哦~