为什么我们要自研掌门教育自己的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端用户环境而言，我们的业务交互和采集数据上报都会占用同一个带宽资源，我们必须要保证业务的优先级，尽量不去影响用户使用体验，所以我们必须要实现一定的调度、控制，比如上报数据间隔变大或者变小，让它自动化，自己自动去发现什么时候合适去上报数据，同时我们也会需要一定的延迟上报能力，看看多少量的情况下更合适上报，而不是定时、定量去发送。
未来展望
-
我们希望能够在数据上报成功率上再进一步，目前我们的上报成功率大概在98%左右，我们希望这个数据可以达到99%以上。
-
天眼系统研发的初衷，是希望能够补充我们公司定制化场景下的一些问题，所以我们也不希望闭门造车，未来，我们会去跟业务方进行沟通，对接更多的技术、业务需求，最终做到与公司互相赋能。
-
目前，我们的Topic数目、日志量开始慢慢多起来，这么多的数据量里面，我们去做数据信息的检索，去查某一项的数据，性能上还是有很大的提升空间，未来我们可能调研一些其他方案来解决这些问题。
