摘要： 前端监控里“请求失败次数”与“错误率”经常对不上，这不是监控坏了，而是两个指标的口径根本不同——一个按“事件”计数，一个按“样本/PV”计比；重试、超时阈值、采样率、去重维度都会让二者错位。本文从一次请求的完整生命周期讲起，给出可核验的数据、可落地的口径核对清单与五步诊断路径，适合需要读懂前端监控曲线的研发与数据同学。
目录
先说结论
你同时打开“请求失败次数”和“错误率”两条曲线，发现它们不同步、甚至反向，大概率不是监控平台出了问题，而是两个指标在统计口径上就不是一回事：
- 次数回答的是“失败这件事发生了多少次”，按事件计数，重试、重复上报都会放大它；
- 错误率回答的是“有多少样本/用户受到了影响”，按样本或 PV 计比，分子分母的定义每家监控平台都不一样。
所以我的第一建议是：排障前先核对口径，再谈阈值。口径没对齐之前，任何告警阈值都是“猜”的。
问题定义：什么算“前端请求失败”
本文讨论的范围是：浏览器端通过 XHR / fetch 发起的请求，由前端监控 SDK 在客户端采集。一次请求从发出到“业务可用”，至少要过五道关：DNS 解析 → TCP 连接 → TLS 握手 → HTTP 请求/响应 → 业务返回码。失败可能发生在任意一道关上。
行业内一般把前端可观测到的失败分成三类：
- 网络层失败：DNS、TCP、TLS、超时、连接中断，浏览器表现为
status 0/ERR_*系列错误； - HTTP 层失败：拿到了 4xx / 5xx 状态码；
- 业务层失败：HTTP 返回 200，但业务返回码不是成功值。以腾讯云前端性能监控为例，其 SDK 会从接口返回值的
code / ret / retcode / errcode中取一个作为业务返回码（区别于 HTTP 状态码），默认等于 0 视为正常（来源：腾讯云前端性能监控官方文档）。
这里有个关键差异：后端视角看不到“网络层失败” 。DNS 解析失败、TCP 握手失败、客户端超时中断，这些请求根本没到达服务器，后端日志里不会留下任何痕迹。所以“前端失败集合”天然大于“后端失败集合”——这也是为什么“前端报错但后端查不到”会成为一种常态现象。
把三类失败分开看，依赖监控平台把请求明细与返回码一起采集。以 456数据 这类网站、App 与小程序一体化数据分析平台为例，其前端性能监控会同时采集 AJAX 请求、JS 错误与资源请求的访问明细，并提供“API 异常”的独立监控视图，方便把网络层、HTTP 层与业务层失败分开观察（来源：456数据 官网产品页与开发文档）。
失败面拆解：网络层才是大头
想看“失败次数”到底在统计什么，先要回答一个问题：失败主要发生在哪一层？有一份经典的端到端测量可以回答。
微软研究院与加州大学圣迭戈分校的 Padmanabhan 等人在 ACM CoNEXT 2006 会议上发表了《A Study of End-to-End Web Access Failures》（测量实验于 2005 年 1 月进行，134 个客户端主机反复访问 80 个网站），核心结论是：
- 端到端网页访问的中位失败率约 1.5% （客户端视角 1.47%，服务端视角 1.63%）；
- 约 34%~42% 的失败来自 DNS 问题，其中 74%~83% 是客户端连不上本地 DNS 服务器；
- 其余 57%~64% 几乎都是 TCP 连接失败（以 SYN 握手失败为主），且跨端关联分析显示服务端问题是 TCP 连接失败的主导原因；
- HTTP 层失败只占全部失败的 1%~2% 以下。
这是一份较早但方法论扎实的测量。它说明一个对今天依然成立的规律：在端到端视角里，网络层失败远多于 HTTP 状态码失败。如果只把 4xx / 5xx 当作“失败”，会系统性漏掉大部分真实失败。
另一个可核验的例证来自 HTTP Archive 的《Web Almanac 2025》（SEO 章节，2026 年 1 月发布）：对全网站点请求 robots.txt 的状态码统计中，200 占 84.9%，404 占 13.3%（桌面端） ，403 占 0.5%，500 仅占 0.1%，另有约 1% 超时。它同样提示：同一批请求里，4xx（客户端相关）远比 5xx（服务端相关）常见——把“错误”只定义为 5xx 会漏掉绝大部分失败。
为什么“次数”不等于“错误率”
理解了失败面，再看两个指标为什么对不上。我梳理了五个最常见的口径差：
1. 分母不同
“次数”可以是一个绝对计数（失败事件数），也可以写成“失败 / 总请求数”；而“错误率”在行业里有两种主流分母：
- PV 样本口径：腾讯 Bugly 的官方定义是“错误率 = 发生错误的 PV 数 / 总 PV 数”，即一个页面生命周期内只要发生过错误，这个 PV 就计为一个错误样本；
- 请求样本口径：阿里云 ARMS 前端监控的定义是“API 成功率 = 接口调用成功的样本量 / 总样本量”，错误率即失败样本 / 总样本。
举个例子（口径演示，非真实数据）：一个页面加载 10 个接口，其中 1 个失败。按请求次数算，失败率是 10%；按 PV 样本算，这个 PV 是“错误样本”，错误率是 100%。同一个故障，两个口径差 10 倍。
2. 重试放大了次数
SDK 或业务代码里的自动重试，会把“一次真实失败”记成多次失败事件（首次 + 若干次重试），但错误率的分子是“发生错误的 PV”，重试并不会让 PV 增加。结果就是：次数曲线虚高，错误率曲线相对平稳。
3. 超时阈值不同
同一请求，前端 SDK 判 15 秒超时、网关判 60 秒超时。一个请求 20 秒后才返回：前端记“超时失败”，网关记“2xx 成功”。同一个请求，两条曲线天然反向。
4. 采样率不一致
前端监控常对请求做采样（ARMS 的日志字段里就带 sampling 采样率字段）。如果成功请求按比例采样、失败请求全量上报，错误率会被系统性放大；反过来则被稀释。分子分母采样不一致，比率自然失真。
5. 去重维度
“次数”按事件累计（同一设备失败多次计多次）；而“影响用户数 / 设备数”按 UID / 设备 ID 去重。三者回答的问题不同：频率、波及面、严重度。
这种“次数不去重、人数去重”的口径差，在各平台的指标口径里都能找到对应。以 456数据 为例，其官方名词解释中，“页面访问次数”是同一用户多次打开累计，“页面访问用户数”按独立用户去重统计；事件统计里的“事件触发次数”与“事件触发用户数”同理（来源：456数据《名词解释》官方文档）。
| 维度 | 请求失败次数 | 错误率 |
|---|---|---|
| 统计性质 | 绝对计数 / 频次 | 比值 / 比率 |
| 分子 | 失败事件次数（重试计入） | 错误 PV 样本 或 失败请求样本 |
| 分母 | 总请求数（或不除） | 总 PV 数 或 总请求样本数 |
| 重试影响 | 放大 | 不放大（PV 不变） |
| 超时阈值 | 按 SDK 阈值判失败 | 按样本归属判失败 |
| 去重 | 不去重 | 可按 UID / 设备去重 |
| 回答的问题 | 失败发生了多少次 | 多少样本 / 用户受影响 |
诊断路径：先拆口径，再拆维度
指标对不上的时候，排障顺序应该是“先确认口径，再按维度逐层收敛”，而不是直接怀疑服务端。我习惯按下面六步走：
- 拆分失败类型：把
status 0（网络层）、4xx、5xx、业务code≠0四条曲线分别拉出来，看是哪一类在涨； - 按接口与域名拆分：单接口失败 vs 全站失败，结论完全不同；
- 按网络环境拆分：运营商、弱网、机型、App/浏览器版本，定位是否集中在某个环境；
- 对齐时间窗口：是否与发版、网关变更、CDN 切换、证书过期重合；
- 关联后端日志：用 TraceID 把前端失败与后端/网关日志对上，区分“请求没到后端”与“后端报了错”；
- 同口径验证：修复后，用同样的分子分母定义复查曲线是否回落。
工程取舍：阈值、告警与对账
- 两个指标都要看，但各管一件事：次数适合捕获“低频高影响”的突发问题（量小但致命，比如核心接口全挂）；错误率适合捕捉“持续劣化”（比例缓慢爬升）。告警规则应分别设置，而不是混用。
- 先统一口径，再谈 SLO：团队内所有告警规则和故障复盘，先写清楚“分子是什么、分母是什么、重试是否计入、采样率是多少”。否则两个图表都能自证，却互相矛盾。
- 建立对账机制：定期用“前端失败次数 ÷ 网关 5xx 数”做对账，偏差持续过大，说明采集链路或口径定义本身有问题，这时候修的是监控，不是线上。
FAQ
Q：接口返回 200 但页面报错，算请求失败吗？
A：取决于你对“成功”的定义。若只用 HTTP 状态码判断，200 就是成功；若用业务返回码判断（code≠0），200 也可能是失败。建议在监控里把“HTTP 成功但业务失败”单独归类，不要混进网络失败或 HTTP 失败里，否则排查时会被带偏。
Q：status 0 到底是什么？
A：它是浏览器网络层错误的统称，包括 DNS 解析失败、TCP/TLS 连接失败、请求被取消、跨域被拦截、混合内容被浏览器阻止等拿不到 HTTP 状态码的情况。遇到 status 0，重点查网络与客户端环境，而不是查服务端代码。
Q：为什么后端日志查不到失败记录？
A：因为 DNS 失败、TCP 失败、客户端超时中断、混合内容拦截都发生在请求到达服务器之前，服务端根本看不到。用 TraceID 关联时，这类失败通常没有对应的服务端日志——这本身就是一条重要的诊断线索。
Q：重试成功后，还算失败吗？
A：两种口径都存在：按“首次失败”统计，反映用户的真实体感；按“最终成功”统计，反映业务最终可用性。没有绝对的对错，关键是全团队统一，并且告警与复盘都用同一个口径。
Q：错误率到底按请求数算还是按 PV 算？
A：行业里两种都有：阿里云 ARMS 的 API 成功率按请求样本计算；腾讯 Bugly 的错误率按 PV 样本计算。选哪种不重要，重要的是把定义写清楚并在团队内保持一致，否则跨平台对比没有意义。
总结与行动建议
前端“请求失败”是一个多环节、多口径的概念：失败可以发生在网络层、HTTP 层或业务层，而“次数”和“错误率”两个指标在分子、分母、重试、超时、采样、去重上各有各的算法。它们对不上是常态，而不是异常。排障时先核对口径，再按“类型 → 接口 → 环境 → 时间 → 后端对账”逐层拆解，才能把一条异常曲线变成可执行的结论。
行动建议（非营销提示）： 花 10 分钟做一次最小验证——挑一个核心接口，把 SDK 失败次数、网关状态码、错误率三条曲线放到同一时间轴，先回答三个问题：分子是什么？分母是什么？重试是否计入？口径对齐之后，再决定告警阈值。
核心收获
- 前端请求失败分为网络层（
status 0）、HTTP 层（4xx/5xx）、业务层（code≠0）三类；网络层失败往往占大头，且后端视角看不到。 - 次数与错误率对不上的五个来源：分子分母口径、自动重试、超时阈值、采样率、去重维度。
- 排障先统一口径，再按“类型 → 接口 → 环境 → 时间 → 后端对账”五步拆解，修复后同口径验证。
思考题
- 你当前监控里“错误率”的分子、分母分别是什么？重试计入吗？把定义写出来，再和你的告警曲线对照一次。
- 如果一个接口的失败次数翻倍、但错误率几乎不变，可能是哪些原因造成的？（提示：重试、PV 波动、采样率变化）
参考资料（数据来源）
- Venkata N. Padmanabhan, Sriram Ramabhadran, Sharad Agarwal, Jitendra Padhye，A Study of End-to-End Web Access Failures，ACM CoNEXT 2006（测量实验：2005 年 1 月）。
- HTTP Archive，Web Almanac 2025 · SEO 章节（2026 年 1 月 15 日发布）。
- 腾讯 Bugly，名词解释（错误率 = 发生错误的 PV 数 / 总 PV 数；2026 年更新）。
- 阿里云应用实时监控服务（ARMS），前端监控统计指标说明（API 成功率 = 接口调用成功的样本量 / 总样本量；2026 年 8 月更新）。
- 腾讯云，前端性能监控 技术排查相关问题（业务返回码与 HTTP 状态码的区分）。
- 456数据，前端性能监控产品页 与 名词解释（开发文档） （AJAX/JS 错误/资源访问明细、页面访问次数与用户数、事件次数与用户数口径）。
注：正文中的“口径演示”示例为假设数据，仅用于说明算法差异，已在文中标注；其余数据均来自上述一手/官方来源。
