Sentry 怎么排查线上问题？错误监控、Tracing 和 Session Replay 怎么配合

真正有用的监控，不是每天收到一百封“报错了”

Sentry 会把异常、堆栈、breadcrumbs、release 和环境等上下文放在一起，帮助判断哪个版本开始出错、影响哪些用户、是不是同一类问题。比只在服务器里 grep 日志更容易建立完整线索。

前端报错先把 source map 和 release 配好

生产环境 JavaScript 往往被压缩，没 source map 时堆栈很难读。把构建版本和 source map 对上，才有机会直接看到原始源码位置，也方便判断某次发布是不是引入了回归。

Tracing 适合回答“慢在哪一段”

页面慢或接口慢，单看总耗时很难知道是前端、API、数据库还是下游服务。分布式 tracing 能沿着请求看 span，适合找慢查询、外部依赖和服务之间的瓶颈。

Session Replay 是“像视频一样”的复现，不等于真的录屏

Sentry 当前的 Web Session Replay 主要记录浏览器 DOM 和交互，再重建用户看到的过程。它能帮你理解报错前发生了什么，但也会带来隐私和性能考虑，采样率、文本遮罩和敏感字段必须认真配置。

先把高价值问题接进来，再扩监控范围

一开始就把所有日志、所有 replay、所有 trace 全开，成本和噪音都会上来。更实际的做法是先覆盖核心错误、关键交易和代表性性能路径，等告警规则稳定后再扩大。