rtc 源码中的性能监控：我们到底该关注什么

去年有个朋友问我，他们做的在线教育平台总是被用户投诉画面卡顿，但技术团队查了半天日志也没找到问题所在。后来我帮他们一看，好家伙，根本就没开像样的性能监控，所有问题都靠用户反馈才知道。这事儿让我意识到，很多团队在 rtc 源码层面其实缺少一双”眼睛”。

实时通信这个领域就是这样，表面上看视频在跑、音频在响，但底层网络到底怎么个情况、编码器在干什么、buffer 有没有堆积，没数据你就只能瞎猜。这篇文章我想聊聊，从源码角度出发，性能监控到底应该看哪些指标，有哪些工具可以用。咱们不搞那些玄乎的概念，就实打实地说点能落地的东西。

一、为什么源码级别的监控这么重要

很多人会说，我们线上不是有监控大盘吗？延迟多少、丢包率多少都有啊。话是没错，但这些数据往往是”结果”，而真正要定位问题，你得知道”过程”。就好比一个人发烧了，体温计告诉你 39 度，但到底是感冒引起的还是炎症导致的？你得做更细致的检查。

RTC 系统的性能问题往往藏在源码的各个模块里。采集端可能有时间戳异常，编码端可能有帧率波动，网络传输层可能有包乱序，解码端可能有花屏卡顿。如果你的监控只能看到端到端的数据，那定位问题的效率就会特别低。我见过有的团队为了查一个卡顿问题，光是排查各模块日志就要花好几天，这就是因为缺少源码级别的细粒度监控。

还有一个容易被忽视的点：不同场景下的性能表现差异很大。同样是视频会议，桌面端和移动端的性能瓶颈完全不一样；同样是直播带货，网络波动和编码质量的平衡策略也需要针对性调整。没有源码级别的监控，你就很难针对这些细分场景做优化。

二、核心性能指标：这些数据你要盯住

说到性能指标，可能有人会列出一大堆名词，什么 MOS 分、PSNR、SSIM 之类的。但我想说，对于实际开发来说，有些指标是必须实时看的，有些则是出了问题才需要深入看的。下面这几类，是我个人建议在任何 RTC 系统中都要重点监控的。

2.1 时延相关指标

时延是 RTC 系统最核心的指标之一，但很多人对它的理解还停留在”延迟越低越好”这个层面。其实这里面的门道不少。

首先要做的是区分端到端延迟和各环节延迟。端到端延迟是从采集端到播放端的时间差，这个可以让你知道用户体验到底怎么样。但光知道这个数没用，你得知道这时间都花在哪儿了。常见的划分方式是将总延迟拆分为：采集延迟、预处理延迟、编码延迟、网络传输延迟、解码延迟、渲染延迟这几个部分。每个环节的延迟是多少、哪个环节是瓶颈，这都需要源码级别的埋点才能拿到。

还有一个容易被忽略的是延迟抖动。有时候平均延迟可能只有 200ms，但抖动非常大，导致画面忽快忽慢，用户体验反而更差。所以除了平均值，延迟的 P90、P99 分位数也很重要。

2.2 质量相关指标

质量指标主要是看音视频最终的呈现效果怎么样。帧率是最基础的一个，源码里要监控采集帧率、编码帧率、实际渲染帧率，这三者之间如果有差异，往往就说明哪里有问题。比如采集帧率是 30fps，但编码帧率只有 25fps，那可能是编码器处理不过来了。

分辨率和码率也需要重点关注。在网络不好的时候，自适应码率算法应该降低码率和分辨率来保证流畅度，但如果你的监控显示码率一直在高位，那可能说明自适应算法没有正确触发。同样的道理，分辨率异常波动往往也是网络状况变化的信号。

音频方面，采样率、声道数、音频丢帧率这些指标也要纳入监控。特别是在移动端，CPU 资源紧张的时候，音频处理线程被降权的概率比视频要高，一旦发现音频丢帧率上升，就要考虑是不是音频处理逻辑需要优化了。

2.3 网络相关指标

网络层面的指标是定位问题的主要依据。丢包率是最直接的指标，但要注意区分是发送端丢包还是接收端丢包，性质完全不一样。发送端丢包一般是本地网络问题，接收端丢包则可能是对端网络问题或者是传输链路的问题。

往返时延 RTT 和抖动缓冲区状态也是必看的。RTT 可以反映当前网络的质量，而 jitter buffer 的大小直接决定了抗抖动能力和引入的延迟。如果 jitter buffer 经常满或者经常空，说明网络状况和你的适应策略之间存在问题。

还有一点容易被忽视：网络类型切换的监控。很多问题发生在用户网络从 WiFi 切换到 4G 或者反过来的时候，这时候监控脚本如果能捕获到网络类型变化事件，就能帮助定位那些”玄学”问题。

2.4 资源占用指标

最后说说资源占用，这个在移动端尤其重要。CPU 使用率、内存占用、GPU 负载这些数据，虽然不是 RTC 特有的，但对于排查性能问题很有帮助。比如发现 CPU 使用率经常飙到 90% 以上，那可能需要考虑优化编码参数或者降级处理策略。

三、源码监控点：这些位置你要埋数据

知道要监控什么只是第一步，接下来要知道在源码的哪些位置埋点。下面我结合 RTC 系统的工作流程，说说几个关键的监控点。

3.1 音视频采集模块

