前文已经解决了采集数据的问题了,但是采集到的数据不做分析是体现不出价值的。接下来会介绍 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 检查每一条日志是否需要触发报警。报警方案主要有两种:
报警可以通过邮件、短信渠道通知到对应的人。
报警需要解决重复报警,有几种情况:
针对上面三条,其实处理起来也不是非常复杂:
上图中的有些特殊时刻数据量会偏高,经过一段时间的数据沉淀,在这个时刻不会再触发报警了。
当你收到一个报警之后坑定会想知道发生了什么。
如果你是自己打的日志,那很清晰明了,不用担心找不到问题。
比如这样:
如果你收到的错误是这样:
那可能你会头疼一下了,这个是压缩后的代码,完全看不明白这是什么报错。定位压缩后的代码肯定需要祭出 sourceMap 这个神器了。
在我们已知文件、行号、列号的情况下,通过 sourceMap 就可以拿到还原后的代码了。如下图,进入一个报错的时候会定位到某一列。
JSTracker 做为一个报警系统,最理想的情况就是它默默的在后面运行就好了,大家都不知道他存在是最好的了。但是一旦有报警还是需要有页面可以查看,界面上直接用 Bootstrap 加上开源的图表组件基本就可以了 。