第五期 | 前端监控怎么玩？

2020.4.25 前端如何搞监控

场景

搭建平台开发的组件太多，实际上不少功能相似，须要监控组件在一类场景下效能如何
组件监控的指标

• 引用量，引用次数高对此组件的优先级也高
• 曝光点击率： 引导转化率 = 引导成交量/点击量/曝光量
• 数据接口： 加载时间、组件异常、白屏率
• 配置复杂度：好比输入转选择类型，预设默认值，减小用户配置时间
• 代码质量：编译过程当中，ESlint上报不合规

App、小程序监控
监控目的：

• 有没有人用
• 用的怎么样
• 有什么异常
• 如何跟踪
• 分析解决
• 提供决策

工具
以宋小菜为例：
----
初版

• Countly: 针对RN应用
• 友盟：针对原生APP

第二版

• BugSneg 针对RN
• MongoDB 数据存储
• RGB 基于Koa自建

第三版

• 采集SDK 自研平台
• Filebeat 节点 Node Transfer 作日志采集转发
• Kafka集群作分布式消息通讯
• ES(ElasticSearch) 日志处理
• Datawarehouse 下沉到数仓
• Reports 大表哥报表平台
• MySQL/Redis Task存储

系统架构
----
客户端： PC/H五、RN、小程序
日志处理： log-transfer、Filebeat、Kafka集群、ElasticSearch
数据处理： Data Warehouse、监控系统后台
数据展示：可视化报表平台、监控看板

为何本身研发

以贝贝举例：
假设有80个工程项目，每一年须要支付28W左右监控费用 > 本身研发成本
业界方案对比（有必定偏差，仅供参考）：

监控步骤

根据业务咱们能够看到主要有两种场景，

• 一种是用于广告营销类的，分析用户行为造成用户画像
• 另外一种主要是对本身系统作的错误监控，

这两种场景的步骤也是不一样的。

用户监控： 埋点-> 采集 -> 计算 -> 分析
错误监控：错误收集-> 错误上报 -> 数据清洗 -> 数据持久化 -> 平台可视化、监控

错误监控实现层面来自贝贝的 Allen 讲师已经讲的很详细了，我这里用脑图整理了一下。
Web端错误监控脑图：

其余端

上面这套闭环的Web端监控，在其余端怎么用？其实主要是在第一层应用接入去作文章。
思路： 差别化采集、格式化上报

错误捕获以及代码实现

JS端：
错误捕获： ErrorUtils、Promise.rejection Tracking
网络请求： 替换XMLHttpRequest, 代理 send/open/onload 等方法

Native端：


微信小程序：
网络请求：代理全局wx的wx.request对象

代码实现：

React 端：

为何选择ES和Mysql?
存储介质对比：


接下来是对营销、广告场景的监控分析：

埋点

监测用户行为、事件、留存 -> 上报数据，能够分红下面几个级别：

• 站点级别
• 页面级别
• 组件级别
• 组件内部连接级别

采集

采集哪些数据

• 用户行为数据： 用户页面操做、页面跳转、窗口事件
• 错误数据： 后端接口、前端JS错误 AppNative错误

经过单个页面咱们能够得到的一些结论：

• 用户地域分布
• 在线时长
• 按钮点击率
• 页面来源分布：内链、外链、搜索引擎
• 广告位点击率：点击次数/曝光次数
• 日访问量趋势

如何采集用户停留时间？

1. 使用置信区间，过滤异常数据。以下图能够看到有些平均时长不是很能表现用户停留时间，采用中位数效果会好些

2. 采用柱状图展现用户停留时长

怎么采集事件？
鼠标、滚动、键盘、自定义事件
具体实现：

• sendBeacon方法 确保事件被发送
• 兼容IE用户， 发送请求
• CORS 发送post请求批量上报

怎么将采集到的数据转换为人能够理解的指标？
流程：搭建指标体系 -> 获取数据 -> 数据分析 -> 具体到应用场景

举例1：用户登陆或者游客访问

三个框对应 浏览器数据、事件数据、用户数据，自动生成uuid,和userid关联，将 uuid 和 userid 存储到cookie

举例2：用户跳转

跳转时记录来源， 项目ID、页面ID、区块ID、坑位下标、串联ID，
在下个页面，从URL获取utm值。而后进行页面上报

计算

数据清洗案例：

分析

怎么分析？
针对用户采集能够采用阿里云 Log Service，主要功能是查询和统计

分析什么？


如何分析基础数据 PV、UV、点击数、曝光数
使用漏斗模型，分析转化率 
用热力图分析页面
经过漏斗和路径分析来分析转化率

遇到的坑

iOS符号化

符号化后去除了大量版本间的差别，对错误聚合提供了方便

错误聚合

初级聚合： 全内容散列，聚合度低

将错误直接MD5散列， 这样聚合度会比较低，
通用优化：

• 同一类错误 错误名和错误堆栈是相同的
• 系统类行号去除，减小不一样系统版本致使的堆栈不一致（用正则找到系统类，而后去掉行号）

而后对这些信息进行散列

针对优化：
同一类错误，有时候客户端不一样系统版本之间的系统
解决： 抽取业务代码堆栈和业务名称来散列
OOM错误，堆栈溢出
这一类错误，直接拿到错误名聚合，而后分析在哪些设备上容易出现

向ES中写入 JSON 类型数据

数据量较大，全部数据并不是写在一个索引中，这个时候须要按时或按天创建索引保存数据
同时，须要创建一个固定的索引模版，索引某一字段的数据类型必定要统一，不然会形成数据保存失败的状况。

字段问题：
哪些字段不变，哪些字段动态会变化的，须要设计系统时进行衡量，保持适度的灵活。
变化的字段集中在 pyload 信息，其余类型字段都是固定的，好比：

• 设备特征：如系统类型、版本
• 用户特征：如userId, ip、用户所在地
• SDK信息:SDK类型、版本等

字段字符化处理：
若是使用JSON类型进行上报 且在ES中依然保存为JSON数据，虽然存在索引模版，但在模版没有照顾到的字段上报上来会生成新字段，于是形成字段数量爆炸、这时候就可使用log-transfer 

第三方推荐

• 友盟
• 数极客
• 神策
• GrowingIO
• Fundebug
• FrontJS
• Sentry

......

回顾

因为后面还有事情，因此今天的活动没有听完，只对我听过的一些进行了整理。
从业务上来看，监控的场景分为错误监控和用户行为监控，固然还有阿里更复杂的组件级别、场景级别的监控（目前遇不到）。同时学习了一些监控实现的步骤、像埋点、采集。清洗、分析以前都是没有接触过的。
贝贝的两位讲师内容很接近落地方案，后续PPT还得多看看，若是有这方面的需求也会更多的去了解。

关于前端早早聊大会：前端早早聊大会目标成为用得上、听得懂、抄得走的技术大会，计划 2020 年办 >= 15 期，由前端早早聊与掘金联合举办，前端早早聊大会行程动态、录播视频/PPT/讲稿资料下载请关注 「前端早早聊」 公众号跟进。

5 月 16 日举办第六届 - 前端到底怎么玩 Serverless(Paas|Faas)，报名请戳：huodongxing.com/go/tl6，海报及讲师行程以下：

看完如有启发，给做者点个👍吧