Web 直播音视频质量监控与故障排查：从端到端指标到问题定位

直播故障发生时的排查速度直接决定损失规模。一场电商大促直播如果卡顿 1 分钟，可能损失数十万 GMV。本篇将从可观测性指标入手，以即构(ZEGO) RTC 为例讲解 Web 直播的全链路质量监控体系和常见问题的定位方法。

核心质量指标

Web 直播的质量由以下核心指标定义，每个指标都能通过 SDK 实时获取。

上行质量（推流端）

下行质量（拉流端）

实时监控方案

SDK 端质量回调

ZEGO Express SDK 提供实时推拉流质量回调接口，应用层可以在直播过程中持续获取质量数据。

// 推流质量回调
zg.on('publishQualityUpdate', (streamID, quality) => {
  console.log('[推流]', {
    流ID: streamID,
    延迟: quality.delay + 'ms',
    丢包率: (quality.packetLostRate * 100).toFixed(1) + '%',
    发送码率: quality.videoSendBitrate + 'kbps',
    帧率: quality.videoSendFps + 'fps',
    音频送码率: quality.audioSendBitrate + 'kbps',
  });
});

// 拉流质量回调
zg.on('playQualityUpdate', (streamID, quality) => {
  console.log('[拉流]', {
    流ID: streamID,
    接收码率: quality.videoRecvBitrate + 'kbps',
    卡顿次数: quality.videoBreakRate,
    延迟: quality.delay + 'ms',
    丢包率: (quality.packetLostRate * 100).toFixed(1) + '%',
  });
});

通话前网络检测

在用户进入房间前进行网络环境评估，提前预知上行/下行带宽是否满足直播需求。

zg.startNetworkSpeedTest({
  testUplink: true,
  testDownlink: true,
  expectedBitrate: 1500,
}).then(result => {
  if (result.quality === 'EXCELLENT') {
    // 流畅推流 1080p
  } else if (result.quality === 'GOOD') {
    // 推流 720p
  } else if (result.quality === 'POOR') {
    // 建议降低清晰度或切换网络
  }
});

线上故障排查流程

当收到用户投诉”直播卡顿”时，按以下链路排查：

第一步：确认是局部问题还是普遍问题

查看全链路监控平台（如 ZEGO 星图），确认当前一段时间内有问题的用户数量和区域分布：

• 只有一个用户卡顿 → 大概率是该用户本地网络或设备问题
• 同一区域多个用户卡顿 → 该区域 CDN 节点或网络问题
• 全部用户卡顿 → 推流端或服务端问题

第二步：定位推流端

检查推流端的质量数据：

• RTT 高 + 丢包率高 → 推流端上行网络问题
• 发送码率稳定但 RTT 高 → 推流端到媒体服务器之间的传输链路问题
• CPU 占用率高 + 帧率低 → 推流端设备性能不足

第三步：定位拉流端

检查拉流端的质量数据：

• 接收码率持续低于推流码率 → 拉流端下行带宽不足
• 端到端延迟突增 → 抖动缓冲正在吸收网络波动
• 卡顿次数多但接收码率正常 → 可能是播放器渲染问题而非传输问题

第四步：检查服务端

通过运营后台查看流媒体的传输链路：

全链路监控工具

星图（Analytics Dashboard）

ZEGO 提供的全链路质量监控与可视化平台，支持：

• 实时看板：当前在线用户、推拉流质量分布、区域延迟热力图
• 通话 KPI：延迟、卡顿率、丢包率、RTT 等关键指标的趋势图
• 呼叫详单：每个用户每次通话的详细质量记录
• 问题定位：基于用户 ID 或房间 ID 检索特定通话的端到端质量数据

常见问题

怎么看直播卡顿是网络问题还是设备问题？

通过 SDK 质量回调数据区分：如果 RTT 正常但编码帧率低于设定值，且 CPU 占用率高，通常是设备性能问题。如果 RTT 持续升高且丢包率 > 5%，则是网络问题。

用户反馈”画面模糊”怎么办？

画面模糊最常见的原因：一是推流端码率设置过低，二是网络差时触发了自适应降码率。检查推流端的视频发送码率是否低于配置值的 80%，以及拉流端的接收码率是否匹配。

推流失败可能是什么原因？

常见原因包括：浏览器不支持 WebRTC（如 UC 浏览器）、未使用 HTTPS 部署、推流 Token 错误或过期、房间内已有相同流 ID。建议检查推流回调中的错误码定位具体原因。

拉流一段时间后卡顿怎么办？

多发生在长时间直播场景，可能是客户端内存泄漏或浏览器垃圾回收导致。建议：1) 检查浏览器内存占用，2) 确认是否开启了过多的非必要功能（如实时美颜），3) 尝试手动触发 stopPlayingStream 并重新拉流。

多人互动时卡顿更明显，如何处理？

多路拉流时卡顿一般是因为下行带宽不够。建议：1) 减少同时拉流的数量（非活跃用户的流暂不拉取），2) 开启大小流功能（小屏窗口拉低清流），3) 观众端限制最大拉流路数。

总结

• Web 直播质量监控的核心指标是丢包率、延迟、卡顿率和首帧时间，通过 SDK 实时回调可以持续获取这些数据。
• 故障排查从”确认影响范围”开始，按推流端 → 拉流端 → 服务端的链路逐步缩小范围。
• 借助全链路监控平台（如 ZEGO 星图），可以可视化定位从推流端到拉流端全路径上的质量瓶颈，而不是依赖用户反馈”卡了”再盲目排查。