关于前端:聊聊前端日志库在-SaaS-产品中的应用与设计

文 | 元三 网易智企资深前端开发工程师

一、前言

笔者所在的公司业务次要是为企业提供全流程的企业服务和一整套 SaaS 解决方案。对于企业服务 SaaS 产品来说，客户实现购买并不意味着产品价值曾经齐全交付，因为客户在首次购买产品时，往往须要通过一系列培训并应用后，能力真正产生价值。因而从实质上来看帮忙客户解决在应用过程中呈现的问题是 B 端产品中提供的有偿服务，是产品价值链条中十分重要的一环。

本文将着重介绍开发者排查客户反馈问题这个场景下前端日志库的利用，以及如何设计开发实用于此类场景的前端日志库。

二、SaaS 业务下前端面临的挑战

笔者以前是做 C 端业务出身，人造带着 C 端业务的思维，感觉前端把产品交互体验做到极致就够了。当我这个做法套用到做 SaaS 业务上，着实吃了不少亏。B 端产品和 C 端产品在付费形式的差别、购买决策人和理论使用者不同、产品用处不同（B 端客户购买产品的根本原因是为了帮忙企业赚钱，C 端产品购买决策有可能只是一时冲动好玩），导致 SaaS 企业经营关注的指标和 C 端产品存在较大差别，间接导致了对研发侧的导向不同。C 端业务前端在研发资源投入上可能为了用户体验不计成本，优化网页性能以晋升用户粘性，体现在挪动互联网、电商等行业往往关注 DAU、MAU、GMV 等量级指标。B 端产品的外围关注大部分是否 帮忙客户晋升效率 ，产品是否帮忙客户达成他的工作指标、是否帮他疾速达成指标比产品界面是否好看重要得多。掂量一家优良的 SaaS 企业有一项比拟重要的指标——NDR（支出留存率），对 SaaS 业务的前端开发来说，首要解决的挑战来自如何通过软件研发工作去晋升产品 易用性 、 工作效率 、 服务效率 等指标，从而为企业带来进步 NDR 的分子（存量客户的续费 + 增购）的成果。

B 端和 C 端比照

值得一说的是，在这方面《云计算软件产品应用体验品质 度量模型及度量办法》也提出 5 项指标维度用于掂量产品应用体验，十分具备参考性。这些指标维度包含 易用性 、 工作效率 、 满意度 、 一致性 、 页面性能 。其中易用性包含易操作性、易学性、清晰性，工作效率包含性能利用率、工作完成率、工作实现耗时。基于 SaaS 产品支出可持续性的考量，SaaS 企业的指标之一是进步依附软件产品输入价值的比重，升高依附人工服务输入价值的比重，因为只有软件产品输入价值边际老本最低，能力一直晋升产品服务效率。在这一点上，纯正依附人工服务终归是边际老本十分高的，因而在 SaaS 业务场景下依附技术创新去 晋升解决问题的效率 是前端可能提供的十分大的产品价值。

三、如何解决客户反馈问题

当咱们把视角汇集到客户反馈问题的解决上时，能够先将客户反馈问题分为性能征询类、问题报障类、售前征询类。其中开发者次要关注的是问题报障类，也存在一些技术支持答复不了的性能征询类问题会流向开发者，针对这类问题个别能够采纳建设外部的问题排查零碎来解决。其中前端开发者次要遇到的反馈问题既有来自于 SDK 接入这一类的征询，也有客户认为产品性能不合乎预期的问题报告。

针对此，前端为了无效且疾速定位这些问题起因，一方面能够在客户端打日志并上报到问题排查零碎之中，另一方面，对于 S 类 A 类客户（基于 SaaS 企业针对客户企业规模的分层模型）的紧急问题，如有必要能够迅速和客户沟通，应用近程帮助之类的工具在客户的设施中复现并定位问题起因。对于后者，咱们设计开发了基于 Chrome 浏览器 Chrome DevTools 协定的 近程调试解决方案 woodpecker-remote，它可能反对网站开发者对网站用户的 Chrome 浏览器间接进行近程调试。对于前者来说，咱们设计开发了 前端日志库 woodpecker-log 以反对将客户端运行状态等信息进行长久化存储供开发者调试排查问题。

