背景与目标：
当前导购小程序有一套错误监控方案，但也仅限在导购小程序使用无法普及到其他项目中。基于此我们准备对错误监控方案做升级。期望新版本的错误监控体系可观测、可追踪。
业务痛点：
现在的实现方式是将错误日志通过接口上报到后端的日志库中，查询的时候需要在运维后台人工过滤。同时所有的日志只是纯报错信息无关联的设备信息、用户信息会增加排查的难度。
针对老版本的监控问题，期望新的监控体系可以实现的目标如下：
建设目标：
✅ 构建跨部门通用的错误监控SDK
✅ 实现端到端可追溯（用户行为链+设备环境+业务上下文）
✅ 建立分钟级告警响应机制
研发设计：
错误监控的内容各端的实现会有不同。简单的处理就是当捕获到前端JS报错直接上报就结束了，然后根据周期去统一处理这些问题即可。
接下来回结合业务场景：企微小程序。来讲一下我们是如何实现错误监控体系搭建的，在这个过程中需要思考哪些问题：
- 错误监控的日志内容是否与用户相关
- 错误监控的日志内容是否与设备相关
- 错误监控SDK涉及的内容有哪些：JS报错、接口报错、性能监控、自定义类别日志......
- 可视化的日志库操作如何实现
- 错误日志监控告警改如何实现
- 如何设计一个跨部门的通用的SDK
整体架构
架构设计主要解决的问题是：链路梳理与需求整合
[客户端SDK] -- 错误日志 --> [统一接入层] --> [SLS日志库]
↑ |
└----[设备/用户上下文]-----┘
日志描述：
所谓的日志描述即可以通过一条日志可以看到的信息用哪些，即通过日志能快速提供的信息。通过思考一条日志的数据结构来推测当前的设计是否可以满足要求。
如：张三在ios设备上使用导购小程序出现了错误，出现错误的版本是1.0.0，出现错误的时间为12点半。
字段设计如下：
distinct_id + devices_info + app_name + error_info + versions + timestamp
日志级别、类型：
日志级别、类型主要是为了快速查询和钉钉群告警，这样是研发可以快速跟进错误，以免被无用的信息打扰。
字段涉及：
level: info、warn、error
type: api、js、custom(自定义日志)
日志上报：
日志上报指的是当错误监控SDK收集到了一条错误日志上报到哪里。从SAAS的角度上来讲需要错误监控平台提供统一的上报数据库，然后各端通过app_name区分。
在各个团队的沟通中发现统一的日志服务管理不太符合他们的需求，大家都期望使用自己的数据库独立管理。
基于此我们需要对SDK的处理做调整如下：
// 错误监控SDK初始化
monitor.init({
serverUrl: '', // 独立配置服务地址
appName: '', // 标识应用名称，注意去重
showLog: false,
})
架构设计的调整如下：
[客户端SDK] -- 错误日志 --> [统一接入层] --> [各端独立的日志存储]
↑ |
└----[设备/用户上下文]-----┘
解决方案：
通过思考一条错误日志包含的内容之后，就需要考虑数据可视化和监控告警群该如何对接。
- 错误监控SDK
- 日志服务SLS
- 钉钉群告警
[SLS日志存储] -- 日志查询 --> [钉钉群告警]
代码实现
错误监控的主要目标是捕获前端JS报错，接口监控、性能监控为非必须的能力。因此在设计层面会通过插件的方式对接，开启插件改回收集对应的错误日志。
// 私有仓库
import monitor, { sendRequest, setCustomOptions } from '@lib/mini-monitor'
monitor.init({
serverUrl: '',
appName: '',
showLog: false,
plugins: [], //wxPerformance、wxRequest
ignoreUrls: [], // 忽略部分接口
})
优化升级
- 错误日志的聚合上报
- 可视化监控平台规划
