本文部分内容和截图内容都来自以下第五届前端早早聊大会分享 总结笔记

本文是会议总结文章，可能会有点大乱炖的感觉。

监控步骤：定制规范，埋点 > 采集 > 计算 > 分析

数据埋点的业务价值

• 平台迭代数据抓手，降低咨询量
• 解决高频问题，提升用户满意度
• 解决业务痛点：我的会场效果如何？不好该如何调优？调优过程是否高效？经验是否可以复用？

面向场景做监控：

• 精细化运营（偏好敏感、人群身份）——>场景度量

• 解决心智难以划分：圈选逻辑没有约束，场景重叠度高，同质化严重 >>> 商品&人群下钻、重叠度报告、心智报告
• 数据指标波动问题：运营干预波动数据难体现，分析成本高，打击分析积极性>>> 场景组配置、趋势报告、场景报告
• 流量公平问题：流量越多的场景就有更多的曝光机会，运营同学都想要流量，流量给谁>>> 生成场景分配报告

埋点规范

超级定位模型

（super position model)

• 站点级别 spma
• 页面级别 spma .spmb
• 组件级别 spma .spmb .spmc
• 组件内部链接级别 spma .spmb .spmc .spmd

数据采集

采集方式

采集方式有：进入、离开、点击、滚屏、代码植入

进入

• 通过编译植入项目ID，进入页面生成页面ID，比如 data-utm-c="区块ID"
• 代码侵入：坑位ID、区块ID data-utm-click="坑位ID1"

举例生成的配置文件：

事件委托到 document，一般的事件类型：mousedown、touch、scroll、keydown

设置埋点参数：进入页面的时候，可以在URL 后边加入生成唯一标识的串联ID，在链接点击跳转时，可以依据标识上报。

< href="http://giscafer.com?utm=项目ID.页面ID.区块ID.坑位index.串联ID"/>

滚屏

监听 scroll 事件处理一些需要上报的场景，要处理好触发次数。

离开

使用 Send Beacon 避免离开页面时请求被终止，保证数据上报正常发送。缺陷：IE浏览器不支持。IE的话改用 发送发送。

无埋点采集情景

比如商场的收藏、加购、spm链接跳转等这种逻辑下自动采集数据

自定义植入代码

手动埋点，事件触发上报等

组件监控

任何页面都可以拆分成组件（React 的思想：以组件的方式考虑UI构建），所以监控可以结合组件来做。当组件渲染异常时，可以监控到哪个地方出问题。比如聚合组件在业务组件中的统计效能：曝光量、点击转化率、加载性能、渲染性能、数据性能、应用次数、失败次数、代码质量。

多端统一采集

• 规范化采集字段（日记上报规范）
• 统一采集方案
• 业务自行上报 （前端只负责埋点）

问题

• 如何保证数据收集时不影响业务系统的性能？

个人觉得可以用相关的技术点来解决前端可能影响到页面性能的问题，比如：Web Worker、requestIdleCallback 等，但后端的服务稳定性是否能保证需要关注吗？

• web页面 beforeunload 数据丢失的问题，页面奔溃就没法收集了

除了 Send Beacon 外，可以考虑 Service Worker 来配合做？页面奔溃前定时器处理做标记，下次打开页面对比对应值来判断是否页面奔溃过。

• 网络问题是否上报？

记录但不处理，不进行报警

数据清洗

数据分析

数据分析本质就是将监控到的数据可视化展示，或是转化为大家可以理解的概念，指标数据。使用过站长统计、比如 Google Analytics 和 百度统计、CNZZ 等，他们的统计管理后台，展示给“站长”可视化的指标数据就是通过数据分析得来的。

实现思路/方案：

• 获取到网站页面的基础数据，如 PV、UV、点击数、曝光数 来通过公式规则（如功能有序页面漏斗）来计算转化率、跳出率、平均使用时长等

数据应用

得到指标分析的结果，可以用来分析存在的问题，改善网站，通过转化率来促进义务。，也可以研究用户习惯和发现趋势，提供一些自定义设置功能帮助更好的做到分析。

将监控数据通过各种图表工具来展示分析结果。

功能展示（监控看板）