四、前端日志的概念

这里先介绍一下前端日志的概念。通常来说个别在后端开发时常常会听到日志的概念，对后端来说日志是指一种用于记录服务端启动、运行状态的文件。这里的前端日志指的也是用于记录客户端运行状态在客户端存储或者上传到服务器存储造成的日志文件。个别前端在开发、测试环境应用 Console 记录运行状态就够了，但在生产环境就须要将客户端日志信息发送到服务端存储起来，不便日后排查定位用户反馈问题时应用。

五、传统的前端日志存在的问题及挑战

1. 前端日志库普及率不高，感知差，和异样、性能监控等各自林立。
2. 打日志不标准，各种日志格局乱象丛生。
3. 日志库自身占用前端性能估算，在性能方面须要思考尽量减少对 JS 主线程占用开销，保障主线程尽量闲暇。一部分前端日志库在服务器端存储日志，日志产生后须要即时上传到服务器，需占用带宽，并挤占浏览器同域名申请最大并发数，从而拖慢失常业务 Ajax 申请，须要均衡上报频率和每次上报日志大小。
4. 大型利用（如千万、亿级用户数的利用）容易产生巨量日志，日志与 Bug 之间存在的关联度低，检索和剖析操作老本高，如应用 Elasticsearch 存储海量日志，kibana 查问效率低。
5. 日志开发及部署不不便，这里有一些问题，前端开发者须要提前在代码中预埋打印日志的代码。否则，当须要定位问题的时候不存在相干的日志无奈进行剖析。
6. 日志库短少问题的上下文，无奈对一个残缺的会话进行追踪。如不反对记录用户拜访页面产生问题前后的用户界面交互操作记录，以及页面跳转等行为轨迹。
7. 问题反馈链路长，如果不能和产品深度集成则容易在反馈链路两头失落线索，造成沟通老本高企，解决办法能够是在客户上报问题时主动带上以后的日志信息，关联外部的工单、Jira 等问题反馈解决零碎。

六、基于 B 端业务的前端日志库设计

上述问题中，首要解决的是日志和用户反馈问题相关度的问题。外围思路是应用客户端进行日志存储，在产生问题时由用户或者程序发现进行被动上报，而不是定时定频率上报到服务器。这里留两个问题：用户如何发现问题？程序（员）如何发现问题？另外，性能问题和 JS 异样也是产生客户反馈的问题起源之一，但从日常 SaaS 业务的客户反馈问题起源统计来看，这两块并不是次要起源。另外的 JS 异样监控、性能监控两个畛域曾经有比拟成熟的前端基建反对。因而，非 JS 异样和性能问题导致的客户反馈问题是前端日志库次要笼罩并解决的问题。

6.1 一些典型的须要记录前端日志的场景

首先在开始设计之前，先思考一下，前端会如何应用日志库。有这些典型场景可能须要前端记录日志。

1. 调用第三方服务，做最坏打算如果第三方服务不可用怎么办。
2. 性能估算很低、对性能十分敏感的页面，须要上报一些性能数据。
3. 须要重点监控的网页外围流程，应用 JS 断言后果为 false 时，须要记录断言失败起因。

对第 3 种场景，这里简略列了在程序断言为 false 时应用前端日志库记录日志的 Demo：

6.2 日志库 SDK 的可维护性

相比于几千行代码在繁多文件内保护，将 SDK 独立成我的项目并采取前端工程化形式开发更具备可维护性。前端工程化是指采纳模块化、组件化、规范化、自动化的技术计划从软件工程的角度解决工程的品质、可维护性问题。这里列举了一些 关键技术选型：

1. 编程语言

对于 SDK 绝对底层的代码来说，Typescript 语言人造提供的类型文档具备可读性和易读性，动态类型查看能够帮忙框架或库的使用者在代码运行阶段之前发现错误，智能语法感知能够提供有用的 API 类型提醒。

1. 构建

须要思考为 SDK 的使用者提供多种 JS 模块标准的反对，以 rollup 为例，配置如下：

1. 自动化测试

