项目五：前端稳定性监控与大促高可用

项目五：前端稳定性监控与大促高可用

资料中的“前端哨兵”项目覆盖错误、用户行为、框架异常、性能指标、ErrorId、日志上报和 Web/小程序差异；配套的大促资料进一步涉及入口盘点、容量、三层监控、预案和演练。本文将其组织成完整项目，不把“提前多少分钟发现”或 Crash 百分比当作既定结果。

1. 背景与目标

前端故障往往先表现为用户无法点击、页面白屏、请求失败或数据展示错误，而服务端大盘可能仍然正常。没有统一采集和版本关联时，团队只能依赖用户截图，难以回答：

• 哪个版本、浏览器、路由和依赖引起了问题？
• 有多少会话受影响，是否集中在资损或高流量入口？
• 是真实异常、主动取消、弱网超时，还是监控 SDK 自己失败？
• 如何在大促期间快速止血，并在事后补上测试和发布门禁？

项目目标是建立一条不阻塞业务的闭环：

采集 -> 脱敏/标准化 -> 采样/聚合 -> 队列上报
   -> 版本/trace 关联 -> 大盘/告警 -> 预案/止血
   -> 复盘/回归测试/规则调整

成功标准要落到行为和证据：错误能定位到 release 和样本；关键性能能按路由和设备分位统计；上报失败不会放大故障；高风险入口有容量、降级、回滚和演练记录。

2. 监控架构

浏览器 / 小程序
  |- runtime/resource/unhandled rejection
  |- request/performance/behavior
  \- framework boundary
          |
          v
SDK: normalize -> redact -> sample -> bounded queue -> beacon/fetch
          |
          v
接收网关 -> 校验/限流/去重 -> 事件存储 -> 聚合大盘/告警
                                     |             |
                                     v             v
                              release/source map  值班/预案/事故单

SDK 只负责轻量采集和可靠发送；聚合、查询、告警和权限放在服务端。Web 和小程序可共享事件模型与脱敏规则，但能力检测、生命周期和上报 API 分别适配，不假设两端完全相同。

3. 统一事件信封

type MonitorEvent = {
  schemaVersion: 1
  id: string
  type: 'error' | 'performance' | 'request' | 'behavior'
  occurredAt: number
  sessionId: string
  page: { url?: string; route?: string }
  release: string
  traceId?: string
  samplingVersion?: string
  payload: Record<string, unknown>
}

字段约束：

• id 客户端生成，用于重试去重；服务端仍需幂等写入。
• release 与构建产物、Source Map 一致；错误不能只按消息文本聚合。
• URL、错误消息、自定义属性进入队列前做字段级脱敏；不采集 Cookie、Authorization、输入框原文和完整 IP。
• payload 限制深度、字符串/数组长度和总字节数，超限时保留摘要。
• 路由、浏览器、网络类型和采样版本作为维度，但避免未经必要性评估的设备指纹。

错误 fingerprint 可组合事件类型、标准化消息、文件/行列和 release；同一问题聚合后再告警，避免单个用户连续刷新把值班频道刷爆。

4. 错误与请求采集

全局 error 监听需区分运行时异常和资源加载失败；unhandledrejection 统一转换未知 reason。框架 Error Boundary 负责组件树，但不能代替全局捕获。跨域脚本只得到 Script error. 时，需要服务端 CORS 与 crossorigin 配合；第三方脚本仍可能不可观测。

请求拦截器记录脱敏后的 URL 模板、方法、状态、耗时、取消/超时原因和 traceId，不记录完整请求体或令牌。主动取消、用户离开页面和预期降级应标记为非错误，避免错误率虚高。慢请求和错误请求提高采样，正常请求按会话或哈希稳定采样。

5. 性能与用户行为采集

PerformanceObserver 可观察导航、资源、长任务、布局偏移和交互延迟。首屏指标先在内存中汇总，页面隐藏或 pagehide 时用 navigator.sendBeacon 尝试发送；Beacon 只保证请求进入浏览器队列，不保证服务端已处理。内存队列在页面/进程结束后会丢失；若要求跨页面或跨启动补偿，必须将 outbox 持久化到 IndexedDB、Service Worker 等可靠介质，并设置过期与隐私清理，否则只能依赖服务端对已接收事件的幂等重试和明确记录丢弃计数。

