自研工具是为了解决内部问题而生，希望通过这些问题引起大家的共鸣：
是否知道重要的业务，该页面是可以正常服务于用户的？
能否在问题还没有大规模爆发之前，快速的感知到业务的异常？
怎么不去用户的电脑上就能直观的看到问题所在，从而俯瞰项目全局；能否从宏观到微观一路下钻快速的定位线上告警信息？
在跨部门沟通时拿出合理的证据，来告诉他这个时间段该接口就是无法访问的，并告知我们的参数传的很正确，帮助服务端反查问题。
产品和设计同学想要提升用户体验，研发不断迭代功能版本。那这些我们以为的优化点，效果究竟如何？怎么去衡量？
哪个广告位，哪个资源位更有价值？怎么能更为精准的触达用户痛点，为提升业务赋能？
我们看到这些疑问，都需要数据指标的支撑。从解决这些问题的角度出发，把反复出现或无法跟其他部门交代的问题，打造成可以帮助我们解决问题的产品。
所以在这种场景下，易车·前端监控应运而生。
它主要是多场景多维度实时的监控大盘，实现浏览器客户端的全链路监控，方便团队事后追查和整改，转变为事前预警和快速判定根因。
经过详细的规划以后，我们把前端监控分为四期，分别为：异常监控（一期）、性能监控（二期）、数据埋点（三期）、行为采集（四期），于 2020 年 6 月 23 号正式启动研发，目前处于二期阶段。
关键结构为实现上述需求，监控系统主要分为四个阶段来实现；分别是：指标采集、指标存储、统计与分析、可视化展示。
指标采集阶段：通过前端集成的 SDK 收集请求、性能、异常等指标信息；在客户端简单的处理一次，然后上报到服务器。
指标存储阶段：用于接收前端上报的采集信息，主要目的是数据落地。
统计与分析阶段：自动分析，通过数据的统计，让程序发现问题从而触发报警。人工分析，是通过可视化的数据面板，让使用者看到具体的日志数据，从而发现异常问题根源。
可视化展示阶段：通过可视化的平台；在这些指标（API 监控、异常监控、资源监控、性能监控）中，追查用户行为来定位各项问题。
随着统计需求的增加以及前端应用的上线，数据量由早期的每天 100 多万条数据；到现在的每天约 7000 万条数据。架构上也经历了三次版本的迭代。这是最新版的架构图，主要经过 6 层处理。
采集层：PC 和 H5 使用了一套 SDK 监听事件采集指标，然后将监听到的指标通过 REST 接口往 Logback 推送数据。Logback 以长连接的方式，会把这些不同类型的指标数据推送到 Flume 集群当中。Flume 集群会将这些数据，分发到 Kafka Topic 进行存储。
处理层：由 Flink 去实时消费；Flink 会消费三种类型，分别是：离线数据落地、实时 ETL+图谱、明细日志。
存储层：离线数据会存储到 HDFS 中；实时 ETL+图谱数据会存储到 MySQL 中；明细数据会落入到 ES 中。
统计层：离线（DW、DM）、实时（分钟级->十分钟级->小时级）的方式，对指标进行汇总和统计。
应用层：最后由接口去汇总表和明细 ES 里查询数据。
展示层：然后前端输出图表、报表、明细、链路等信息。
采集最初的愿景是希望对业务无侵入性，业务系统无需改造，只需要嵌入一段代码即可。所以这些采集，都是 SDK 自动化的处理。
SDK 会全局监听几个事件，分别为：错误监听、资源异常的监听、页面性能的监听、API 调用的监听。
通过这几项监听，最终汇总为 3 项指标的采集。
异常采集：调用 error/unhandledrejection 事件，用于捕获 JS、图片、CSS 等资源异常信息。**
性能采集：调用浏览器原生的 performance.timing API 捕获页面的性能指标。
接口采集：通过 Object.definePropety 代理全局的 XHR 用于捕获浏览器的 XHR/FETCH 的请求。