日志程序回答“发生了什么”，错误监控回答“哪些错误正在伤害使用者”。话说回来，

从痛点来看。缺失错误监控的真实代价

很多产品早期没有错误监控，只有使用者截图、服务器日志和开发者自己的感觉。从结果是来看，

• 线上已经报错很多天了团队还不知道。
• 一次发布引入了新 bug，直到使用者流失才发现。话说回来，
• 前端白屏、支付失败、后台任务异常。都散落在不同地方，

错误监控的主要目标

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

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

参考资料

• Sentry Breadcrumbs
• Sentry Releases & Health
• Sentry Troubleshooting Source Maps
• Sentry Create a New Release API
• OpenTelemetry Exceptions
• Grafana Alerting

错误监控和日志不一样

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

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

日志：还原完整过程
至于错误监控，发现和归类异常
从指标监控来看。判断程序整体健康
告警程序的观点是，提醒该处理了

如果只有日志，你会很难知道“哪个错误最关键”。如果只有错误监控，你又可能缺少业务过程细节。两者最好一起用，

先覆盖前端和后端

第一步先，把前端和后端都接上。

前端需要捕获的异常类型

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

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

只接后端不够——很多使用者看到的问题发生在浏览器里后端根本不知道。只接前端也不行——支付、权限、数据库、后台任务的关键错误都在服务端。

Issue 聚合比单条错误更关键

网站最大的价值之一，是把相似错误归成一个 Issue。

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

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

Source Map 必须配置好

If you’re building a front‑end project。Source Map is essential.

app.min.js:: // 没有 source map 时只能看到压缩文件位置，几乎无助定位。

有了 Source Map。网站可以把生产环境堆栈映射回原始源码，让你看到真实文件、函数和行号。

• 生产建立生成 source map。
• source map 已上传到监控网站，release 与建立保持一致。
• 堆栈可读且不泄露敏感源码。老实说，

If source maps are missing。even a flood of front‑end errors becomes useless noise.

Release 和环境要打准

每个错误事件都必须携带环境和版本。说到常见环境，

development
preview
staging
production

说到常见版本标识。

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

Sentry 的 release 文档指出，release 能帮助判断 issue 是否由某次发布引入，并关联提交记录。如果没有 release，你很难回答：

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

上下文比堆栈更能救命

The stack trace tells you *where* code crashed;context tells you ***** it crashed.

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

Avoid leaking passwords。tokens or or personal data.

Sentry 的 Breadcrumbs 可以记录 issue 前的一串事件，例如使用者操作、请求、路由变化等，这对复现非常关键。

哪些错误需要忽略

Error monitoring isn’t “more is 娱乐ter”. Filter out noise:

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

If you don’t filter。platform quickly turns into a trash bin. Filter conservatively—always evaluate impact before discarding.

告警要按影响面设计

Avoid sending a notification for every new Issue.

• 生产环境新 error
• Error impact 超过阈值
• 关键方法失败这方面，支付、登录、注册、上传等 Certain release 引入的大幅 error rate 上升

。

---