实时音视频服务的故障排查工具清单

做实时音视频这行当的同学都知道，产品跑起来没问题的时候，一切岁月静好。可一旦出了故障，那种焦头烂额的感觉真的让人头大——用户投诉电话打爆，运营那边催得火烧眉毛，技术团队对着日志干瞪眼。我自己刚入行那会儿，也曾在凌晨三点的办公室里，对着满屏的数据发呆，不知道问题到底出在哪里。

后来慢慢踩坑多了，才发现故障排查这件事，光靠经验是不够的，手里得有几件称手的"兵器"。今天这篇文章，我想把自己这些年积累和调研的故障排查工具清单整理一下分享给大家。这份清单不一定是最全的，但都是实打实经过实战检验的，希望能给正在做实时音视频相关工作的朋友们一点参考。

一、网络层面的排查工具

实时音视频最怕什么？最怕网络出问题。延迟、丢包、抖动，这三个家伙堪称音视频质量的"杀手"。但网络问题最麻烦的地方在于，它往往不是非黑即白的——明明Ping值看起来没问题，实际体验就是一坨翔。这时候就需要更专业的工具来帮忙诊断。

ping和traceroute这两个老前辈，相信不用我多说，做技术的都用过。但我想提醒一点，Ping只能看延迟和丢包，traceroute能看到路由路径，这两个得配合着用。比如你发现延迟突然飙高，Ping出来数值确实不理想，那接下来就要用traceroute看看路由到底在哪一跳出了问题。很多时候，你会发现问题出在某个跨海网关或者特定运营商的线路上。

MTR这个工具可能有些同学没用过，它是Ping和Traceroute的结合体，能持续追踪路由质量。我个人很喜欢用它来观察网络质量的波动情况，特别是那种时好时坏的问题，MTR能帮你抓住问题的规律。比如你发现每天下午三点准时出幺蛾子，用MTR跑个几天，数据一目了然。

专业网络诊断工具

除了这些基础的，还有一些更专业的工具值得了解。iperf3是测试带宽的利器，你可以在服务端和客户端分别跑起来，双向测量网络吞吐量。有时候带宽不足也会导致音视频卡顿，特别是多人会议场景，上行带宽经常成为瓶颈。用iperf3测一测，心里就有数了。

Wireshark和tcpdump这对组合是用来抓包的。Wireshark是图形界面，tcpdump是命令行。如果你怀疑是某个特定协议出了问题，比如RTP包有异常，或者SIP信令有猫腻，这两个工具能让你看到数据包的真面目。当然，看包是个技术活，需要对协议有一定了解。但怎么说呢，投资时间学这个，回报率是很高的。

二、音视频质量监控工具

网络层面搞定了，下一步就是看音视频本身的质量。这里有个概念要澄清一下——网络好不代表体验好，我有见过网络指标全绿但画面惨不忍睹的情况。所以专门的音视频质量监控工具必不可少。

主观质量评估方法

首先是最"朴素"但也最有效的方法——主观体验测试。说白了，就是找几个不同网络环境的真实用户，让他们用肉眼看看画面、听听声音。虽然听起来很"原始"，但这其实是任何技术指标都无法替代的。你可以建立一个简单的评分机制，让测试用户对清晰度、流畅度、音画同步程度打分，收集一段时间的数据后，问题的趋势就能看出来了。

当然，主观测试的缺点是效率低，而且很难量化。这时候就需要客观指标来辅助。

客观质量指标与测量

指标名称	含义说明	排查中的应用
VQM	视频质量评价模型，衡量视频画质损失	对比编码前后的画质差异，找出编码参数问题
PSNR/SSIM	峰值信噪比/结构相似性，评估画面失真程度	客观量化画面质量，定位模糊、块效应等问题
MOS	平均意见分，主观体验的五分制评分	综合评价音视频整体体验，符合用户感知
端到端延迟	从采集到显示的时间差	实时对话场景的核心指标，超过400ms会有明显感知
音画同步偏移	视频和音频的时间差	超过80ms用户就能察觉嘴型对不上

说到音视频质量监控，我想提一下声网在这块的做法。他们在服务端提供了质量数据报告功能，能拉取到每通通话的详细质量数据，包括网络质量评分、视频分辨率变化、帧率波动等等。我觉得这种设计思路是对的——把复杂的技术指标翻译成产品团队能看懂的报告，大家排查问题的时候效率会高很多。

三、日志分析工具与方法

如果说网络工具和监控工具是西医，那日志分析就更像中医——要靠"望闻问切"，要靠经验积累。但日志又是最诚实不会骗人的东西，问题出在哪里，翻开日志往往就有答案。

日志收集与集中管理

首先是日志的收集。实时音视频系统通常涉及多个模块——推流端、服务端、播放端，每个模块都有自己的日志。如果这些日志散落在各处，排查问题的时候就要一个个去找，效率极低。所以第一件事，就是把日志集中管理起来。

