小程序监控报警：从被动响应到主动预防

小程序上线后，用户遇到的第一个白屏、第一次支付失败，往往不会主动反馈。等到差评出现，问题已经扩散。监控报警的价值在于把「用户发现问题」变成「系统发现问题」，把响应时间从小时级压缩到分钟级。

监控的三个层次

很多团队的监控停留在「服务是否存活」，这远远不够。一个可用的监控体系至少覆盖三层：

• 可用性监控：接口成功率、页面加载成功率、关键路径（登录、下单、支付）是否通畅。
• 性能监控：首屏耗时、接口 P95/P99 延迟、setData 频率与数据量。
• 业务监控：支付成功率、订单转化率、核心按钮点击量的异常波动。

前两层偏技术，第三层偏业务。只做技术监控，容易出现「系统一切正常，但转化率腰斩」的盲区。

数据从哪来：前端埋点与后端日志

小程序端可通过 App 的 onError、onUnhandledRejection 捕获未处理异常，结合 wx.request 的封装统一上报接口耗时与状态码。

// 统一请求封装，自动上报耗时与错误
function request(options) {
  const start = Date.now();
  return new Promise((resolve, reject) => {
    wx.request({
      ...options,
      success(res) {
        report('api', {
          url: options.url,
          status: res.statusCode,
          cost: Date.now() - start
        });
        resolve(res);
      },
      fail(err) {
        report('api_fail', {
          url: options.url,
          cost: Date.now() - start,
          msg: err.errMsg
        });
        reject(err);
      }
    });
  });
}

App({
  onError(msg) {
    report('js_error', { msg });
  },
  onUnhandledRejection(res) {
    report('promise_error', { reason: String(res.reason) });
  }
});

上报本身要轻量：批量聚合、失败重试一次即可，避免监控拖慢主流程。后端侧则记录接口耗时、错误码分布，两者按同一时间窗口聚合，才能快速定位是前端渲染慢还是接口慢。

报警规则怎么定

报警不是越多越好，噪音会让人麻木。建议按「阈值 + 持续时长 + 同比」三个维度设置：

• 接口错误率连续 5 分钟超过 5% 触发；
• 支付成功率较昨日同时段下降 30% 触发；
• 首屏 P90 耗时连续 10 分钟高于基线 2 秒触发。

单点抖动不报警，持续异常才报警。同时给每个报警设置明确的负责人和处置手册，否则报警只是把焦虑转发给下一个人。

用云开发快速搭一套

对独立开发者和小团队，云开发能省掉服务器与运维成本。上报数据写入云数据库，用定时触发器每分钟跑一次聚合函数，命中规则后调用订阅消息或 webhook 推送。

// 云函数：定时聚合与报警判断
exports.main = async () => {
  const db = cloud.database();
  const since = new Date(Date.now() - 5 * 60 * 1000);
  const { total } = await db.collection('api_log')
    .where({ createdAt: db.command.gt(since) }).count();
  const { total: failed } = await db.collection('api_log')
    .where({ createdAt: db.command.gt(since), status: db.command.neq(200) }).count();

  const rate = total ? failed / total : 0;
  if (total > 50 && rate > 0.05) {
    await cloud.callFunction({
      name: 'notify',
      data: { text: `接口错误率 ${(rate * 100).toFixed(1)}%` }
    });
  }
};

注意日志表要设置过期清理策略，否则存储费用会随数据量线性增长。

报警之后：闭环比通知更重要

一条报警发出去只是开始。真正降低故障影响的是三件事：

1. 快速止血：能降级就降级，能回滚就回滚，先恢复再排查。
2. 定位根因：报警信息里带上时间、版本号、错误样本，减少来回沟通。
3. 复盘归档：把每次报警的处置过程写进文档，同类问题第二次出现时能直接套用。

监控的目标不是「没有报警」，而是「每次报警都能在用户感知前被处理」。

从小处着手：先给登录、下单、支付三条核心链路加上成功率和耗时监控，跑通一次完整的「异常—报警—处置」流程，再逐步扩展到全站。监控体系是长出来的，不是一次设计出来的。