# 第 11 部分导论 · 看不见的通话怎么调试

> WebRTC 的问题往往在线上、在别人的网络里、还无法复现——这让「可观测性」成了刚需。这一章讲清 WebRTC 可观测性的两大支柱：getStats（实时指标快照）与 RtcEventLog（事后逐事件回放），以及它们各自回答什么问题。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/webrtc/observability-overview
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 第 11 部分导论 · 看不见的通话怎么调试

引擎（[第 0~9 部分](https://daiw.org/manual/webrtc/call-recap)）和地基（[第 10 部分](https://daiw.org/manual/webrtc/rtc-base-recap)）都齐了。但真实产品里最头疼的事往往是：**用户说“卡了”“听不清”，而你什么都看不见**。这一部分讲 WebRTC 怎么让“看不见的通话”变得**可观测、可调试**。

## 为什么 WebRTC 特别难调试

<Callout type="info">
  **WebRTC 的 bug 有三个特点，让传统调试手段几乎失效：**

  - **在线上、在别人的网络里** —— 问题常出在[用户的弱网、NAT、防火墙](https://daiw.org/manual/webrtc/ice-overview)环境，你的开发机上一切正常。你没法 attach 调试器到用户的浏览器。
  - **无法复现** —— [网络状况](https://daiw.org/manual/webrtc/congestion-control-overview)瞬息万变，“刚才那 3 秒卡顿”可能永远不会以同样的方式再来一次。断点调试对“一次性、时序相关”的问题无能为力。
  - **跨越十几个子系统** —— 一次“卡顿”可能源于[带宽估计过低](https://daiw.org/manual/webrtc/delay-based-bwe)、[丢包重传](https://daiw.org/manual/webrtc/nack-rtx)、[jitter buffer 拉长](https://daiw.org/manual/webrtc/video-jitter-buffer)、[编码器降质](https://daiw.org/manual/webrtc/video-adaptation)……问题在哪个环节？光看现象说不清。

  所以 WebRTC 不能靠“打断点、看日志”这类传统手段，必须**内建可观测性**——让引擎在运行时**自己吐出足够的数据**，事后能重建“当时到底发生了什么”。这不是可选功能，是[实时通信产品](https://daiw.org/manual/webrtc/what-is-webrtc)的生存必需。
</Callout>

## 两大支柱：快照 vs 回放

WebRTC 的可观测性由两套互补的机制支撑，回答不同的问题：

```mermaid
flowchart TD
    RTC["一次运行中的通话"] --> STATS["getStats() / RTCStatsReport<br/>实时指标快照"]
    RTC --> LOG["RtcEventLog<br/>逐事件二进制日志"]
    STATS -->|"现在怎么样?"| Q1["实时监控 / 仪表盘<br/>当前码率、丢包、RTT、分辨率"]
    LOG -->|"刚才发生了什么?"| Q2["事后回放 / 可视化<br/>重建带宽估计、jitter 的时间线"]
```

| 支柱 | 是什么 | 回答的问题 | 本部分 |
| --- | --- | --- | --- |
| [`getStats` / `RTCStatsReport`](https://daiw.org/manual/webrtc/stats-report) | 某一刻的**指标快照**（[W3C 标准](https://daiw.org/manual/webrtc/stats-report)） | “**现在**怎么样？” | [第 2~3 章](https://daiw.org/manual/webrtc/stats-report) |
| [`RtcEventLog`](https://daiw.org/manual/webrtc/rtc-event-log) | 逐事件的**二进制日志** | “刚才**发生了什么**？” | [第 4~5 章](https://daiw.org/manual/webrtc/rtc-event-log) |

<Callout type="info">
  **`getStats` 是“**快照**”——它给你**此刻**的一组数字（[当前码率、丢包率、RTT、分辨率、jitter](https://daiw.org/manual/webrtc/stats-report)），适合做实时监控、仪表盘、质量告警。`RtcEventLog` 是“**录像**”——它把通话期间的[每个关键事件](https://daiw.org/manual/webrtc/rtc-event-log)（收发的 RTP 头、RTCP、[ICE 事件](https://daiw.org/manual/webrtc/connection-and-checks)、[带宽估计变化](https://daiw.org/manual/webrtc/delay-based-bwe)）逐条记下来，事后能**逐帧回放**、画成图，重建问题现场。** 两者互补：

  - 想知道“**这通电话质量如何**”、做线上监控 → 用 [`getStats`](https://daiw.org/manual/webrtc/stats-report)（轻量、标准、可持续采集）。
  - 想**深挖一个具体问题**“为什么第 30 秒开始卡” → 抓 [`RtcEventLog`](https://daiw.org/manual/webrtc/rtc-event-log)，用[可视化工具](https://daiw.org/manual/webrtc/event-log-visualizer)看那一刻[带宽 / 丢包 / jitter](https://daiw.org/manual/webrtc/delay-based-bwe) 的曲线。

  一个是“体温计”（随时读个数），一个是“[黑匣子](https://daiw.org/manual/webrtc/rtc-event-log)”（出事了调出来还原）。真实排障中两者常配合：先用 stats 发现异常，再用 event log 定位根因。
</Callout>

## 这一部分怎么安排

- [`getStats` 与 `RTCStatsReport`](https://daiw.org/manual/webrtc/stats-report) —— 快照的数据模型：[W3C 标准的 stats 类型](https://daiw.org/manual/webrtc/stats-report)、怎么读。
- [统计的收集](https://daiw.org/manual/webrtc/stats-collection) —— 这些指标[从各子系统怎么汇集](https://daiw.org/manual/webrtc/stats-collection)成一份报告（跨线程收集的机制）。
- [`RtcEventLog`](https://daiw.org/manual/webrtc/rtc-event-log) —— 黑匣子：记什么、二进制格式。
- [可视化与排障](https://daiw.org/manual/webrtc/event-log-visualizer) —— 用 `event_log_visualizer` 把日志[画成图](https://daiw.org/manual/webrtc/event-log-visualizer)、定位问题的实战。
- [回顾与其他手段](https://daiw.org/manual/webrtc/observability-recap) —— 两支柱配合，加上 [`RTC_LOG` / field trials / webrtc-internals](https://daiw.org/manual/webrtc/observability-recap)。

## 小结与下一章

WebRTC 的 bug [常在线上、在别人的网络、无法复现、跨十几个子系统](https://daiw.org/manual/webrtc/what-is-webrtc)，传统“打断点”手段失效，所以它**内建可观测性**。两大支柱互补：**[`getStats`/`RTCStatsReport`](https://daiw.org/manual/webrtc/stats-report)** 是“快照 / 体温计”，给[此刻的标准指标](https://daiw.org/manual/webrtc/stats-report)，适合[实时监控](https://daiw.org/manual/webrtc/stats-report)；**[`RtcEventLog`](https://daiw.org/manual/webrtc/rtc-event-log)** 是“录像 / 黑匣子”，逐事件记录、事后[可视化回放](https://daiw.org/manual/webrtc/event-log-visualizer)，适合深挖具体问题。先发现异常、再定位根因，两者配合。

先看第一支柱——**getStats 的数据模型**。👉 [getStats 与 RTCStatsReport](https://daiw.org/manual/webrtc/stats-report)。

## 参考资料

- [1] libwebrtc 源码.`api/stats/`、`rtc_event_log/rtc_event_log.h`。
- [2] WebRTC 官方 `g3doc/rtc_event_log.md`。
- [3] W3C「Identifiers for WebRTC's Statistics API」（getStats 标准）。