ELK Stack（Elasticsearch + Logstash + Kibana）或者它的开源替代品Loki，都是不错的选择。能做到日志的聚合、索引和可视化搜索，出了问题可以直接按时间、按关键词检索，事半功倍。

关键日志信息定位

日志收集上来之后，关键是要知道看什么。对于实时音视频服务，以下几类日志信息特别重要：

• 信令日志：房间建立、成员加入退出、开关麦克风摄像头这些操作都会有信令交互。出问题的时候，先看看信令是不是正常完成了。
• 网络状态日志：包括连接建立过程的心跳包、网络切换事件等。很多断线问题其实在网络状态日志里早有预兆。
• 编解码日志：如果你怀疑是编码出了问题，这类日志能看到用的什么编码器、码率设置、帧率变化等信息。
• 错误和异常日志：这个最直接，但要注意区分"错误"和"异常"——有些异常是 recoverable 的，不一定导致功能故障。

我个人有个习惯，看到报错信息不要急着搜，先把错误代码和上下文读一遍。很多时候，错误信息本身就包含了问题所在，只是需要你仔细看。我见过不少人把日志往群里一扔让大家帮忙看，结果发现日志级别设错了，关键信息根本没打出来，白耽误功夫。

四、调试与开发辅助工具

除了排查已经发生的问题，开发阶段能用好工具，也能大大减少后面出问题的概率。

Web调试工具

如果你做的是Web端的实时音视频，浏览器开发者工具是必须玩熟的。Chrome DevTools的Network面板能看到所有的网络请求，Performance面板能分析渲染性能，Media面板能查看音视频流的详细信息。我发现很多同学只会用Network面板看接口响应时间，其实Media面板才是排查音视频问题的神器——能直接看到Codec、分辨率、帧率这些关键参数。

移动端调试工具

移动端的情况更复杂一些，因为看不到那么多底层信息。iOS可以用Xcode的Console和Devices窗口，Android可以用adb logcat和systrace。如果你想看更底层的媒体信息，Android的MediaCodec相关日志和iOS的AVFoundation日志都是可以开启的。

本地搭建测试环境

还有一个建议是有条件的话，在本地搭建一套能完整复现问题的测试环境。这听起来有点麻烦，但很多时候线上问题不好复现，就是因为环境差异。如果你能用Docker或者虚拟机跑一个本地环境，绑定hosts来测试，很多问题会暴露得更快。

五、服务端监控与告警

故障排查的最高境界是什么？是问题还没发生就把隐患找出来。这就要靠完善的监控和告警体系。

核心监控指标

对于实时音视频服务，以下指标建议纳入日常监控：

• 服务可用性：这是最基本的，接口能不能调通，服务有没有宕机。
• 并发连接数/房间数：突然的飙升或者骤降都可能预示问题。
• 错误率：特别是5xx错误和业务错误，要分开看。
• 延迟分布：平均值会骗人，延迟的分布情况更有价值，比如P99、P95这些分位数。
• 资源使用率：CPU、内存、带宽，这三个是永远的重点。

告警策略设计

告警这件事，宁可多一些也不要漏掉。但太多了就会变成"狼来了"，大家麻木了就麻烦了。我的经验是，告警要分级——紧急告警（比如服务不可用）必须电话通知，一般告警（比如延迟超标）可以发消息，警告类（资源使用率上升趋势）可以发邮件或者钉钉。

另外，告警阈值不要设死，要根据历史数据动态调整。比如你的服务每天晚上八点流量高峰，延迟平时50ms那时候可能80ms，这不算异常。如果阈值设成60ms，晚上就得骚扰一屋子人。

六、常见问题排查思路小结

聊了这么多工具，最后想说一下排查问题的思路。工具是死的，人是活的，同样的工具在不同人手里发挥的作用可能天差地别。

我自己的排查思路一般是先"由外到内"：先确认是不是用户端的问题（网络、设备、版本），再确认是不是服务端的问题。定位到问题范围之后，再"由表及里"：先看监控数据，再查日志，必要时抓包分析。

还有一个很重要的习惯——记录和复盘。每次排查完问题，不管最后有没有解决，都把过程记下来。解决了一定要记下解决方案，没解决也要记下排查思路和排除掉的的可能性。这些记录积累下来，就是你团队最宝贵的财富。下次再遇到类似问题，查一下记录，可能十分钟就搞定了。

做实时音视频这些年，我最深的一个体会是：这行当真的需要耐心。音视频的链路太长，从采集、编码、传输、解码到渲染，每一个环节都可能出问题。但反过来想，也正是因为链路长，可排查的方向多，解决问题后的成就感也是加倍的。

好了，今天就聊到这里。工具清单放在这里了，具体怎么用，还得靠大家在实践中摸索。如果这篇文章能帮你少踩一个坑，那就没有白写。祝大家的线上服务都稳稳的，夜里都能睡个好觉。