前端监控闭环：采集、告警到问题跟踪

wuwj 收录于监控与运维

2022-09-05 约 276 字预计阅读 2 分钟

很多团队做前端监控的姿势是：

先接一个 SDK，看到了几个报错，然后就没然后了。

最后变成：

告警群天天响，大家学会了「静音」；
仪表盘很酷，但没人看；
真出大问题时，还是靠用户截图。

这篇文章想聊的是：怎么从「有监控」升级到「有闭环」：采集、告警、问题跟踪、复盘一条链路打通。

1. 前端到底要监什么？

可以按三个维度来想：

可用性
- JS 运行错误（Error、Promise 未捕获）；
- 资源加载失败（JS/CSS/图片）；
- 页面白屏/异常重定向。
性能
- 首屏指标（FCP/FP/TTI 等的近似值）；
- 接口耗时、失败率；
- 静态资源加载时间。
行为 & 转化
- 关键路径的曝光/点击/完成；
- 异常行为（频繁刷新、某步流失明显）。

实践上，可以先从：错误 + 性能 + 关键链路打点 三件事做起。

2. 采集：埋点 & SDK 一起用

2.1 错误采集

典型方式：

window.addEventListener('error', (event) => {
  reportError({
    type: 'error',
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
    stack: event.error?.stack,
  });
});

window.addEventListener('unhandledrejection', (event) => {
  reportError({
    type: 'unhandledrejection',
    reason: String(event.reason),
  });
});

结合 sourcemap 上传，可以把错误还原到源代码行。

2.2 性能采集

利用 Performance API：

window.addEventListener('load', () => {
  const timing = performance.timing;
  const dns = timing.domainLookupEnd - timing.domainLookupStart;
  const tcp = timing.connectEnd - timing.connectStart;
  const ttfb = timing.responseStart - timing.requestStart;
  const domReady = timing.domContentLoadedEventEnd - timing.navigationStart;

  reportPerformance({ dns, tcp, ttfb, domReady });
});

更现代一点可以用 PerformanceObserver 采集 FCP/LCP 等指标。

2.3 行为埋点

对关键链路埋点：

页面进入 / 离开；
表单提交、下单按钮点击；
某些开关、功能使用次数。

统一封装 track 函数，避免到处写：

track('order_submit_click', { bizType: 'fund', source: 'home_banner' });

3. 聚合与存储：别让数据躺在日志里

采集上来只是原始数据，要能看、能查，至少要做：

按 应用 / 版本 / 环境 维度分库或分索引；
给每条数据打上：用户 ID / 设备 / 浏览器 / 路由信息；
错误要能聚合成「错误组」（同一 stack 归为一类）；
性能要能按「地区 / 终端」维度做分布。

技术选型上：

小团队可以直接上现成的前端监控 SaaS；
有资源的团队可以基于 ELK / ClickHouse / 时序库自己搭。

关键不是用什么，而是：查询与聚合方便，开发能自己查。

4. 告警：少而准，比多而吵重要

告警的目标是：真正有「异常」时把相关人叫醒，而不是让大家对告警免疫。

4.1 告警规则设计

示例规则：

JS 错误
- 单个错误类型在 5 分钟内出现次数 > N；
- 某个页面的错误率超过一定阈值（错误会话数 / 总会话数）。
接口失败
- 某个关键接口 5 分钟失败率 > X%；
- HTTP 5xx 突增。
性能指标异常
- 某页面 FCP > 某阈值且样本数较大；
- 指标较历史平均突然抬升（同比/环比）。

4.2 通知方式

日常类告警：钉钉/飞书/企微群机器人；
严重类（比如大量用户无法登录）：附加短信/电话通知 oncall。

并且在通知内容中给出：

应用名 / 环境（生产/预发）；
错误摘要 / 接口名；
最近 5 分钟次数统计；
链接到监控平台对应视图。

5. 问题跟踪：从告警到工单/缺陷

有了告警之后，更关键的是：

告警被谁看到、谁负责跟进、结果如何。

比较理想的流程是：

告警推送到群里；
值班/相关负责人在群里「认领」，并在平台上将其转换为工单/缺陷；
问题处理完毕后，标记状态并写简短结论。

这样一来：

每条告警都有去向；
历史问题可以回溯，看哪些是「一直反复出现但没人根治」。

实践中可以把监控平台和现有问题管理系统（Jira、Tapd 等）打通，支持「一键转工单」。

6. 复盘：让同样问题少发生几次

对于影响较大的前端问题（如大面积白屏、核心流程报错），建议做一次简短复盘，包含：

时间线：何时首次发生，何时发现，何时恢复；
影响范围：多少用户受影响，主要在哪些页面；
根因分析：代码缺陷？灰度策略问题？配置错误？；
监控视角：监控是否提前给出信号？规则需要调整吗？；
后续动作：加单测？加发布前检查？改监控阈值？。

复盘的目的不是「追责」，而是让监控体系和发布流程一点点变好。

7. 实战中的几个经验

先把错误率和关键链路跑起来，不要一上来全开
- 魔改太多指标，一开始团队反而消化不了；
- 可以先选 2–3 个关键信息：全局错误、登录/交易流量。
监控数据要对开发友好
- 能快速根据用户 ID 或某个 session 找到对应日志；
- 能从错误栈追到源代码位置。
告警要「能被关掉或调优」
- 对经确认为「暂时可接受」的告警，提供静音/调阈值能力；
- 不然很快所有人都把群消息免打扰。
前端监控是团队的，而不是某个人的
- 文档里写清楚各个项目的监控入口；
- 新同学入项时，一定要把监控视图讲一遍。

8. 小结

前端监控要真正起作用，至少要做到：

把关键的「错误、性能、行为」数据采集上来；
存在一个查询方便、聚合合理的平台；
告警有规则、有节制，不让大家对它免疫；
每一次较大的问题都有「跟进 + 复盘」；
监控结果能够反向推动代码质量和发布流程改进。

做到这一步，你会发现：

从此遇到「用户说打不开」，不再只能回一句「你把截图发我看看」，而是能先打开监控，看看到底发生了什么。

目录