错误监控怎么做

日志系统回答"发生了什么"，错误监控回答"哪些错误正在伤害用户"。

很多产品早期没有错误监控，只有用户截图、服务器日志和开发者自己的感觉。结果是：线上已经报错很多天了，团队还不知道；一次发布引入了新 bug，直到用户流失才发现；前端白屏、支付失败、后台任务异常，都散落在不同地方。

错误监控的目标不是收集所有报错，而是让你快速判断：

复制代码

这个错误影响了多少用户？
从哪个版本开始出现？
堆栈指向哪段代码？
有没有复现路径和上下文？
应该现在处理，还是可以排期？

本文参考了几类官方资料：

错误监控和日志不一样

日志偏"过程记录"，错误监控偏"异常聚合"。

日志里可能有成千上万条事件，但错误监控会把相似错误聚合成 issue，并展示发生次数、影响用户、首次出现时间、最近出现时间、堆栈、环境和版本。

你可以这样分工：

复制代码

日志：还原完整过程
错误监控：发现和归类异常
指标监控：判断系统整体健康
告警系统：提醒该处理了

如果只有日志，你会很难知道"哪个错误最重要"。如果只有错误监控，你又可能缺少业务过程细节。

两者最好一起用。

先覆盖前端和后端

错误监控第一步，是把前端和后端都接上。

前端要捕获：

javascript 复制代码

JavaScript 运行时错误
Promise 未捕获异常
页面白屏
资源加载失败
关键 API 请求失败
前端路由切换中的异常

后端要捕获：

复制代码

未处理异常
接口 5xx
数据库异常
第三方接口异常
后台任务异常
Webhook 处理异常
队列消费异常

只接后端不够。很多用户看到的问题发生在浏览器里，后端日志完全不知道。

只接前端也不够。支付、权限、数据库、后台任务的关键错误都在服务端。

Issue 聚合比单条错误更重要

错误监控平台最大的价值之一，是把相似错误归成一个 issue。

单条错误只能告诉你"这里错了一次"。Issue 聚合能告诉你：

复制代码

这个错误出现了多少次
影响了多少用户
是否从某个版本开始增加
是否只发生在某个浏览器或地区
最近是否还在发生
是否已经修复后又回归

早期排查时，不要被单次错误牵着走。先看影响面，再决定优先级。

一个影响 1 个内部测试账号的错误，和一个影响 300 个付费用户支付流程的错误，处理顺序完全不同。

Source Map 必须配置好

如果你做前端项目，Source Map 非常关键。

没有 Source Map，生产环境堆栈可能只会显示压缩后的文件和位置：

arduino 复制代码

app.min.js:1:48392

这对定位几乎没有帮助。

有了 Source Map，错误监控平台可以把生产错误映射回原始源码位置，让你看到真实文件、函数和行号。

Sentry 的 Source Map 文档也强调，需要在对应 release 中上传源码和 source map，且通常要在错误发生前完成上传。

上线前要确认：

arduino 复制代码

生产构建生成 source map
source map 已上传到监控平台
release 版本一致
错误事件能正确反解堆栈
不公开暴露敏感源码文件

如果前端错误很多，但堆栈不可读，错误监控价值会大打折扣。

Release 和环境要打准

错误必须带上环境和版本。

环境常见包括：

复制代码

development
preview
staging
production

版本可以是：

sql 复制代码

Git commit SHA
语义化版本号
构建编号
部署时间戳

Sentry 的 release 文档提到，release 可以帮助判断 issue 是否由某次发布引入，也能关联提交和部署。

没有 release，你很难回答：

复制代码

这个错误是不是刚刚上线后出现的？
哪个版本开始有问题？
修复是否已经发布？
回滚后错误是否停止？

每次部署都应该带上清晰的 release 标识。

上下文比堆栈更能救命

堆栈告诉你代码在哪里崩了，上下文告诉你为什么会崩。

建议给错误事件附带这些上下文：

arduino 复制代码

user_id
team_id
request_id
route
feature
plan
browser
device
region
release
environment
关键业务对象 ID

但同样要注意隐私，不要把密码、Token、完整隐私内容放进去。

Sentry 的 Breadcrumbs 文档说明，breadcrumbs 可以记录 issue 发生前的一串事件，比如用户操作、请求、路由变化和状态变化。这类信息对复现非常有帮助。

一个好的错误事件，应该让你能看懂：

复制代码

用户先做了什么
系统调用了什么接口
哪个步骤失败
失败前后状态是什么

哪些错误需要忽略

错误监控不是越多越好。

有些错误需要过滤或降噪：

复制代码

浏览器插件注入导致的异常
已知爬虫造成的异常
用户主动断网导致的请求取消
第三方脚本偶发错误
无业务影响的旧浏览器兼容问题
本地开发环境错误
健康检查请求错误

如果不降噪，错误监控很快会变成垃圾桶。

但过滤要谨慎。不要因为"看起来烦"就把真实用户错误忽略掉。最好先看影响面、用户类型和业务路径，再决定过滤规则。

告警要按影响面设计

不要每个新 issue 都发消息。

早期可以设置几类告警：

arduino 复制代码

生产环境新错误
错误影响用户数超过阈值
支付、登录、注册、上传等关键路径失败
某个 release 错误率突然上升
同一错误在短时间内暴增
后台任务连续失败
Webhook 连续失败

Grafana Alerting 官方文档也强调，可以基于指标或日志配置规则、条件和通知。

告警的重点不是"有错误就叫"，而是"值得处理时叫"。

错误要有处理流程

错误监控接上以后，还需要处理流程。

一个简单流程：

markdown 复制代码

1. 新错误进入 inbox
2. 判断是否生产环境
3. 看影响用户数和发生频率
4. 看是否影响核心路径
5. 分配负责人
6. 标记优先级
7. 修复后关联 release
8. 观察是否停止或回归

如果没有流程，错误平台会堆满 unresolved issue，最后没人看。

早期可以每周清理一次错误 inbox。上线当天、支付改动、登录改动、权限改动之后，要更频繁地看。

不要把错误监控当审计系统

错误监控不是审计日志，也不是用户行为分析。

它主要记录异常和异常上下文。不要为了省事，把所有用户操作、业务流水、权限变更都塞进错误监控。

正确分工应该是：

复制代码

错误监控：异常、堆栈、上下文、影响面
日志系统：过程记录、排障线索
审计日志：关键变更、谁改了什么
埋点系统：用户行为、转化路径
指标系统：整体健康、趋势和阈值

系统边界越清楚，后期越容易维护。

一个最小可用配置

如果你是独立开发者，错误监控可以这样开始：

markdown 复制代码

1. 前端和后端都接入错误监控 SDK
2. 只在 production 和 preview 上报，development 默认关闭
3. 每次部署带 release 和 environment
4. 前端配置 source map 上传
5. 错误事件带 user_id、team_id、request_id、route
6. 登录、支付、上传、Webhook、后台任务设置更高优先级
7. 过滤明显无效噪音
8. 新错误和错误暴增接入告警
9. 每周清理 unresolved issue

这套配置不复杂，但能让你从"等用户反馈"变成"主动发现问题"。

写在最后

错误监控的核心，是把线上异常变成可聚合、可定位、可分配、可验证的工作项。

不要只追求"接入了某个平台"。真正有用的是：堆栈可读、上下文足够、版本准确、告警不过度、处理流程有人负责。

当你的产品开始有真实用户时，错误监控不是高级配置，而是基础设施。

下一篇，我们继续聊增长和产品判断：用户埋点怎么设计。