行为采集只记录必要的事件名、页面和结果，不记录输入原文。关键点击可关联 traceId 和业务操作 ID，让“用户点了什么”与“哪个请求失败”能在同一时间线上查看。采集本身应异步、限流、可关闭，不得阻塞首屏或交互。

6. 队列、采样与降级

事件 -> 脱敏/规范化 -> 按策略采样 -> 内存队列（条数/字节上限）
                                      |
                                      +-- 批量压缩/Beacon
                                      +-- 超限丢弃低优先级事件
                                      +-- 失败退避/熔断

• 错误和关键性能事件优先于普通行为事件；队列满时按优先级丢弃。
• 上报请求设置超时、重试上限和指数退避；连续失败熔断一段时间，避免网络异常放大流量。
• SDK 初始化失败、CSP 阻断或 API 不支持时静默降级，只增加内部计数，不递归上报自身错误。
• 采样率和规则由版本配置控制，配置失效时使用安全默认值；不能远程下发任意代码。
• 采集开关应支持按环境、租户、路由和用户同意状态关闭，敏感场景默认最小采集。

7. 版本、Source Map 与定位

生产错误定位依赖三个一致的对象：发布版本、构建产物和 Source Map。部署时生成产物校验清单，将 Source Map 上传到受控平台，客户端只带 release 和文件名；旧版本错误匹配不到映射时应安全失败而不是猜测行号。

错误详情可以附带路由、浏览器版本、最近请求 traceId、操作步骤和 feature flag，但必须脱敏。发布系统要能从告警直接跳到对应 commit、灰度批次和回滚入口。

8. 大促前的入口与容量盘点

稳定性不是单一 SDK 项目。大促前先盘点三类入口：

1. 核心重保入口：服务等级、准确性或响应时间有明确承诺。
2. 资损入口：故障可能导致订单、金额或权益错误。
3. 大流量入口：峰值可能挤压自身或下游容量，即使单次故障业务损失有限。

沿入口追踪 HTTP、RPC、消息、缓存和外部服务，标记强依赖/弱依赖、超时、资源水位、最近改造和历史故障。容量模型同时考虑上游流量、业务峰值日期、场景分配、下游限额和余量，并用压测或历史数据验证，不能只看本服务机器数。

9. 三层信号与黄金指标

Biz:       成功率、业务延时、关键状态、资损
Application: JS 错误、请求超时、线程/进程、中间件
System:    CPU、内存、网络、磁盘、实例水位

每层按 Latency / Errors / Traffic / Saturation 组织

业务层最接近用户感受，优先触发告警；应用和系统层帮助定位原因。每条告警写清级别、阈值、持续时间、通知人、升级路径、预案和恢复条件。阈值应结合业务波动和分位数，不能过迟，也不能制造告警疲劳。

前端 SDK 的错误、请求、性能和行为事件可以作为 Biz/Application 层输入，但不能替代服务端和系统监控。大盘至少支持按 release、路由、端、浏览器、租户和依赖分组。

10. 预案、事故角色与演练

预案按执行时机和影响对象分为：

• 技术应急：限流、降级、摘除异常节点、切换备份。
• 技术前置：峰值前熔断弱依赖、暂停冲突任务、校验容量和开关。
• 业务应急：数据错误、玩法变更或需要业务确认的有损处理。
• 业务前置：配合活动节奏调整配置和服务策略。

每份预案至少包含执行/关闭时间、触发/恢复阈值、影响、决策/执行/验证人员、开启和关闭步骤。事故管理可分四个角色：事故总控、处理团队、发言人、规划/轮班负责人。实时事故文档记录时间线、证据、决策和交接，避免多人同时修改同一开关。

沙盘演练使用历史真实故障，重点验证止血、分工、证据保留和恢复，而不是只检查文档存在。演练后要恢复限流/扩容设置，并将缺口转成有 owner 和截止时间的改进项。

11. 失败边界与恢复

