360SDN.COM

基于大数据平台快速构建 APM 的产品实践

来源:Go中国  2017-09-11 13:02:05    评论:0点击:

今天我的分享主要分为三个部分:第一,简要介绍什么是 APM 以及做 APM 产品的动机;第二,着重分享在整个产品实践过程中的架构演进以及遇到的问题;第三,对这款产品的展望。

首先什么是 APM?其全称是 Application Performance Management,翻译过来就是应用性能管理系统。根据 Gartener 2016 的定义,APM 主要分为三个核心领域即 Digital Experience Monitoring (DEM)。主要是量化监控人机交互的一些体验。比如线上 APP 的崩溃率以及其所在网络环境的速度,这些都可以量化为性能指标进行监控,并且这些指标与人机交互的体验关联很大。

二,应用程序发现、跟踪和诊断。主要是针对服务端各个应用组件之间的关系,检测一些节点资源的占用情况钻取组件之间的拓扑并进行可视化。比如常见的对服务集群各个节点的 CPU /内存占用情况的检测及可视化监控

三,应用程序分析。这个更高层,是利用机器学习、统计推断等一些方法,发现服务端一些性能异常的来源,然后对一些服务器的性能指标进行监控或者预测实现智能化的

我们做的 APM 更专注于基于第一个领域(DEM)。主要是面向移动设备做交互。那么,我们做这款产品的动机是什么?从公司层面上讲,我们是做云存储产品起家,其后逐层推出了富媒体(直播、点播服务、微服务化的容器云平台大数据平台人工智能平台。所有产品之间都是递进关系。而我们的 APM 产品其实是构建在大数据平台之上的 SaaS 产品。所以这个产品的衍生过程是合情合理的。从功能角度讲,们团队做 APM 的初衷是什么?主要有四个方面:

第一,提高直播推流以及播放 SDK 的性能。

第二,优化直播节点质量。

第三,一些简单的统计需求,比如日活等。

第四,日志查询的需求。

我们在最初接到这几个需求时,其实把它归结分为两类:一个是时序数据,刚才前面提到的个方面,最终都是可以归结为几张时序折线;二是日志的检索。什么是时序数据?简单而言就是基于时间序列的数据点,并且在同一个数据序列中的各个数据必须有可比性。比如日常生活中的金融股票,可以看到每日的 K 线图、月线图,以及如图 1 所示都是时序的数据以及CPU 内存的使用量。

图 1

为了应对一开始的需求,我们做了一个如图 2 所示的萌芽版,自己了一套程序,在内存里以及 Redis 中做一些数据的聚合及缓存,然后打点到时序数据库和持久化到 MySQL,再通过 Grafana 进行展示,同时也将全量的日志导入到对象存储。

图 2

从图 2 可以看到,由移动端的 APP 打点到网端,再依次通过 Flume、 Kafka,然后做一些聚合,将聚合出来的数据投放到一些数据库中。另外将一些全量的数据导入到对象存储,以供今后做一些离线分析,展示层最开始用 Grafana 进行展示

这样一个版本基本上满足了最初提出的业务需求。但在完成这些需求之后,我们团队内进行了一些思路的拓展,即能不能利用这些数据做对七牛直播云用户有帮助的事情,更进一步地,能否做对非七牛直播云用户有益的事情,我们认真地进行了思考。之前我在直播业务部门的时候,其实经常在一些用户技术支持群里面收到客户们的抱怨,归结起来主要有以下几个问题:第一是视频打开的速度很慢,即首开时间时间较长;第二是视频经常缓冲,播放时很卡顿。第三是用户出错排障很慢,不知道是谁的问题,以及问题的出现时间。比如到底是主播网络的问题,或者同一个房间里访客本身 WIFI 的问题导致的卡顿等。当用户碰到以上一些问题时,经常一头雾水地跑来咨询我们的技术支持,排障的效率较低。

图 3

于是我们提出了如图 3 所示的视频 APM 目标,主要是针对直播领域,我们提出了四个主要功能:

第一,多维度的数据联合分析,比如 CDN、省份、服务器 IP、ISP 等,对服务器的性能指标进行分析

第二,实时监控数据

第三,提供快速查询定位,针对每个用户的问题进行一些回溯

第四,简单的运营统计

此外,我们横向地进行了拓展,提出对移动 APM 的设想功能:

第一,APP 线上崩溃报告,期望实现类似 Crashlytics 这类崩溃收集服务的初步功能。

第二,网络性能的监测,App 在某个时刻访问自己的 API 很慢,想判定是自己的服务有问题还是所处的网络存在故障,这个时候可以做一个网络性能的测试。

第三, APP 页面视图响应时间监测。

第四,对性能指标的多维度联合分析。

第五,自定义统计数据的分析。这个主要是偏向于运营的数据。

基于我们的萌芽版架构我们遇到了什么问题?第一,因为基本上所有的统计功能都是自己写的,所以功能拓展上就遇到了麻烦。比如,每增加一个统计维度就需要修改很多代码;常见的聚合函数,必须自己去实现,比如百分位这样的函数;新增一个统计点可能造成代码复用率降低。第二,水平拓展很困难,遇到计算资源瓶颈时难以拆分统计逻辑。

图 4

于是我们做了一个如图 3 所示的规划版。首先也是移动 APP 打点到一个网关,然后分发到 Kafka ,一个是实时,一个是非实时,然后进行计算,同时会把全量的日志导出到ES中。我们自己会在展示层做一个 Portal,也可通过 Spark SQL 进行离线分析以及使用 Kibana 做日志检索。这个规划版有什么问题呢?我们 APM 团队刚成立时,人员很少,并且大部分都是从端开发转过来,只有一个全栈的老司机在带路,这个版本基本上是要把整套大数据框架重新搭建一遍。此外,我们自己有对象存储服务,但是如果要用到原生的 Spark进行数据导入,则要再搭一个 HDFS 集群,成本很大。如果还要做一些基于时序数据库的监控,还需要搭 Grafana 套件。当时我们的心情很纠结,如果自己去搭这样一套集群,首先业务层面的功能开发会受到影响,其次可以预见今后我们对这一整个集群的调试、排障和初步运维工作是无比艰巨的。

但是需求来了还是得继续做下去,正在我们着手开始搭建一整个集群时,公司内部推出了一个大数据平台,代号 "Pandora"。这是一套从存储到数据化、可视化、全栈的大数据的分析产品,它的核心其实是一个 workflow,用户可以使用 Workflow 管理自己的数据流,无须有大数据背景,实现可视化数据流监控,降低运维成本;并且集成诸多优秀的社区组件,优化并做到更好。我们评估了一下 Pandora 的架构及功能点之后,发现无比契合我们的需求,于是立即终止了之前的一些集群架设工作,成为了 Pandora 的第一批用户。

图 5

如图 5 所示是七牛大数据平台 Pandora 的架构图,其数据流的方向是自上而下的。上游是数据源的输入,中游是一个实时或者离线计算工作流的引擎,下游是各类的数据导出服务。上游数据来源可分为多种,一个是 REST API,可以方便地进行自定义打点;其次有一个功能强大的日志搜集工具 LogKit,可以快速收集各类日志;然后还有一系列不同语言版本的 SDK,比如 GO/Python/PHP 甚至是 Android/iOS 等移动版,可快速用不同的姿势接入推送数据。此外,Pandora 还支持从七牛的对象存储,以及如 CDN 日志存储这样一些离线数据源进行数据拉取。总而言之,所有数据来源就分为实时和离线两部分,这两部分数据都会被打入到各自的消息队列中,而后用户可在工作流引擎中分别创建两种任务,即实时计算任务或离线计算任务。这种计算任务创建动作可以往复进行,如一个消息队列中的数据可以经过三四次甚至更多的清洗、转换过程,直到最终在下游被导出。

Pandora 提供几种导出服务,一个是 Pandora 自研的时序数据库 TSDB另外是日志检索服务 LogDB,还可以导出到七牛对象存储进行永久化保存,另外还有其他一些 RDS 以及 HTTP 的回调导出方式。导出至对象存储的离线数据可以通过 Pandora 提供的另外一个单独的组件叫做 XSpark 直接拉取,以进行离线分析。最外层还有一个 Report Studio 报表系统可从各类下游节点中导出数据进行报表展示。

图 7

于是我们就根据 Pandora 的架构重新设计了如图 7 所示的实施版架构图。首先也是由移动 App 通过 SDK 或 REST API 打点到我们自己的网关,在进行初步的数据清洗之后打点到 Pandora 的 Pipeline,全量的原始数据可以直接导出到对象存储和 LogDB,供持久化及快速检索使用。各个统计功能点会经过实时工作流的 Transform 计算任务之后,导出到 LogDB 或 TSDB,然后通过 APM Portal 进行展示。此外我们在 TSDB 之上,建立了一个监控告警系统。最后,我们通过 XSpark 定时分析导出到对象存储的原始数据,做更多维度的关联系分析及实现更高层次的数据分析逻辑。

至此,我们团队可以将主要力集中在红框的组件上,第一是移动 SDK 的开发,第二是 Pandora 工作流一些核心计算逻辑的编写,是数据展示的前端及监控告警系统此外还有数据网关等的开发部署最初的一系列大数据集群相关烦恼不复相伴。

图 8

基于 Pandora ,我们核心逻辑变成什么样子?由于 Pandora 提供可视化的任务编辑界面,所有的计算逻辑都可以呈现为树状的拓扑。先是 上游的数据 打点都会在工作流的 数据源汇集 然后在数据源之上 新建若干 个计算任务,计算出实时的结果会自动被导出到单独的 消息队列,最后再 导出到时序 数据库 如图 8  (APM实时计算工作流)所示,各个 消息队列里面的数据想额外 导出到对象存储、日志检索这些下游的节点都是可行的。图中 每个分支代表了一个  APM 的统计计算功能。

我们以直播的卡顿率这个性能指标为例,分享一下在 Workflow 中的计算创建过程首先要定义卡顿率的测量方法。比如以一分钟为频率,我们观察某段视频在一分钟之内是否存在缓冲?有的话填 1,无缓冲填 0,上报之后,将这一列数据的值进行求和,然后除以时间段的总上报数量,即时间内的卡顿率。我们可以通过运营商、服务器 IP、上报平台等各种不同维对卡顿率进行聚合。

图 9

这个卡顿率反映在 workflow 是什么样子?就是如图 9 右侧所示 一个 SQL 语句。SQL 中  d的字段在数据源里都 存在,如果没有的话可以通过一些 预计算先得出。比如 V4 是代表一个卡顿率的 sum 操作可得到缓冲总次数,count 则得到 上报数据的总条数 sum(v4)/count(v4) 则可得到平均卡顿率。在 workflow 的 pipeline 中进行如上聚合计算之后,将最终结果 时序数据库中 ,就形成了一个实时的卡顿率变化情况的序列。

图 10

最终卡顿率这个指标导出的结果是什么样子?即如图  10 所示的一张表 首先它是以时间作为基准,然后 分为 CDN 、国家、分辨率、运营商、实时观看的总人数、移动平台、省份 等维度 我们最后可以通过这张表指定查询到如 “福建电信 iPhone 用户在某半小时之内”的卡顿率情况。

图 11

随着产品的逐步完善,发展至今,整个 APM 的组件如图 11 所示。一个是端的打点 SDK,现在已经有  iOS 和安卓版,一个接收打点的网关,一个展示系统展示页面,以及 一个告警系统。底下深蓝色四个方块其实都是 Pandora 提供的 组件,我们所有的运算逻辑 目前都是放在实时数据流的处理引擎中,之后会 根据需求建立一些 离线数据的处理 任务 现阶段在离线数据分析这块,主要是利用 XSpark 对原始数据做定时统计,算出诸如应用日活、地域分布等数据。

这套系统的吞吐量取决于 Pandora 吞吐量的上限,现在 Pandora 每分钟实时写入的数据增量是数百个 GB、数据条数达到数十亿条;每天的数据增量是数百 TB,已经经受住了海量数据的验证。因此依托 Pandora 这个平台,我们不担心吞吐量受到限制。我们自己的程序做一个水平拓展,比如网关在数据峰值过来时做什么样的应对,我们在上面进行了一个容器化的处理,就是把这些组件都做成一个微服务,然后可以方便的对他们进行水平拓展。这样一个服务高可用以及数据吞吐能力等问题基本都解决了。

回顾最初提出的 APM 的目标(图 3),这些目标我们是否都能够通过 Pandora 这套大数据平台,然后构建出来并一一实现?答案是肯定的。刚才讲了,比如卡顿率的计算,我们放到时序数据库里面,然后再通过前端拉取出来进行展示。

图 12

大家看到如图 12 所示的两个图,上图是卡顿率,下图是首开时间,然后根据它的移动设备平台、运营商以及省份这三个维度进行联合展示。它可以快速拉取,根据省份、运营商、平台进行分析,得到图 12。底下的首开时间也是一样的。

图 13

如图 13 所示是更多纬度的质量的对比。比如通过移动端的上报,我们可以获取到各个 CDN 厂商的数据。据此监控各个厂商在某个时刻,或者在某些运营商、某些省份、某些设备平台之下的表现。对于大规模直播服务提供厂商,他们可能会有多条备线,那么就可以根据我们所反馈的质量指标来切换所要选择的主线或者备线。比如福建一个厂商在某个时间段内,他的主要流量都放在 A 厂商,如果卡顿率、请求错误率大幅提高,就可以根据监控数据进行实时的切换,比如切换到该时刻另外一个性能比较好的 B 厂商

图 14

图 14 是从 LogDB 日志检索的一数据。直播过程中,用户经常会和平台提供方抱怨,说什么时候很卡,或者某个房间的某用户说无法观看。整个问题处理的流程中,用户是先反馈到直播服务的提供商,然后再由直播服务的提供商向我们的技术支持进行反馈。由于中间多了这样的一个流程,整个处理的速度就会降低。如今,使用用户日志进行检索,直播服务的提供商可以根据用户的设备 ID 或者用户 IP 直接在日志检索系统里进行查询,然后回溯观察当时用户所处的网络情况以及同一时段该房间内其他用户的情况,可以先自行定位问题所在,提速排障过程。

图 15

对于移动 APM,现在我们做了 APP 崩溃日志的集。我们将 App 端上报的日志存放到 LogDB 以及对象存储进行检索及展示。另外我们支持自定义事件上报,这个对于简单的运营统计需求,其实很有帮助。它可以自己定义一些数据格式,通过 APM 创建这样一个数据 Repo 后,会在 Pandora 自动生成一个 Pipeline 和 Export。通过将上报的数据存放到 LogDB 或对象存储,以便后期报表展示或者进行二次数据分析。

之前说到离线的日志分析,可以把全量的数据都存放到对象存储,然后通过 XSpark 分析后通过 Zeppelin 展示,用户要自己使用的话,可能会有一点的使用门槛,自己可能需要熟悉一些 spark 的编程范式,可以对离线的日志进行统计。比如我们统计出了一个网络的正常响应的正常代码的比重,还有用户设备以及省份的分布图。比如一天跑一次生成一个数据表,可以直接把报表导出,用来做一些运营的分析,或者把这些数据二次导出到下游的存储中。

另外我们还做了一个 APM 的功能——监控告警,最开始是基于 TSDB,即时序数据库来构建的。并且使用 Kapacitor,一个实时聚合计算和告警引擎。但是我们遇到一个问题,时序数据库更适用于做查询,因为它是对查询有做优化,基本写入一次,多次读取,高频聚合计算,是极耗 TSDB 所在节点的 CPU 和内存。比如 IP 做 GroupBy 的聚合运算,会造成查询的超时。Kapacitor 是用程序员思维做出来的一款产品,它提供了自定义的 DSL 叫 TICKScript,但学习成本高,普通终端用户基本没办法自行创建一个告警任务

我们是如何处理这两个问题的呢?第一是可以利用 Grafana 为做告警,第二是基于 TSDB,利用 Kapacitor 进行实时聚合计算和告警,通过定制一个前端降低告警任务创建门槛。第三是基于七牛云这 Pipeline  为利用实时计算做复杂运算的告警。如果说计算任务非常大,或者运算逻辑复杂,其实可以做一个容器上的垂直扩容。然后通过 Pipeline 进行聚合计算之后再把这部分数据导到 TSDB,最后再进行告警。

图 17

左边是我们做的定制化的告警界面,可以在一个时序数据库的仓库,选择一个表,选择要监控的字段,中间可以设置一个值,比如五分钟内总体的卡顿率 20% 的情况下,底下是一个下游的告警分发,可以通过邮件等方式分发告警信息右边是基于 Workflow 做的实时流计算工作,我们把之前能放在 TSDB 中做的聚合计算任务放到 Pipeline 里做,好处是你要做告警的话,只需要查里面有没有数据点即可,有就证明这个时间段内是有异常发生的。然后再做告警。

 

最后,小结一下我们做的 APM 产品。第一,基于现在实施版来说,它是构建于七牛大数据平台 Pandora 这个 PaaS 之上的一个 SaaS 产品;第二,目前,我们做的 APM 没有大而全的功能,相对一些老牌的厂商,我们更希望深耕于数字化体验领域,即 DEM;第三,提供一个可定制化的运维、运营数据分析呈现工具,给使用用户提供运营数据分析;第四,开放自由,用户愿意的话可以自己上报所有的数据,包括所有自定义的数据都可以导出到对象存储,后续有任何分析的需求,均可随时自行拉取而且存储的时长基本上不受限制,比如导出到对象存储的话可以做到永久存储。

我们有一个感,在构建 APM 的过程中,我们遇到最初选择架构的纠结过程,后来回想起来,一个小的团队,最开始要做一件事时,不要太过关注于一些复杂的底层层面的事情,而是要善于借助外部的力量。我们比较幸运的是踩了 Pandora 这样一个有力的臂膀之,可以快速的进行迭代和演进,可以更加专注于我们所需要处理的一些业务数据,以及一些产品的功能层面的一些事情。

那么,将来我们对这个产品的展望是什么样子?第一,将更专注于 DEM 这个核心领域的第三个层次,即数据分析这一块相关内容,我们将结合更多的机器学习算法进行数据挖掘,可以去发现用户数据中的热点以及趋势;第二,做更智能的告警,现在的告警很初级,用户自己要去干预,手动设一个阈值,比如刚才讲的卡顿率或者错误率都要根据自己的经验去设一个预值,我们希望将来可以对异常的情况做一种预测,如果在这样一个持续的数据里发现一些异常变化的趋势时,我们希望能够及时提供告警。这个是我们后面想做的一些事情。



 

 

阅读原文

为您推荐

友情链接 |九搜汽车网 |手机ok生活信息网|ok生活信息网|ok微生活
 Powered by www.360SDN.COM   京ICP备11022651号-4 © 2012-2016 版权