掌门教育自研APM实际分享

为什么我们要自研掌门教育自己的 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 数目、日志量开始慢慢多起来，这么多的数据量里面，我们去做数据信息的检索，去查某一项的数据，性能上还是有很大的提升空间，未来我们可能调研一些其他方案来解决这些问题。