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

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

目前天眼系统的使用场景

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

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

掌门教育自研APM实际分享_前端

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

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

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

天眼系统的辐射能力

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

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

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

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

掌门教育自研APM实际分享_前端_02

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

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

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

掌门教育自研APM实际分享_前端_03

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

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

未来展望

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

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

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