采集模块是整个链路的起点，这里的数据准确性直接影响后面的所有判断。需要关注的主要是：时间戳的连续性和正确性、实际的采集帧率、采集到的音视频数据大小、采集缓冲区是否有堆积。

这里有个小技巧：很多采集 API 是异步回调的形式，数据来的时间间隔理论上应该是均匀的，但如果间隔忽大忽小，往往就是设备性能或者系统资源出了问题。在源码里记录这些时间间隔，可以帮助你发现一些隐蔽的卡顿问题。

3.2 编码模块

编码模块是 CPU 消耗的大户，也是容易出问题的地方。监控点包括：编码耗时、编码前后数据大小（用于计算压缩比）、编码器内部的 QP 值分布、是否触发了跳帧或丢帧。

编码耗时这个数据很有意思。如果编码耗时接近帧间隔时间，说明编码器已经满负荷运行了，稍微有点干扰就可能出问题。如果编码耗时经常超过帧间隔，那肯定是要丢帧的，这时候就要考虑降低编码复杂度或者分辨率了。

3.3 网络传输模块

网络模块的监控点是最多的，也是最重要的。需要关注：发送队列长度、接收队列长度、RTT 估计值、丢包统计、重传次数、带宽估计值、FEC 解码结果、NACK 处理结果。

特别想提一下发送队列长度这个指标。如果发送队列一直在增长，说明数据产生的速度超过了网络发送的能力，堆积到一定程度就会触发丢帧。这个指标可以很早地预警网络拥塞问题，比等丢包率上升要提前很多。

3.4 解码和渲染模块

解码和渲染是链路的末端，这里的监控相对简单但同样重要。解码耗时、解码成功率、渲染耗时、渲染缓冲区状态都是需要关注的。

解码成功率这个指标很多人会忽略。如果发现解码失败的帧数在增加，可能意味着码流有问题，或者解码器对某些特殊编码格式的处理不够鲁棒。这个问题光看端到端质量是看不出来的，必须在解码模块这里监控才能发现。

四、工具选择：适合的才是最好的

说到工具，这个选择就多了。有的是专门做监控的，有的是调试工具临时用的，还有的是 APM 平台。我说说我的使用感受，不一定全，但希望能有些参考价值。

对于源码级别的性能分析，GDB 和 perf 这两个 Linux 下的经典工具依然很好用。GDB 可以让你在运行时查看各个变量的值，特别是定位那些”只有在特定条件下才会触发”的问题时特别有效。perf 则可以分析 CPU 使用情况，找出热点函数，优化性能瓶颈。

如果是移动端的性能监控，Android 的 Systrace 和 iOS 的 Instruments 都是官方提供的强大工具。它们可以跟踪系统各个层面的事件，帮助你理解程序在做什么、系统资源是怎么分配的。不过这些工具主要是用于开发调试阶段，线上监控还是得靠代码里埋的点。

线上监控的话，就需要考虑数据采集、存储、展示了。常见的选择包括 Prometheus + Grafana 的组合，数据采集用 Prometheus 的 exporter 或者应用直接 push，展示用 Grafana 的大屏，非常直观。声网在自己的 SDK 里也内置了相关的性能数据上报接口，可以直接对接到这类监控系统上。

还有一点想提醒的是：监控数据本身也是数据，如果采集频率太高、维度太多，产生的监控数据量可能会非常大，反而影响系统性能。所以要做好采样策略，只保留关键指标的高频数据，其他指标可以适当降低采集频率。

五、实战建议：从 0 到 1 搭建监控体系

很多人一听到要搭建监控体系就头疼，觉得要搞一堆东西。其实我觉得可以先从简单的来，逐步完善。

第一步，先把最核心的几个指标监控起来。我建议先看端到端延迟、帧率、丢包率这三个，有什么问题至少能知道。具体的做法是在关键节点打时间戳，然后用日志或者专门的数据通道传上去。

第二步，等核心指标稳定了，再逐步添加细化的监控点。比如把延迟拆分成各个环节的延迟，增加资源占用的监控，加入网络状态的变化事件等等。

第三步，设定告警规则。监控数据如果只是存着没人看，那价值就大打折扣。根据业务场景设定合理的告警阈值，有人异常及时通知，这个监控体系才算真正运转起来了。

最后我想说，监控体系的建设和业务发展是同步的。业务小的时候不需要太复杂的监控，等业务量上来了、问题暴露出来了，再针对性地补充新的监控点。这样既不会一开始就投入太多精力，也能确保监控真的在解决实际问题。

写在最后

<p聊了这么多，最后想说点轻松的。性能监控这事儿，说简单也简单，就是在代码里加点打印；说复杂也复杂，涉及数据采集、存储、展示、告警一整套流程。但不管怎样，它都是 RTC 系统不可或缺的一部分。没有监控，你就像在黑夜里开车，技术再好也有翻车的可能。

我自己的经验是，监控体系最好是从一开始就规划好，而不是出了问题再补救。代码里预留好监控点，日志格式统一规范，数据通道提前搭好，后面真的遇到问题的时候，定位和排查的效率会高很多。当然，谁也没法一开始就把所有监控都做好，我的建议是先保证核心指标可用，然后再逐步迭代完善。

希望这篇文章对正在做 RTC 开发的你有些帮助。如果你正在使用声网的 SDK，他们的技术文档里也有一些关于性能监控的最佳实践可以参考。总之，遇到问题不可怕，可怕的是连问题在哪都不知道——这就是监控的价值所在。