为什么咱们要自研掌门教育本人的 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 数目、日志量开始缓缓多起来，这么多的数据量外面，咱们去做数据信息的检索，去查某一项的数据，性能上还是有很大的晋升空间，将来咱们可能调研一些其余计划来解决这些问题。