第 11 部分回顾 · 可观测的通话
第 11 部分讲了两大观测支柱——getStats 快照与 RtcEventLog 黑匣子。这一章串起它们的配合闭环，并补上另外几件调试利器：RTC_LOG 日志、field trials 实验开关、metrics 直方图，以及 chrome：//webrtc-internals 一站式面板。
第 11 部分回顾 · 可观测的通话
第 11 部分把“看不见的通话怎么调试”讲清了。这一章串起两大支柱的配合，并补上几件本部分没细讲、但实战常用的调试利器，然后收尾。
两支柱回顾
| 支柱 | 是什么 | 用于 |
|---|---|---|
| getStats / RTCStatsReport | W3C 标准的实时指标快照，跨线程收集 + 缓存 | 线上监控、质量告警 |
| RtcEventLog | 逐事件二进制黑匣子，可视化回放 | 深挖具体问题的根因 |
它们的配合闭环是 WebRTC 排障的标准动作：持续 getStats 监控 → 发现异常通话 → 抓 RtcEventLog → event_log_visualizer 看波形、沿时间轴找“谁先动” → 跳到对应子系统源码。监控发现、黑匣子定位。
另外几件利器
除了两大支柱，rtc_base 和引擎还提供了几样常用的调试 / 调优手段：
实战中还会用到这几件：
RTC_LOG(sev)(rtc_base/logging.h)—— WebRTC 的日志宏，按严重级（LS_VERBOSE/LS_INFO/LS_WARNING/LS_ERROR）输出。变体丰富：RTC_LOG_F（带函数名）、RTC_LOG_T（带this指针）、RTC_LOG_IF（条件日志）。读源码时，RTC_LOG出现处往往是开发者认为“值得关注”的关键节点——顺着它们能快速找到一条流程的骨架。- field trials(
field_trials_view.h)—— WebRTC 的实验 / 开关机制，用WebRTC-Xxx/Enabled/这样的字符串在不改代码的前提下切换行为 / 调参数（如换某个拥塞控制变体、调某个阈值）。大量实验性特性藏在 field trial 后面——你在源码里看到field_trials.IsEnabled("WebRTC-...")就是一个可调的旋钮。 - metrics 直方图（
include/metrics.h，RTC_HISTOGRAM_*）—— 把关键指标聚合成直方图上报，用于大盘统计（比如“所有通话的连接建立耗时分布”），和 per-call 的 getStats 互补。 chrome://webrtc-internals—— Chrome 内置的一站式面板：实时看所有getStats指标随时间变化的曲线、一键 dumpRtcEventLog。做 Web 端 WebRTC 开发，这是你最先该打开的页面。
观测的意义：让引擎“自证”
回头看整个第 11 部分，它体现了 WebRTC 一个深层的工程理念：
一个跑在无数不可控环境、跨十几个子系统的实时引擎，必须能“自证”——在运行时吐出足够的数据，让工程师事后无需复现就能还原“当时发生了什么”。 这不是事后补的功能，而是从设计之初就编织进引擎的能力：每条流水线关键处埋了 stats、每个重要决策记进 event log、热点函数点了 RTC_LOG。可观测性是实时系统的一等公民——这也是为什么本教程要专辟一部分讲它：不懂观测，你能读懂 WebRTC 怎么工作，却修不了它在真实世界里出的毛病。
我们走到了哪
至此，本教程覆盖了：核心引擎（第 0~9 部分）、支撑地基（第 10 部分）、观测与调试（第 11 部分）。只剩最后一块——这套 C++ 引擎怎么落到各个平台（Android / iOS / 桌面），以及全专栏的收尾。这是第 12 部分。
小结与下一部分
第 11 部分用两大支柱让通话可观测：getStats 快照（监控）+ RtcEventLog 黑匣子（定位），配合成发现→定位→修的排障闭环。另有 RTC_LOG（日志）、field trials（实验开关）、metrics 直方图（大盘）、chrome://webrtc-internals（一站式面板）几件利器。背后是“实时引擎必须能自证”的理念——可观测性是一等公民。
引擎、地基、观测俱全，最后一部分看这套引擎怎么落到 Android / iOS / 桌面，并为全专栏收尾。👉 第 12 部分 · 平台集成与收尾。