写点什么

掌门教育自研 APM 实际分享

发布于: 23 小时前

为什么我们要自研掌门教育自己的 APM 系统

针对数据分析这块,掌门教育内部,后端服务使用的是开源的 Apache SkyWalking 系统,虽然 SkyWalking 已经提供了非常方便的 SDK,可以满足我们很多场景下的需求。但对于掌门教育目前的一些定制化的前端业务场景,我们很多的业务需求依然难以完全覆盖,以此我们前端需要一套自己的 APM 系统。

目前天眼系统的使用场景

天眼系统主要是针对外部 C 端用户信息进行记录,目前掌门教育已经有 400+个前端项目,接入天眼系统的应用数量也有 100+,接近所有项目总数的 30%,主要覆盖 Web 端、H5、App 这些应用场景。

掌门教育天眼系统的模块结构



探针:数据采集、上报是 APM 系统的发起点,它主要负责在客户端程序中采集数据,并发送到我们服务器端的收集器。针对探针的设计,最大的难点主要在于我们如何去设计,并获取我们需要的数据信息,比如跟用户体验及其相关的 95/99 线等等。

收集器、存储器:收集、存储器本身只是一个简单的应用程序,但结合到数据源多样化的 topic 类型、庞大日志量,以及我们要保持系统的稳定性、可靠性,这就对我们提出了更高的技术要求。

数据可视化界面:UI 系统是我们另外一个非常核心的应用产品,类似我们常见的 PV、UV 指标,都需要在这一层中被暴露出去,向我们的业务赋能这些关键数据信息。

天眼系统的辐射能力

异常预警:前端异常告警的概念相对于后端应用来说,理念可能不是很强,比如后端 redis-timeout 这种异常是非常致命的,前端这样的类似的场景就比较少。但现在,很多极度影响用户使用体验的场景,对于一家互联网公司来说,也已经越来越重要,这就要求我们能够寻找并提供一种方式、方法去让前端团队能够对这些关键指标进行预警。

工单追踪:我们很多时候,C 端用户会报障过来,过去我们只能提供后端 api 的调用链来分析问题,但假如用户 App 本身出现了问题,比如卡顿等等这样的问题,那我们就需要能够获取到用户的设备情况、网络情况来进行分析。

业务指标分析:对于前端应用来说,一个页面内容的渲染、交互,可以分为很多细小的过程,比如我们打开一个新页面,需要哪些流程进行处理,每一个流程的表现情况如何,这些数据信息如果能够记录下来,并且进行针对性的分析,我们前端就可以针对性进行优化。

前端 APM 重点关注的数据类型



我们目前 APM 系统,结合了非常多掌门教育定制化场景的数据类型,这些数据类型可能不一定适合每一个公司,这取决于你公司具体业务场景。在掌门技术部,我们很多的上报信息跟产品、项目是强相关的。

通用性数据类型,我们包括 PV、UV,设备信息,流量信息、系统信息,用户 App 前后台存活信息等等,另外 H5、App 采集方式的区别也比较大,上报的方式也不一样。

数据采集的一些问题和数据上报时机问题



第一个问题是数据源的准确性问题。前端数据源的采集相对于后端,往往受到的影响因素很多,比如后端常见的一些访问超时,发生的时候就可以快速的记录下来,而前端会面临着延迟的概念,另外前端采集还会面临很多数据丢失的情况,这种种因素发生的概率非常高,这就对我们前端数据源的采集带来了很多的挑战。

第二个问题是数据上报时机问题。对于 C 端用户环境而言,我们的业务交互和采集数据上报都会占用同一个带宽资源,我们必须要保证业务的优先级,尽量不去影响用户使用体验,所以我们必须要实现一定的调度、控制,比如上报数据间隔变大或者变小,让它自动化,自己自动去发现什么时候合适去上报数据,同时我们也会需要一定的延迟上报能力,看看多少量的情况下更合适上报,而不是定时、定量去发送。

未来展望

  1. 我们希望能够在数据上报成功率上再进一步,目前我们的上报成功率大概在 98%左右,我们希望这个数据可以达到 99%以上。

  2. 天眼系统研发的初衷,是希望能够补充我们公司定制化场景下的一些问题,所以我们也不希望闭门造车,未来,我们会去跟业务方进行沟通,对接更多的技术、业务需求,最终做到与公司互相赋能。

  3. 目前,我们的 Topic 数目、日志量开始慢慢多起来,这么多的数据量里面,我们去做数据信息的检索,去查某一项的数据,性能上还是有很大的提升空间,未来我们可能调研一些其他方案来解决这些问题。

用户头像

上海白玉兰开源开放研究院 2017.10.23 加入

由上海交通大学牵头,联合电子中国电子技术标准化研究院、北京大学、机器之心、复旦大学、华东师范大学、开源社、上海人工智能研究院有限公司等单位成立上海白玉兰开源开放研究院 http://www.baiyulan.org.cn/

评论

发布
暂无评论
掌门教育自研APM实际分享