在开发阶段对 SDK 的自动化测试次要关注单元测试和集成测试。单元测试是用于对模块、函数或类进行正确性测验，能够采纳 jest 框架。值得注意的是，对 indexedDB 存储和查问进行单元测试时须要模仿数据库，能够应用 fake-indexeddb 来 Mock。集成测试的目标是将零碎之间的各个模块组装起来并应用真正的内部依赖、拜访真正的 indexedDB 数据库对代码进行正确性测验。此例中咱们采纳了 Karma + Mocha + chai 的计划，对 ChromeHeadless、FirefoxHeadless、Safari 浏览器进行测试。

1. 版本控制

基于语义化版本标准 semver 进行版本控制。

1. Demo 和文档

6.3 应用 indexedDB 在客户端存储日志

localStorage 适宜对大量数据进行 key-value 存储，在客户端日志存储的场景中应用 indexedDB 更加适合，它具备以下长处：

• 存储和查问结构化数据，反对二进制
• 反对事务
• 异步
• 解决大量数据

假设应用 10M 容量，300bytes 的日志，能够存 34952 条；最长反对循环录制 8 天日均 4369 条。

6.4 性能开销

• 网络性能（提早、申请失败率）——日志长度、申请体积

  • 应用独立域名服务器解决日志申请 Chrome 对同一域名的并发最大连接数限度
  • DNS 预获取 dns-prefetch

  • 日志存储前进行字符串压缩

    • 应用基于 Gzip 算法的 JS 实现 LZMA-JS，实测 Level6，300bytes，压缩率 79%

• sendBeacon

  • 数据牢靠异步传输，并且不会提早页面的卸载或影响下一导航的载入

• 合并申请

  • 合并多个小体积的日志分页上报，单页约 1M
• HTTP/2 头部压缩

• 运行性能

  • 全异步非阻塞式操作，存储、检索、上报
  • 保护存储队列反对批量日志存储操作

6.5 API 设计

SDK 初始化设置

实例办法

6.6 线上呈现问题，然而代码中没有打日志怎么办

咱们经常须要公布前就在代码中设计好业务要害流程执行时须要打印的日志。否则，当咱们须要定位问题的时候，才发现自己并没有输入相干的日志，这样就会比拟被动。此时只能长期改代码加日志，从新公布。有没有一种计划，能够在遇到问题的时候，再去代码中相应地位加日志，用户执行改业务流程时就能立即打印出相干日志，而不必从新走一遍公布流程。这里介绍一种在 woodpecker-proxy 中的实现，借助 MutationObserver 接口监听 script 插入 DOM 事件，改写浏览器 JS 申请，将其代理到指标服务器，从而实现在指标服务器批改 JS 退出日志代码即可在用户浏览器记录日志。Demo 地址：DEMO。

6.7 日志标准——分级别、分利用打印日志

遵循良好标准记录的日志，有利于排查问题时可能疾速依据信息级别、利用进行日志筛选。

分级别

分利用

因为客户端存储受同源限度，日志拜访只能在本身域名下进行。多个利用可能会在同一域名下记录日志，辨别利用名进行存储易于隔离不同利用的日志信息。

6.8 问题的上下文须要收集哪些信息

• 设施、浏览器、页面信息
• 关联一次会话的用户界面交互操作
• 关联一次会话的页面跳转

6.9 如何在收到客户反馈时疾速找到相干日志

1. 将用户 id、会话 id 存储到日志中并建设索引。
2. 将日志上报性能集成到 SaaS 利用，在客户反馈问题时主动查问以后会话日志并上报。
3. 在客户反馈问题时将用户 id、会话 id 写入到外部的工单零碎，提 Bug 时带到 Jira 零碎。

七、将来致力的方向

• 增强可靠性

  • 网页解体时如何保障前端日志库仍然失常工作，记录此时的日志？应用 Service Worker 监控网页解体。

• 更直观的问题上下文环境

  • 采纳浏览器录屏计划录制呈现问题前后的用户界面。

• 更敌对的客户告诉和告警   

  • 应用 Notification 桌 面告诉。

八、参考资料

• 云计算软件产品应用体验品质 度量模型及度量办法
• 前端日志标准
• woodpecker-log
• woodpecker-remote
• woodpecker-proxy