第 11 部分导论 · 看不见的通话怎么调试
WebRTC 的问题往往在线上、在别人的网络里、还无法复现——这让「可观测性」成了刚需。这一章讲清 WebRTC 可观测性的两大支柱：getStats（实时指标快照）与 RtcEventLog（事后逐事件回放），以及它们各自回答什么问题。
第 11 部分导论 · 看不见的通话怎么调试
引擎（第 0~9 部分）和地基（第 10 部分）都齐了。但真实产品里最头疼的事往往是：用户说“卡了”“听不清”，而你什么都看不见。这一部分讲 WebRTC 怎么让“看不见的通话”变得可观测、可调试。
为什么 WebRTC 特别难调试
WebRTC 的 bug 有三个特点，让传统调试手段几乎失效：
- 在线上、在别人的网络里 —— 问题常出在用户的弱网、NAT、防火墙环境，你的开发机上一切正常。你没法 attach 调试器到用户的浏览器。
- 无法复现 —— 网络状况瞬息万变，“刚才那 3 秒卡顿”可能永远不会以同样的方式再来一次。断点调试对“一次性、时序相关”的问题无能为力。
- 跨越十几个子系统 —— 一次“卡顿”可能源于带宽估计过低、丢包重传、jitter buffer 拉长、编码器降质……问题在哪个环节？光看现象说不清。
所以 WebRTC 不能靠“打断点、看日志”这类传统手段，必须内建可观测性——让引擎在运行时自己吐出足够的数据，事后能重建“当时到底发生了什么”。这不是可选功能，是实时通信产品的生存必需。
两大支柱：快照 vs 回放
WebRTC 的可观测性由两套互补的机制支撑，回答不同的问题：
| 支柱 | 是什么 | 回答的问题 | 本部分 |
|---|---|---|---|
getStats / RTCStatsReport | 某一刻的指标快照（W3C 标准） | “现在怎么样？” | 第 2~3 章 |
RtcEventLog | 逐事件的二进制日志 | “刚才发生了什么？” | 第 4~5 章 |
getStats 是“快照”——它给你此刻的一组数字（当前码率、丢包率、RTT、分辨率、jitter），适合做实时监控、仪表盘、质量告警。RtcEventLog 是“录像”——它把通话期间的每个关键事件（收发的 RTP 头、RTCP、ICE 事件、带宽估计变化）逐条记下来，事后能逐帧回放**、画成图，重建问题现场。** 两者互补：
- 想知道“这通电话质量如何”、做线上监控 → 用
getStats（轻量、标准、可持续采集）。 - 想深挖一个具体问题“为什么第 30 秒开始卡” → 抓
RtcEventLog，用可视化工具看那一刻带宽 / 丢包 / jitter 的曲线。
一个是“体温计”（随时读个数），一个是“黑匣子”（出事了调出来还原）。真实排障中两者常配合：先用 stats 发现异常，再用 event log 定位根因。
这一部分怎么安排
getStats与RTCStatsReport—— 快照的数据模型：W3C 标准的 stats 类型、怎么读。- 统计的收集 —— 这些指标从各子系统怎么汇集成一份报告（跨线程收集的机制）。
RtcEventLog—— 黑匣子：记什么、二进制格式。- 可视化与排障 —— 用
event_log_visualizer把日志画成图、定位问题的实战。 - 回顾与其他手段 —— 两支柱配合，加上
RTC_LOG/ field trials / webrtc-internals。
小结与下一章
WebRTC 的 bug 常在线上、在别人的网络、无法复现、跨十几个子系统，传统“打断点”手段失效，所以它内建可观测性。两大支柱互补：getStats/RTCStatsReport 是“快照 / 体温计”，给此刻的标准指标，适合实时监控；RtcEventLog 是“录像 / 黑匣子”，逐事件记录、事后可视化回放，适合深挖具体问题。先发现异常、再定位根因，两者配合。
先看第一支柱——getStats 的数据模型。👉 getStats 与 RTCStatsReport。
参考资料
- [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 标准）。