为何前端定位问题很困难

前端同学对此肯定深有体会，代码发出去之后，犹如脱缰的野马，运行在万千的客户终端上，等到产品和后台反馈问题到我们这边，很多时候定位问题只能靠猜，尤其是一些偶发诱因，因为根本不知道用户是如何操作的，真实环境遇到的问题通常是很多随机因素叠加的形成的，因此很难回放用户的操作来还原现场找到原因。这个时候，我们想，如果有一个像后台一样详实的可分类和检索的运行日志，无疑将会提供巨大的帮助。

应用场景

• 回放用户细节操作

  真实应用场景下，用户的行为可能是不可预料的，甚至用户自己也无法记得自己的操作，有了日志，我们有了回放用户操作和代码运行状态的能力。

• 核心流程监控

  在产品的一些核心流程中，我们可以在用户出错的情况下主动上传用户日志，以便我们可以快速统计和定位用户遇到的问题。

• 主动抓取用户的日志分析用户行为

  有时候在用户不配合开发人员的时候，我们可以设计一种策略，比如我们在线上发布一个json文件，里面配置一个希望主动抓取日志的用户列表，当我们的产品在用户手机上被打开后，延时下载（避免影响主流程性能）这个json，当匹配当前用户时，直接主动上报该用户的日志。

• 统计和辅助分析JS错误

  我们可以记录js的报错，包含调用队列一起记录，直接上传此错误日志或者在累计达到一个阈值的时候统一上传。

特性

• 零外部依赖
• 客户端存放（需要时再获取，节省移动带宽、流量和连接数）
• 多维度过滤（命名空间、日志等级和关键词）
• 多个存储方案（Websql、localStorage和IndexedDB）
• 可清理（防止日志过多，占用上传带宽和占满用户允许的内存）

1.安装

npm install logline

2.引入脚本

Logline 支持直接使用 script 标签引用，也支持 AMD 模块加载器。

// Script标签引入方式
<script src="./mod/logline.min.js"></script>
// AMD模块方式（如requirejs）
var Logline = require('./mod/logline.min');
// CMD引入方式（使用npm安装）
var Logline = require('logline');
// ES6引入方式（使用npm安装）
import Logline from 'logline';

3. 选择日志协议

目前一共支持三个协议， 三个协议都被直接挂载在Logline对象上以便一些特殊的应用场景，也更好的符合语义化:

• websql: Logline.PROTOCOL.WEBSQL
• indexeddb: Logline.PROTOCOL.INDEXEDDB
• localstorage: Logline.PROTOCOL.LOCALSTORAGE

你可以在引入Logline之后，使用 using 主动选定一个期望使用的日志协议。

Logline.using(Logline.PROTOCOL.WEBSQL);

链接: https://fly63.com/nav/2721