-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
对于init里面的repeat参数 #31
Comments
所以这里并没有根据 repeat 去重。 |
|
repeat 的初衷是防止单次访问中出现过多的重复上报,例如setInterval 或则 用户重复操作一个操作引起的上报, 这样会造成错误出现大量的暴增,引起我们优先处理此错误,而这个错误其实优先级没有这么高。 假如页面已经刷新,会当作是全新的PV 处理错误排重, 刷新页面越多,说明用户在此页面的操作欲望越高,这个错误就会排在前面,我们就会即时处理。 通常来说。 用户访问一个页面。 刷新的频率是很少的,除非 出现了错误或则网络慢才会不停地刷新。 @penglinjiang 不知道这样对 repeat 解释是否满意 |
|
嗯,您这样解释是合理的。我之前之所以提出那样的疑问,是因为我们的网站在使用badjs-report捕捉到错误并上传之后会立马通过cc进行推送通知,所以只要有报错就会有同事去解决了,所以基于这种解决方式的话,感觉重复推送就没有意义了,现在感觉前端报错还是很频繁的,所以我们后来也改为上传统计了 @caihuiji |
有一个问题,对于日志去重的处理:
1.repeat参数貌似对离线日志不生效,离线日志会存入重复的日志信息,上报离线日志的时候貌似也没有去重,感觉这样会导致重复上传大量相同错误日志;
2.repeat参数去重是通过一个全局对象_log_map实现的,如果刷新页面,则会重新new 一个_log_map对象,刚才已经达到重复上线的话,刷新之后又会进行上报。
建议:以上两个问题感觉可以统一处理,上报info的时候即实时上报的时候也会存入离线日志,存入时去重存储,根据indexdb里面的是否有该类型的错误进行选择上报,有且数量已达上线,就不在上报
The text was updated successfully, but these errors were encountered: