可视化与排障 · 把黑匣子画成图 · 音视频与 WebRTC 详解

抓到的 event log 是二进制，得靠 event_log_visualizer 画成一堆时间序列图才看得懂。这一章讲这个官方工具怎么用（--plot/--list_plots）、能画出哪些关键曲线，以及一套「看图定位子系统」的实战排障方法论。

可视化与排障 · 把黑匣子画成图

上一章抓到了 event log，但它是二进制的，肉眼看不懂。要让它有用，得画成时间序列图——WebRTC 官方提供了 event_log_visualizer。这一章讲怎么用它，以及一套“看图定位问题”的排障套路。

event_log_visualizer：日志变图

官方工具的用法很直接（g3doc）：

# 把日志变成一组图(工具输出一段 python,交给 matplotlib 画)
out/Default/event_log_visualizer /path/to/log_file | python

# 只画你关心的图
out/Default/event_log_visualizer \
  --plot=incoming_packet_sizes,incoming_stream_bitrate \
  /path/to/log_file | python

# 列出所有能画的图
out/Default/event_log_visualizer --list_plots /path/to/log_file

event_log_visualizer 把黑匣子日志转成几十种时间序列图**——码率、丢包、RTT、带宽估计、jitter buffer 延迟……用 --plot= 选要哪些、--list_plots 看全部，还能同步各图的 x 轴（一起缩放，方便对齐时间）。** 它输出一段 Python 脚本、由 matplotlib 渲染。关键在于：把“通话期间发生的一切”沿同一条时间轴摊开，于是“第 30 秒卡顿”这种时序问题不再抽象——你能看到那一刻哪条曲线出了异常。

几张最有用的图

--list_plots 列出的图很多，排障时最常盯这几张：

图	看什么	异常意味着
incoming/outgoing stream bitrate	收 / 发码率随时间	码率骤降 → 带宽被砍 / 编码器降质
bandwidth estimate	GoogCC 估的带宽曲线	估计塌陷或上不去 → 拥塞控制问题
network delay / RTT	往返时延	飙升 → 网络拥塞 / bufferbloat
packet loss	丢包率	尖峰 → 丢包触发 NACK/FEC
jitter buffer delay	NetEq/视频 jitter buffer 缓冲深度	变大 → 网络抖动、缓冲被迫拉长
pacer / ALR	pacing 队列、应用受限区	队列堆积 → 发送跟不上

一套看图定位的套路

有了这些曲线，排障就从“猜”变成“顺着数据推”。一个典型的“卡顿”排查：

图表加载中…

排障的核心思路：沿时间轴对齐多条曲线，找“谁先动”。卡顿是果**，要找因——是带宽估计先塌（拥塞控制判断网络变差）导致降码率？还是网络真的抖了、jitter buffer 被迫拉长？还是编码器 CPU 顶不住主动降质？** 这几种根因在图上长相不同：

若 bandwidth estimate 先塌、码率随后跟着降 → 拥塞控制判断网络变差，去查那一刻的 RTT / 丢包是不是真涨了（网络问题）还是 GoogCC 误判（算法问题）。
若 码率没降、但 jitter buffer delay 飙升 → 发端没问题，是网络抖动让收端缓冲拉长，表现为延迟增大。
若 码率降了、但带宽估计没塌 → 不是网络，多半是编码器 / CPU 受限，配合 getStats 的 qualityLimitationReason 印证。

这就是 event log 的威力：它把散落在十几个子系统里的状态拉到同一时间轴，让你像看心电图一样“看波形诊断”。配合本教程前几部分建立的子系统心智模型，你能从一条异常曲线直接跳到“该去读哪块源码”。

两支柱配合的完整闭环

回到第 11 部分开头的两支柱，实战里它们这样配合：线上用 getStats 持续监控 → 发现某通电话质量指标异常 → 对可疑通话抓 RtcEventLog → 可视化看波形定位根因 → 跳到对应子系统源码修。监控发现问题、黑匣子定位问题，这是 WebRTC 工程化排障的标准闭环。

小结与下一章

event_log_visualizer 把二进制 event log 转成几十种时间序列图（--plot= 选图、--list_plots 列全部、可同步 x 轴），经 matplotlib 渲染。最有用的图：收发码率、带宽估计、RTT、丢包、jitter buffer 延迟、pacer/ALR。排障套路是沿时间轴对齐多曲线、找“谁先动”：带宽估计先塌→拥塞控制、jitter 飙升→网络抖动、码率降但估计没塌→编码器/CPU 受限。两支柱闭环：getStats 监控发现 → event log 定位根因 → 跳源码修。

第 11 部分的两大支柱看完了。下一章收尾，并补上其他调试手段。👉 第 11 部分回顾。

参考资料

[1] WebRTC 官方 g3doc/rtc_event_log.md（event_log_visualizer 用法、--plot/--list_plots）。
[2] libwebrtc 源码.rtc_event_log/rtc_event_log_parser.h、tools/event_log_visualizer/。
[3] 关联延迟带宽估计、jitter buffer、getStats。

可视化与排障 · 把黑匣子画成图