可观测性升级：小程序错误监控体系实践

背景与目标：

当前导购小程序有一套错误监控方案，但也仅限在导购小程序使用无法普及到其他项目中。基于此我们准备对错误监控方案做升级。期望新版本的错误监控体系可观测、可追踪。

业务痛点：

现在的实现方式是将错误日志通过接口上报到后端的日志库中，查询的时候需要在运维后台人工过滤。同时所有的日志只是纯报错信息无关联的设备信息、用户信息会增加排查的难度。

针对老版本的监控问题，期望新的监控体系可以实现的目标如下：

建设目标 ：

✅ 构建跨部门通用 的错误监控SDK

✅ 实现端到端可追溯 （用户行为链+设备环境+业务上下文）

✅ 建立分钟级告警响应机制

研发设计：

错误监控的内容各端的实现会有不同。简单的处理就是当捕获到前端JS报错直接上报就结束了，然后根据周期去统一处理这些问题即可。

接下来回结合业务场景：企微小程序。来讲一下我们是如何实现错误监控体系搭建的，在这个过程中需要思考哪些问题：

错误监控的日志内容是否与用户相关
错误监控的日志内容是否与设备相关
错误监控SDK涉及的内容有哪些：JS报错、接口报错、性能监控、自定义类别日志......
可视化的日志库操作如何实现
错误日志监控告警改如何实现
如何设计一个跨部门的通用的SDK

整体架构

架构设计主要解决的问题是：链路梳理与需求整合

bash 复制代码

[客户端SDK] -- 错误日志 --> [统一接入层] --> [SLS日志库]
       ↑                        |
       └----[设备/用户上下文]-----┘

日志描述：

所谓的日志描述即可以通过一条日志可以看到的信息用哪些，即通过日志能快速提供的信息。通过思考一条日志的数据结构来推测当前的设计是否可以满足要求。

如：张三在ios设备上使用导购小程序出现了错误，出现错误的版本是1.0.0，出现错误的时间为12点半。

bash 复制代码

字段设计如下：
distinct_id + devices_info + app_name + error_info  + versions + timestamp

日志级别、类型：

日志级别、类型主要是为了快速查询和钉钉群告警，这样是研发可以快速跟进错误，以免被无用的信息打扰。

bash 复制代码

字段涉及：
level: info、warn、error
type: api、js、custom(自定义日志)

日志上报：

日志上报指的是当错误监控SDK收集到了一条错误日志上报到哪里。从SAAS的角度上来讲需要错误监控平台提供统一的上报数据库，然后各端通过app_name区分。

在各个团队的沟通中发现统一的日志服务管理不太符合他们的需求，大家都期望使用自己的数据库独立管理。

基于此我们需要对SDK的处理做调整如下：

javascript 复制代码

// 错误监控SDK初始化
monitor.init({
  serverUrl: '', // 独立配置服务地址
  appName: '', // 标识应用名称，注意去重
  showLog: false,
})

架构设计的调整如下：

bash 复制代码

[客户端SDK] -- 错误日志 --> [统一接入层] --> [各端独立的日志存储]
       ↑                        |
       └----[设备/用户上下文]-----┘

解决方案：

通过思考一条错误日志包含的内容之后，就需要考虑数据可视化和监控告警群该如何对接。

错误监控SDK
日志服务SLS
钉钉群告警

bash 复制代码

[SLS日志存储] -- 日志查询 --> [钉钉群告警]

代码实现

错误监控的主要目标是捕获前端JS报错，接口监控、性能监控为非必须的能力。因此在设计层面会通过插件的方式对接，开启插件改回收集对应的错误日志。

javascript 复制代码

// 私有仓库
import monitor, { sendRequest, setCustomOptions }  from '@lib/mini-monitor'

monitor.init({
  serverUrl: '',
  appName: '',
  showLog: false,
  plugins: [], //wxPerformance、wxRequest
  ignoreUrls: [], // 忽略部分接口
})

优化升级

错误日志的聚合上报
可视化监控平台规划