全链路监控：前端稳定性报警与日志追踪大盘构建

先说几个核心判断：前端稳定性报警和日志追踪大盘，并非简单拼凑一个埋点SDK、加上上报、再挂一个前端监控平台就能实现。关键在于，从页面加载那一刻起，TraceID就必须贯穿请求、资源加载、错误捕获、用户操作乃至整个上报链路——并且，它需要与后端的链路天然对齐。做不到这一点，所谓的“全链路”只是一个前端视角的单点幻觉。

前端如何生成并透传统一的TraceID

这里的关键不是“有没有ID”，而是这个ID能否与后端SkyWalking、OpenTelemetry生成的链路无缝对接。手动拼接或随机生成的trace_id，在跨域、重定向以及微前端场景下，极易断裂。

• 推荐做法：在HTML模板首次渲染时，由服务端注入一个全局变量 window.__TRACE_ID__ = "xxx"。这个值必须与后端入口（如Nginx或网关）生成的trace_id保持一致。
• 所有XHR/Fetch请求都必须携带这个ID。要么放在W3C标准格式的traceparent头部，要么用自定义header（如X-Trace-ID）。注意，为防止被CORS拦截，需提前配置Access-Control-Expose-Headers。
• 在微前端架构下，由主应用负责初始化并向下透传。子应用通过props或qiankun的getAppData获取，严禁各自为政、自行生成ID。
• 一个容易被忽视的细节：像Sentry、Bugsnag这类错误监控SDK，默认不会传递trace_id。需手动通过beforeSend钩子把ID注入进去。

前端日志如何与后端链路一键关联

在日志字段里写个trace_id: "abc123"，并不等于“可关联”。ELK或Loki能否根据这个字段快速跳转到SkyWalking对应链路的详情页，取决于日志结构、索引策略和上报时机。

• 前端日志必须结构化为JSON格式，且顶层字段必须包含trace_id、span_id、timestamp（要求毫秒级）、level、msg、url、ua。
• 上报日志时，务必复用同一个trace_id，并在span_id中体现层级关系。例如，根span用root，API请求用api-/order/list。
• 要避免日志打点过载。用户滚动、鼠标移动这类高频事件，一律不打日志。只保留error、warn和关键业务节点（如“下单按钮点击”、“支付回调成功”）。
• 在Loki中必须配置__labels__包含trace_id。这样，在Grafana查询时，才能用{trace_id="xxx"}直接联动到SkyWalking的trace详情页。

哪些前端指标真正影响稳定性报警有效性

“JS错误率 > 0.5%”这类告警，实话实说，毫无意义。它既不分错误类型，也不看影响范围，更别指望它能触发精准定位。真正可用的报警，必须绑定上下文维度。

• 优先监控这几个指标：白屏率（首屏内容为空的PV占比）、接口失败率（不是指HTTP 5xx错误，而是指fetch().catch捕获到失败，或响应体中的code !== 0）、资源加载失败率（通过script/css的onerror事件捕获）、长任务阻塞（利用longtask API统计主线程连续阻塞超过50ms的次数）。
• 报警必须带标签。按env（如prod/staging）、page（如/cart、/pay）、browser（如Chrome 124+、Safari 17.5）、region（如cn-shenzhen、us-west）进行切分。否则，一告警就全量推送，运维团队会直接选择静音。
• Prometheus不太适合直接采集前端指标。一个更推荐的做法：用Grafana的Alerting rules基于Loki的日志聚合结果来触发。例如，过去5分钟内，level="error" | json | trace_id != "" | __error_type__ == "network_timeout"出现了10次以上。
• 要避免“告警风暴”。对于同一个trace_id下的多个错误，只对根因进行告警（比如第一个JS错误或第一个网络失败），其余错误都标记为caused_by。

为什么你搭的大盘查不到“那次用户点击没反应”

问题通常出在链路的最前端：你没有记录用户操作前的环境快照，也没有把用户行为（click、tap、input）作为一个Span显式创建出来。结果就是，日志和追踪里只有一堆“空白请求”和“报错”，却完全找不到“是谁、在哪、点了什么之后崩溃的”。

• 必须将关键的用户交互封装为performance.mark()加上自定义Span。例如，startSpan("ui-click-checkout-btn")，并在后续的fetch操作完成后endSpan()。
• 上报日志时，自动捕获document.activeElement、location.href、performance.navigation.type以及performance.getEntriesByType("navigation")[0].type（区分是reload还是back_forward）。
• 不要依赖console.error的自动捕获，因为它拿不到堆栈上下文里的变量值。改用try/catch配合Error.captureStackTrace（类似Node.js风格），或者用stacktrace-js做增强采集。
• 移动端真机问题最难复现？在日志中强制带上screen.width x screen.height、devicePixelRatio、navigator.connection.effectiveType。这些字段比单纯的“iOS 17.6”有用十倍。

最后，一个最容易被忽略的点：前端链路的起点，不是DOMContentLoaded，而是navigationStart。如果你没有从performance.timing或Navigation Timing API中取到这个时间戳，所有耗时计算都会偏差100~300毫秒。而这个偏差，刚好会掩盖掉CDN缓存失效、DNS预热失败这类真实的性能瓶颈。