• 指标波动图（UV、PV等）
• 热力图
• 访问来源、时长、跳出率分析
• 用户活跃、留存、地域分布、终端类型
• 心智报告图表统计
• 报表统计、日记报告、错误报告等
• 实时信息看板
• ……

如何针对 APP 自建前端监控体系（宋小菜）

详细见 《如何针对 APP 自建前端监控体系》PPT

《如何针对 APP 自建前端监控体系》

RN SDK

• JS 端

• 错误捕获
• 网络请求
• 页面跳转

• Native 端

• IOS 使用 KSCrash
• 存储捕获到的数据（包括 JS 端和 Native 端统一上报）

微信小程序 SDK

• 网络请求：代理全局对象wx 的 wx.request 的方法
• 页面跳转：覆写 Page 对象，代理生命周期方法

Log 处理

监控看板

• 实时P/UV 查看
• 实时错误查看
• Issue查看、分配和统计
• Issue 分类
• Issue/task 更新历史
• 报警任务查看和编辑
• ……

报警控制

• 更新报警任务
• 分发报警任务

• 常用报警任务，主要用于发现以及生成新issue
• 特定报警任务

• 更新任务执行结果

eg: 常规任务

• 根据任务执行规则而分发嗅探上报的错误信息的报警任务分给任务执行器，在任务执行结果返回之后将值归类并根据错误信息特征生成issue

任务执行

• 执行报警任务
• 多结点分担任务压力

《如何搭建一套多端错误监控平台》（贝贝）5☆推荐

详细见 《如何一套多端错误监控平台》PPT，该分享根据具体实现逐步讲解，比较接地气和清晰，点赞。

为什么自研

稳定性、一致性、扩展性、安全性和成本综合考虑

实现

架构图

Web端错误监控的实现

一、SDK——错误收集/上报

AOP 面向切面编程，改写原有行为

1、SDK 设计

2、错误捕获机制

• window.onerror： 运行时错误监听
• 监听unhandedrejection 事件：promise 没有 catch 错误场景
• try/catch 处理跨域脚本错误： Script error.

• 方案1：后端配置 Access-Control-Allow-Origin、前端 script 标签配置 crossoriign
• 劫持原生方法，使用 try/catch 绕过，将错误抛出

• 技术栈错误捕获方式：原生js 就是 addEventListner、Vue errorHandler、React 是 componentDidCatch

3、环境信息收集

4、行为收集

行为分类

• 用户行为：点击、滚动、聚焦/失焦、长按等；
• 浏览器行为：发起请求、跳转、前进后退、关闭、新开窗口等；
• 控制台打印行为

5、数据上报

5.1、数据上报方式

Q: 为什么用 1x1 像素 gif 图？

• 没有跨域问题；
• 发 GET 请求之后不需要获取数据、服务器也不需要发送数据；
• 不会携带当前域名 cookie !
• 不会阻塞页面加载、影响用户体验，只需要 new Image 对象；
• 相比 BMP/PNG 体积最小，可以节约 41%/35% 的网络资源大小。

6、总结

监听/劫持 原始方法，获取需要上报的数据，在错误发生时触发触发函数会用 gif 上报。

二、数据清洗

数据特征：

• 数据量大、体积大
• 没有分类、聚合
• 没有对非法数据进行过滤

1、存储介质对比

2、清洗流程

详情见会议PPT

ES——>获取数据——> 数据预处理——>数据聚合（为了存储小、查询快）

SDK 实现 之 Node 篇

捕获机制

Node 端使用 process 对象监听 uncaughtException、unhandledRejection 事件，捕获未处理的 JS异常 和 Promise 异常。

SDK 实现 之 Weex 篇

捕获机制

SDK 实现 之 小程序 篇

捕获机制

全局函数 onError

环境信息的收集

原生客户端上报

不借助 sdk， 使用系统提供方式

1、Android 错误上报机制

使用 系统提供 的机制，实现
Thread.UncauhtExceptionHandler 接口，通过 uncaughtException 方法获取崩溃错误信息，在应用初始化时替换掉默认的崩溃回调。

2、IOS错误上报机制

使用 系统提供 的错误捕获机制，注册了 Objective-C 异常和 POSIX signal 的处理钩子，在发生崩溃的时候可以通过钩子函数记录崩溃的信息。在下次启动APP 的时候再上报。

更多见会议分享PPT