7.3 指标观测与工具链

7.3 指标观测与工具链

本节摘要：凌晨的告警说「有用户反馈卡」，卡在哪一环？没有指标，你只能靠复现玄学；有了指标，一条曲线就能指认元凶。本节讲透统计接口的组织方式与关键字段、浏览器内置诊断工具的用法、三者配合的排查套路，并交付一套可以直接抄走的最小监控方案。这是全册的最后一节——让前面六章的机制在你的线上系统里变得「可见」。

学习目标

阅读完本节，你应当能够：

1. 解释统计报告的组织方式：报告类型、方向、与轨道的关联；
2. 读出带宽估计、丢包率、抖动、往返延迟、解码帧率五类核心指标；
3. 计算端到端的可感延迟与卡顿率，把「卡」变成数字；
4. 熟练使用浏览器内置诊断工具查看连接、图表与完整统计；
5. 设计最小监控方案：指标清单、采样频率、上报通道与告警阈值。

一、问题与直觉：数据一直都在，缺的是管道

WebRTC 引擎内部一直在测量自己：它知道当前估计出多少带宽、收包丢了多少、解码慢了没有。这些数据通过统计接口（getStats）持续可得——多数团队的问题不是数据不存在，而是没建起「采集、上报、聚合、告警」的管道，于是每次线上问题都从零复现开始。

统计报告的组织方式值得先说清：getStats 返回的是一批带类型的报告对象，有出向媒体报告（发送侧的码率、编码参数）、入向媒体报告（接收侧的丢包、抖动、解码帧率）、连接报告（候选对与往返时间）、入向远程报告（对端视角的接收情况）等。方向与关联是读统计的两个基本功：同一条视频，「我发送的」与「对方收到的」分属两份报告；而「对方收到的」要从我这端的远程入向报告里读——这是初学者最容易晕的地方。

二、核心方法：关键字段与采集管道

一个周期采集的骨架，字段注释即含义：

// 每两秒采一次核心指标（生产建议再抽稀到五到十秒上报）
async function sample(pc, send) {
  const stats = await pc.getStats();
  const snap = { ts: Date.now() };
  stats.forEach((r) => {
    if (r.type === 'outbound-rtp' && r.kind === 'video') {
      snap.sendBitrate = r.bytesSent;          // 差分后得发送码率
      snap.framesEncoded = r.framesEncoded;    // 差分后得编码帧率
      snap.encoderQP = r.qualityLimitationReason; // 降质原因 带宽或CPU
    }
    if (r.type === 'inbound-rtp' && r.kind === 'video') {
      snap.recvBitrate = r.bytesReceived;
      snap.packetsLost = r.packetsLost;        // 累计丢包 差分得丢包率
      snap.jitter = r.jitter;                  // 到达抖动 秒
      snap.framesDecoded = r.framesDecoded;
      snap.framesDropped = r.framesDropped;    // 解码跟不上或迟到丢弃
    }
    if (r.type === 'candidate-pair' && r.state === 'succeeded') {
      snap.rtt = r.currentRoundTripTime;       // 往返时间 秒
    }
    if (r.type === 'remote-inbound-rtp') {
      snap.remoteJitter = r.jitter;            // 对端视角 抖动
      snap.remoteLoss = r.fractionLost;        // 对端视角 丢包比
    }
  });
  send(snap);   // 上报到你的聚合通道
}
​

从原始字段到用户语言需要两步换算。可感延迟 ≈ 编码耗时 + 网络单向延迟（rtt 的一半近似）+ 抖动缓冲深度 + 解码排队——统计里能拿到的是中间两项，端侧两端要自己埋点。卡顿率 = 丢帧数除以应收帧数，或用「渲染帧间隔超过阈值的时间占比」——后者更贴近体感。这两个换算后的指标，才是给产品与支持团队看的语言。

浏览器内置工具是联调阶段的主力：Chrome 与 Edge 的内置诊断页（地址栏输入关于 webrtc-internals 的内部地址）实时展示每条连接的图表——码率曲线、丢包曲线、状态机时序、完整统计转储，还能一键下载。它的问题是一次性的、本地的，适合「复现一遍看曲线」，不适合长期观测——所以它与自建监控是互补关系。

图：从引擎指标到告警的观测管道

三、工程实践要点：排查套路与采样分寸

带着指标的排查套路是先分区、再归因。第一步分区：发送端自视指标正常而对端体验差，看「远程入向」报告——差在丢包就查链路，差在帧率就查解码端性能；两端都差，查发送端编码与采集源头。第二步归因：码率塌了看降质原因字段（带宽受限还是 CPU 受限，处置方向完全不同）；丢包高但抖动低像固网拥塞，抖动也高像无线干扰。每一步都有对应章节的处置方案（第 6 章调质量、第 4 章查链路）。

采样要有分寸。统计接口调用本身有开销，全量指标高频上报在低端设备上是「监控拖垮通话」的反例。分寸感的三条惯例：差分在端上算（上报速率值而不是累计值，服务端不再回算）；入会与挂断各发一份全量快照（事后归因最需要）；中间态低频抽稀（五到十秒一组核心字段）。

完整案例：一次「卡顿集中在某城市」的定位

背景：某产品监控看板发现卡顿率指标整体正常，但客服工单集中指向某城市，两端数据互相推诿，无法定责。

操作：聚合层按城市维度重算分位数，确认该城市卡顿率显著偏高且集中在特定运营商；对照「远程入向」报告发现丢包比高、抖动正常——固网链路拥塞特征。进一步比对该运营商用户的 TURN 中继使用比例，发现显著高于全局（直连失败率高），而中继节点的机位距该城市较远，绕行放大了劣化。处置：中继集群增加该区域的节点、调整选点策略，并联系该运营商反馈互联带宽问题。

结果：该城市卡顿率降到全局水平；监控看板新增「城市 × 运营商 × 中继比例」的常驻维度，此后同类问题在工单出现前就能看到曲线异常。

解读：这个案例展示了观测管道的复利：单次排查的维度切法（城市、运营商、中继比例）沉淀为看板的常驻能力，观测系统从「问题的记录者」变成「问题的预警者」。指标建设的投入产出，全部在这类「第二次问题变简单」的时刻兑现。

变式：没有自建聚合能力的团队，起步方案可以更轻：把采样骨架嵌进客户端，入会与异常时把快照随工单上报（JSON 文本），配合内置诊断页的转储，够支撑初期运营。观测体系是渐进演进的，别等「完美的监控平台」立项才开始采集——管道从第一份数据就开始积累价值。

本节要点回顾

• 统计是方向感训练：出向、入向、远程入向各管一面，对端体验要读「对端视角」的报告。
• 换算成用户语言：可感延迟与卡顿率是产品与支持团队需要的两个最终指标。
• 内置工具与自建监控互补：前者复现看曲线，后者长期看趋势，缺一不可。
• 采样有分寸：端上差分、两头快照、中间抽稀，别让监控拖垮通话。
• 排查先分区再归因：指标把「卡」拆成链路、编码、解码三案，各自对应前面的章节。