失败场景	可能后果	止血与长期改进
SDK 上报接口故障	业务请求被额外拖慢	独立域名、超时、队列上限、熔断和静默降级
采样配置错误	关键事件丢失或流量暴涨	安全默认、版本化配置、配置审计和流量保护
Source Map 不匹配	错误无法定位	release 校验、产物清单、部署门禁和回滚
跨域脚本无堆栈	只能看到 Script error	CORS/crossorigin；接受第三方边界并监控资源失败
Beacon 未送达	页面关闭时指标缺失	visibilitychange/pagehide；只有持久化 outbox 才能下一次启动补偿，否则依赖服务端对已接收事件的幂等重试并记录丢弃计数
告警风暴	值班无法识别主因	fingerprint 聚合、优先级和多指标抑制
强依赖超时	核心链路级联阻塞	超时预算、降级/切换、容量压测和预案演练
灰度版本异常	影响面扩大	小流量停止条件、release 维度大盘、一键回滚

12. 指标与验证

方向	指标定义	证据
采集质量	事件丢弃率、去重率、上报成功率、SDK 自身错误	SDK 内部计数和接收网关日志
稳定性	错误会话率、资源失败率、接口超时率、受影响入口数	release/路由维度大盘
体验	LCP、INP、CLS、首屏/交互延迟 P75/P95	PerformanceObserver、trace
响应	告警到确认、止血、恢复和复盘完成时间	事故时间线
发布	灰度停止次数、回滚耗时、版本错误回归	发布系统和监控关联
大促	峰值流量余量、弱依赖降级覆盖、演练通过率	容量表、预案和演练记录

验证用例包括运行时错误、资源失败、Promise 拒绝、网络超时、Beacon 不可用、队列超限、隐私脱敏、Source Map 错配、降级开关和回滚。指标阈值由自身 SLO、设备和业务波动决定，不直接套用资料中的数字。

13. 面试表达与追问

三分钟版本

前端故障原来只能靠用户反馈，无法关联版本、路由和请求。我负责监控 SDK、事件协议和大促保障清单，采集错误、请求、性能和必要的行为事件，统一脱敏、采样、队列和 release/trace 关联。
SDK 失败时有上限、退避和熔断，不影响业务；发布前把核心、资损、大流量入口和强弱依赖画成链路，建立 Biz/Application/System 三层信号和限流、降级、回滚预案。
一次告警会沿样本、Source Map 和发布批次定位，事故后补回归测试、监控规则和演练。结果只引用自己的大盘、时间线和版本记录。

高频追问

追问	回答要点	深入阅读
为什么不能把所有日志都上报？	成本、隐私、网络和告警噪声；统一信封、脱敏、优先级采样、队列上限和聚合	前端稳定性
error 和 Error Boundary 有什么区别？	全局捕获资源/脚本/Promise，Boundary 捕获组件树；两者互补，跨域堆栈有边界	浏览器机制
Beacon 一定可靠么？	只保证浏览器接受入队，不保证服务端处理；用隐藏/卸载事件、持久化 outbox（若需要跨启动补偿）和幂等处理，无法持久化时明确接受丢失	浏览器高频追问
大促为什么要分 Biz/Application/System？	业务指标先反映用户影响，应用/系统指标定位原因；每层按黄金信号和预案关联	前端稳定性
如何防告警风暴？	fingerprint 聚合、影响面/趋势分级、多指标抑制和明确升级路径	项目面试追问清单
怎么证明监控有效？	固定 release、路由、样本和窗口，测采集质量、定位时间、恢复时间和回归缺陷；不引用宣传数字	技术误区与验证

14. 交付清单

• 事件信封、ID、release、trace 和脱敏规则有版本。
• 错误、资源、请求、性能和行为采集区分预期取消与真实失败。
• 队列有条数/字节上限、优先级、退避、熔断和降级。
• Source Map、构建产物、发布版本和回滚入口可关联。
• 大促入口、依赖、容量、Biz/Application/System 指标和预案齐全。
• 告警有阈值、持续时间、角色、升级和恢复条件。
• 通过故障注入、隐私、Beacon、灰度、回滚和演练验证。
• 指标带版本、样本、基线和时间线，不把示例收益当事实。

来源：高级前端亮点项目.pdf 第 38-39 页（错误/行为/框架/性能采集、ErrorId、上报链路及 Web/小程序差异）；结合 高频真题解析与9月考点预测上.pdf 第 7-9 页（Cookie、缓存、鉴权与代理）、高频真题解析与9月考点预测中.pdf 第 8-9 页（性能指标和构建缓存）及已有 前端稳定性 整理。