（注：上图为 JSTracker 的系统流程图）
上一篇： JSTracker 之前端异常数据采集
前文已经解决了采集数据的问题了，但是采集到的数据不做分析是体现不出价值的。接下来会介绍 JSTracker 的数据处理部分。
大概会按照以下目录：
- 服务端如何接受数据
- 数据存储
- 报警
- 定位
服务端如何接受数据
日志上报需要服务端提供一个 http 接口，将前端采集到的数据统一的发回服务端。
需要注意的是如果你用 GET 请求发送数据，那么 URL 的长度是有限的，建议的安全值是2000（ 没有对所有的浏览器测试，最低的是 IE ）。
如果你需要上报的数据量特别大可以考虑用 POST 请求。
接收到的数据原始数据解析
在 JSTracker 中，服务端采集到日志之后，提供了一个接口可以读取数据流。 这个接口是一个队列，队列的生产端不停地采集数据，队里的消费端就是 JSTracker。
只要消费数据的速度足够快就能接近实时的获取到上报的日志。
拿到的日志我们需要对数据进行基础的加工，比如把原始浏览器信息解析分类（当然这一步其实也可以在采集数据的时候做掉）。
对于前端来说，用 Node 无疑是最好的。JSTracker 对日志的分析压测能够到900 QPS （用的是一台8核16G的机器测试）。
数据存储
虽然进行了数据采集的抽样，但是数据的大小还是会达到每天亿级别的数据。对于前端来说熟悉的 Mysql、Mongo 等等方案已经不能满足这么大的读写了。
最初的时候的时候 JSTracker 是使用的 Mysql ，但是单机写入速度和查询速度都无法满足需求，后来找到了开源方案基于 levelDB 的 SSDB （ https://github.com/ideawu/ssdb ）。如果你的服务托管在阿里云还可以考虑使用阿里云的 OTS ( http://www.aliyun.com/product/ots/ )。
报警
JSTracker 会基于 Midway 检查每一条日志是否需要触发报警。报警方案主要有两种：
- 默认方案：会基于影响用户数、PV、历史数据做判断，阈值会设置比较大。实际应用中会动态的调整这个阈值
- 绝对值方案：有些报错是0容忍的，那么会设置这个错误在达到一定次数直接报警，比如设置在10min内超过10条日志就报警
报警可以通过邮件、短信渠道通知到对应的人。
报警需要解决重复报警，有几种情况：
- 如果这个 URL 是初次接入，由于没有历史基线数据，会不会直接触发报警
- 如果一个报警触发了，那么如何避免连续报警
- 如果一个峰值是历史常态，如何让系统认识到这是一个常态，不是异常
针对上面三条，其实处理起来也不是非常复杂：
- 初次接入的 URL 由于没有基线，那么不报警，除非它超过了一个很高的特殊阈值
- 一个报警发生了，会有一条报警记录，要出发报警之前检查一下这个数据就能避免重复了，JSTracker 会在 1 小时内部重复报警
- 由于我们是比较历史基线数据的，大约一段时间后基线数据就会变得和这个数据一致了（木有涉及机器学习，这个还不必要），比如下面某URL的历史基线（蓝色）
上图中的有些特殊时刻数据量会偏高，经过一段时间的数据沉淀，在这个时刻不会再触发报警了。
报错定位
当你收到一个报警之后坑定会想知道发生了什么。
如果你是自己打的日志，那很清晰明了，不用担心找不到问题。
比如这样：
如果你收到的错误是这样：
那可能你会头疼一下了，这个是压缩后的代码，完全看不明白这是什么报错。定位压缩后的代码肯定需要祭出 sourceMap 这个神器了。
在我们已知文件、行号、列号的情况下，通过 sourceMap 就可以拿到还原后的代码了。如下图，进入一个报错的时候会定位到某一列。
数据展现
JSTracker 做为一个报警系统，最理想的情况就是它默默的在后面运行就好了，大家都不知道他存在是最好的了。但是一旦有报警还是需要有页面可以查看，界面上直接用 Bootstrap 加上开源的图表组件基本就可以了 。
搞个gitee的项目
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
