标签频道
错误监控
该标签下的文章、提问与讨论帖。
«结论先行：RUM 大盘最容易被低估的污染源不是弱网、不是低端机，而是同一用户同时开 3~5 个标签页这件事本身——它把 LCP 拉成「假健康」、把同一个 bug 的影响面放大成 3 倍、把并行会话串成一条超长会话。根因是几乎所有 RUM
«结论先行：前端错误监控的瓶颈不是「采不到」，而是采到了但没人信——错误流里混着大量浏览器边界行为、用户操作和第三方脚本的噪音，值班同学对告警脱敏后，真正的 P0 反而被淹没。本文给出一套「4 维分类矩阵 + 6 条过滤规则」，把需要人看的
【背景】 我做了 3 年前端（CRA → Next.js 14 App Router），团队从 8 人扩到 20 人，前端应用 6 个（H5 + 小程序 + 一个 Electron 壳）。后端有 SkyWalking + Jaeger +
«结论先行：前端错误监控「报了但排不了障」，一半的根因不是监控 SDK 没采全（见 @顾砚舟 的落地文），而是还原链断了——线上 bundle 与其对应的 sourcemap 文件在版本上错配。我们一次事故里 40% 的线上错误在还原服务里
【背景】 做了 10 年前端，最近半年把团队的前端可观测性链路（RUM + 错误上报 + 性能指标）重新梳理了一遍。最纠结的一件事是采样率到底怎么定。 我们的量级：核心页面 DAU 约 80w，日均 PV 约 400w，走的是自研上报 SD
背景 我做了 8 年前端，目前带一个 B 端中台（React 18.2 + Vite 5 + TS 5.4，约 90 个路由，月 UV 80 万）。错误监控链路是 "window.onerror" + "unhandledrejection
背景 我做了 5 年前端，从 SaaS B 端（月 UV 50 万）做到 C 端（月 UV 500 万），错误监控一路踩坑。最痛的一次：某支付回调页面报错，Sentry 默认 100% 上报但被我们「按项目」限流到了 5%，结果一个「银行侧
【背景】 React 18 + Vite 5 的 B 端中台，约 200 个路由，用 Workbox 做 Service Worker 预缓存（precacheManifest 约 380 个资源）。错误上报走 Sentry，sourcem
【背景】 我们是一个 B 端运营中台，React 18 + qiankun 2.x 微前端架构，宿主（Shell）+ 6 个子应用（订单、商品、营销、数据看板、审批、设置）。每个子应用独立发版、独立维护 Sentry 项目。日活约 800
背景：我在做一个内部中后台（Vue 3 + Vite），线上错误上报后拿到的是压缩后的 "TypeError: Cannot read properties of undefined (reading 'x') at a.b (app.3f
【背景】 React 18 + Vite 5 的 B 端中台，主线程之外拆了 3 个 Worker：一个跑 Markdown 解析（约 200k 行代码）、一个跑图表渲染（OffscreenCanvas）、一个跑本地搜索索引。今年把 Sen
【背景】React 18 + Vite 5 的 B 端中台，约 80 个路由、十几个三方 SDK（埋点、IM、风控）。今年把 Sentry 自建替换成一套自研上报链路（错误 + 性能 + 用户行为），按 (错误消息 + 堆栈前 N 帧) 做
背景 做了 15 年前端，这两年越来越觉得：前端可观测性最大的坑，不是「没监控」，而是「监控上了，但要么贵到没人敢全开，要么采样开到关键信号全丢了」。我最近在给一个日活千万级的 C 端 H5 重构上报链路，正好把这个问题逼到桌面上了：错误日
结论先行 前端线上稳定性最大的坑，不是「没监控」，而是监控了但报错对不上号：拿到一条 "TypeError: Cannot read properties of undefined"，既不知道哪个页面、哪个版本、哪个用户，也没法复现。我在
文
标题
摘要