前端监控落地记：从没人看报表到主动追着看数据

1. 第一次上监控：埋了一堆点，没人看

两年前，我们第一次上前端监控，典型组合：Sentry + 自建埋点。那会儿大家的心态很简单——先把 SDK 接上，错误能收进来就是成功。于是我写了一个埋点 SDK，在入口文件里一行 initTracker()，全站搞定，心里还有点小成就感。

真正的问题从一周后开始暴露：每天都有几十上百条错误，Dashboard 红成一片，但没人愿意看。后端同事吐槽：「这玩意儿太吵了」，产品说：「我看不懂这些英文异常信息跟用户有什么关系」，前端自己也只在上线当天心虚地瞟几眼。

后来复盘的时候，我们很诚实地承认：那一轮所谓「前端可观测性改造」，本质上就是多装了几个监控 SDK，却没有回答一个关键问题——

• 谁要看这些数据？
• 什么时候看？
• 看完能做什么决策？

2. 第二次尝试：先砍指标，再谈优化

第二轮我们换了思路，先不谈技术方案，只问一个问题：现在线上到底有哪些我们「经常被骂」的问题？ 很快列出了三条：

1. 有些页面偶尔白屏，刷新一下又好了。
2. 弱网下加载特别慢，但我们没有直观的数据。
3. 偶发现实用户报错，但技术同学在本地死活复现不出来。

于是我们把监控目标缩成了三件事：

• 白屏检测：首屏在 8 秒内是否渲染出关键节点。
• 关键路径耗时：从点击「登录」到看到首页数据的总耗时。
• 错误归因：出问题时，能拿到「环境 + 操作路径 + 请求链路」。

指标一旦收窄，技术方案反而简单了很多——我们把原来那些「想到就埋」的点砍掉 60%，只保留真正能串起来「一次用户访问」的核心事件。

3. 真正有用的几个埋点

最后真正留下来的埋点，大概就这么几类：

• 页面级：PV、首屏渲染时间、白屏检测结果。
• 动作级：登录成功、主要业务入口点击（比如「下单」「提交审批」）。
• 错误级：前端未捕获异常、接口错误（带 status code）、关键接口超时。

我们没有追求「全埋点」，反而刻意控制了埋点数量。一开始有人不放心，总觉得「多采点总没坏处」，真上了之后发现，多出来的那些点基本没人看，还会影响前端包体积和上报压力。

4. 让监控「对人说话」：从开发视角转向用户视角

之前的监控报表，标题大多是这种：

error_count_by_message api_duration_p95 chunk_load_error_total 

乍一看很专业，但产品、运营完全看不懂。后来我们直接把看板拆成了两套：

• 给研发看的：错误堆栈、接口耗时、资源加载情况。
• 给产品看的：每天有多少人遇到「打不开页面」、下单成功率是多少、登录失败率是多少。

这一步其实没有什么高深技术，主要是换个说话方式。比如把「某接口 500 次请求中失败 20 次」翻译成：

「今天有 3.2% 的下单请求失败，估算影响了 80 多个真实订单。」

从那天起，产品经理第一次主动问我们：「这块能不能想办法再优化一点？」

5. 真正改变团队行为的是「复盘」

前端监控想真正有用，光有数据还不够，关键在于把数据写进复盘。我们后来定了一个非常简单的规则：

• 任何一次线上事故复盘，P0 条目里必须有「监控视角」的一节。
• 写清楚：监控有没有提前给信号？有没有误报？有没有漏报？
• 如果这次是「事后才想起来看监控」，那就记一笔技术债，下次要能提前看到。

连续几次之后，大家慢慢形成了一个习惯：上线前看看监控大盘有没有明显异常，出了问题优先去看那几个核心看板。你会发现，监控是不是「好用」，不是研发说了算，而是看复盘里它被引用的次数。

6. 一些踩过的坑

最后简单列几个我们自己踩过的坑，给还在路上的同学做个参考：

• 把监控当日志收集：一股脑把所有 console.log 往监控里塞，结果带宽被打爆， 查询一条记录要十几秒，谁都不想用了。
• 所有告警都发群里：刚开始大家还会点开看看，一个月后所有人都选择性忽略， 真出大问题的时候已经没人信这个群了。
• 只做技术指标，不做业务指标：接口耗时、错误率都很好看，但用户依然在骂「不好用」， 后来才发现某个关键流程的转化率一直很低，我们之前根本没关注。

7. 写在最后

现在再回头看，我们其实没做什么「高大上」的东西，更多是一点点把问题讲清楚：谁看监控、为什么看、看完能做什么决策。 工程上复杂的地方是细节，比如采样率怎么调、前后端 TraceID 怎么贯通，这些各家有各自的实现，思路都差不多。

如果你们团队也在做前端监控建设，我只建议一件事：别从「能接多少 SDK」开始，而是从「下一个版本发布时，我们想少掉哪类线上问题」开始。 这时候你会发现，很多你以为必须上的图表，可能一张都用不上。