在刚开始学前端的时候，那时候开发的应用总是在用户的设备中出现一些报错，开发者只知道这个型号的设备出现这个问题，但对其他信息却全然不知，比如说其他操作系统、其他设备型号、其他页面会有这个报错吗，这个报错出现的频率又是多少。每次出问题只能等待用户反馈，不能第一时间去解决问题，甚至用户没反馈的话永远也无法发现某些报错。

后来了解到前端监控这个东西，才知道原来可以这样去监控用户设备上的应用。“前端监控”不单单包括web性能和JS异常的监听，还包括处理日志的平台。下面就来总结一下打造一个完整的前端监控系统的过程。

了解业务需求

首先要了解自己所在的团队或者公司的具体需求。

• 如果是一个小团队，可能只需要简单的几个数据即可，业务也只有一两种，这样的话整个系统会简单很多，不用划分很多模块
• 如果是中厂或者大厂，很多个前端部门都需要用到这个平台，那么就需要划分成很多模块，而且需要很多通用的特性（比如说维度，下面会讲到）

了解完这个产品覆盖的范围后，就要开始调查开发者们需要在用户手机中需要收集的数据，根据这些字段设计日志的数据结构和数据库的设计

这里提到的数据可以包含以下几个点和无数小点

1. 性能统计
   1. 基础数值（首次渲染时间、白屏时间等）
   2. 可交互（首次加载时页面卡顿、操作时的js加载情况等）
   3. 资源（包括资源大小和资源的加载时间）
2. 异常统计
   1. JS异常
   2. ajax异常
   3. 资源文件

img

其中大点需要一开始就确定，大点下面的小点我把他成为分组，分组可以被每个业务方根据自己的业务自定义，这样可以极大增加系统的灵活性。

确定日志格式

1. type：首先要有一个type字段区分日志的类型，value比如performance（性能统计），abnormal（异常统计），除了这两种比较常见的type，自己也可以根据团队或公司业务来拓展value。
2. module：然后我们需要根据module字段区分各业务方，如商业研发部、基础架构部，考虑到部门的名字用英文表示太长且容易误会，可以用数字（分为前标和后标）映射来表示，如"1_1"表示商业研发部，"1_2"表示商业技术研发部，"2_1"表示基础架构部，按申请的部的顺序顺延，相同的大部门可以使用相同的“前标”，“后标”也可以表示不同的项目，这些都可以根据自己的部门自定义。
3. group：使用group表示分组，比如可以将一个项目中不同的落地页分成不同的组，将一个落地页中不同的组件分为不同组，还是根据自己的业务自行调整。
4. dim：即dimension维度，这个比较重要，简单说就是将每个数据都分为多个模块来统计，常见的dim如操作系统（Android or iOS）、浏览器类型、是否落地页、网络类型等等。
5. info：性能或异常的具体信息，一个“大点”中的info要求一样，这样方便统计，如异常统计的info可以分为“异常信息”、“异常时间”、“异常类型”、“具体的异常位置（行数）”。还包括一些诸如操作系统和浏览器类型的公共信息。