探针加载有两种方式，他们分别有一些优缺点：
同步加载：采集 SDK 放到所有 JS 请求头的前面；因为加载顺序的问题，如果放在其他 JS 请求之后，之前的 JS 出现了异常，就捕获不到了。因为要提前加载 JS 资源，会对性能有一定影响。
异步加载：采集 SDK 通过执行 JS 后注入到页面中；如果能保障首次的 JS 无异常，也可以使用异步的方式加载 SDK，对首屏优化有好处。
目前我们采用的是第一种同步加载的方式。
产品部分截图 首页首页会展示所有应用的情报，在首页可以直观的发现各应用的异常数据。
如果想对某个应用细项的排查，会进入到应用的大盘页面；
主要会展示该应用，前端的重要性指标，近一个小时内的数据状况。
目前主要有页面性能、资源异常、JS 异常、API 接口成功率等重要指标作为衡量。
详情页，就可以看到该应用某项指标的数据细项。方便团队进行事后的追查、整改，提前预警和快速判定根因所用。
SDK 采集到指标以后对数据进行上报时，会做一些过滤性的前置操作，如：
屏蔽掉一些黑名单。
指标的削峰填谷。
应用信息的转换。
客户端 IP 获取。
Token 的验证。
前置处理有一个弊端，因为服务器会经过解析转换环节；当数据量达到每日 7000 万左右，上报的服务器就扛不住了。
所以我们把数据前置处理，变为数据落地后置处理；后置处理就是在数据清洗的过程中，在过滤掉黑名单以及异常指标。这样就减轻了上报服务器的压力。
并且仓库也会保留所有的原始数据，如果出现异常的时，也方便我们溯源，对数据进行恢复。
我们分为了四期，目前还处于二期性能监控阶段。
计划 目标 优先级 支持平台 主要解决的问题点一期 异常监控 高 PC、Mobile、小程序 异常影响的影响用户，资源加载异常感知，网络请求异常感知，代码报错异常感知，代码报错的细项（SourceMap）分析
二期 性能监控 高 性能值（首字节、DOMReady、页面完全加载、重定向、DNS、TCP、请求响应等耗时），API 监控（成功率、成功耗时、失败次数等），页面引用资源统计，和资源占比（JS、CSS、图片、字体、iFrame、Ajax 等），位数对比，95% 的用户、99% 的用户、平均用户
三期 数据埋点 中 操作系统、分辨率、浏览器，事件分类（点击事件、滚动事件），具体的指定的事件类型（点击 Banner 图），事件发生时间，触发事件的位置（鼠标 X、Y，可生成热力图），访客标识，用户标识，链路采集
四期 行为采集 低 进入页面，离开页面，点击元素，滚动页面，操作链路，自定义（如，点击广告位的图），Chrome 插件直观看到埋点
其它