Taobao FED

JSTracker:异常数据处理

JSTracker:异常数据处理

上一篇:JSTracker 之前端异常数据采集

前文已经解决了采集数据的问题了,但是采集到的数据不做分析是体现不出价值的。接下来会介绍 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的历史基线(蓝色)

历史基线数据学习

上图中的有些特殊时刻数据量会偏高,经过一段时间的数据沉淀,在这个时刻不会再触发报警了。

报错定位

当你收到一个报警之后坑定会想知道发生了什么。

如果你是自己打的日志,那很清晰明了,不用担心找不到问题。

比如这样:

自己打的日志

如果你收到的错误是这样:

onError采集到的报错

那可能你会头疼一下了,这个是压缩后的代码,完全看不明白这是什么报错。定位压缩后的代码肯定需要祭出 sourceMap 这个神器了。

在我们已知文件、行号、列号的情况下,通过 sourceMap 就可以拿到还原后的代码了。如下图,进入一个报错的时候会定位到某一列。

sourceMap还原

数据展现

JSTracker 做为一个报警系统,最理想的情况就是它默默的在后面运行就好了,大家都不知道他存在是最好的了。但是一旦有报警还是需要有页面可以查看,界面上直接用 Bootstrap 加上开源的图表组件基本就可以了 。