#
rtc 源码的调试日志过滤技巧
写代码这些年，我越来越觉得日志是个很神奇的东西——它既是程序运行的痕迹，也是debug时的救命稻草。尤其在rtc这种实时音视频领域，日志量一大起来，简直能让人眼花缭乱。今天就来聊聊，我是怎么从密密麻麻的日志里，把真正有用的信息给"捞"出来的。
一、先搞清楚：RTC日志到底长啥样
在动手过滤之前，咱们得先弄清楚，RTC源码跑起来都会产生哪些日志。這不是废话，是因为不同模块的日志长得完全不一样，过滤策略自然也得分开看。
RTC系统的日志大概能分成这么几类，每一类的"脾气"都不太一样。
信令层面的日志主要管的是建连、房间管理、用户上下线这些事儿。这类日志通常会有明显的关键词，比如"join"、"leave"、"publish"、"subscribe"。它们的价值在于告诉你"发生了什么"，但缺点是量大，特别是在高并发的场景下，可能每秒就有几十条。
媒体层面的日志才是真正的重头戏。包括RTP/RTCP包的收发、码率自适应、抖动缓冲状态、帧率分辨率调整等等。这类日志往往伴随着大量的数字信息，比如序列号、时间戳、比特率等等，看起来很枯燥，但出问题的时候，它能告诉你"为什么画质突然变差了"或者"为什么会卡顿"。
引擎内部的日志通常比较深奥，涉及音频3A算法（回声消除、噪声抑制、自动增益）、视频编码参数、内部状态机切换之类的内容。这类日志一般只有特定场景下才会去看，但一看往往就是定位疑难杂症的时候。
网络状态的日志是我个人最关注的类型。包括连接质量评估、丢包率、往返时延、网络类型切换等等。RTC本质上就是个"看天吃饭"的技术，网络一烂，什么问题都可能出来。这部分的日志往往分散在不同的模块里，需要结合起来看才行。
说这么多，其实就想表达一个意思：过滤RTC日志，核心思路不是"怎么看得更少"，而是"怎么看到该看的东西"。接下来的技巧，都是围绕这个目标来的。
二、日志级别这件小事
先从最基础的说起，因为我觉得很多人可能并没有真正用好日志级别这件事。
2.1 级别到底怎么分
ERROR级别的日志，翻译成人话就是"出大事了"。比如关键对象初始化失败、网络连接彻底断开、音视频数据通道不可用之类的。这类日志出现的频率应该很低，但每一条都得认真看。在声网的实际开发中，ERROR日志通常会关联到业务层面的告警系统，一旦出现就得第一时间处理。
WARN级别表示"有点不对劲，但还能凑合活着"。比如重试机制启动了、某个非关键配置使用了默认值、网络质量开始波动但还没崩。WARN级别的意义在于它是ERROR的前兆，如果你的WARN日志突然变多，那大概率是要出事的节奏。
INFO级别是最常用的，它记录的是正常的业务流程节点。比如成功加入了房间、开始推流了、码率调整到多少了等等。INFO日志在开发环境可以尽情打开，但在生产环境就得掂量掂量了——量大起来，几GB的日志文件几天就能给你造出来。
DEBUG和
VERBOSE级别，这两个是给开发者自己看的，里面会包含大量的细节信息。比如某帧数据的具体内容、某个函数被调用的详细参数、内部状态机的每一步变化。只有在定位特定问题的时候，我才会临时打开这两个级别，问题一定位完，立刻关掉。
2.2 实战中的级别过滤技巧
讲道理，这些级别划分谁都懂，但真正用起来的时候，很多人还是会犯错。我自己踩过不少坑，说几个让我印象深刻的。
第一个教训是关于"动态调整"的。声网SDK支持在运行时动态修改日志级别，这个功能一定要善用。比如用户投诉卡顿的时候，你可以先让用户把日志级别从INFO改成DEBUG，跑个一两分钟再改回来。这样既能抓到足够的信息，又不会让日志膨胀得太夸张。
第二个经验是"分层过滤"。什么意思呢？RTC系统往往是多模块协作的，你可以对不同模块设置不同的日志级别。比如网络模块我只想看WARN及以上，但音频模块我想看INFO，那完全可以分开设置。很多开发框架都支持这种细粒度的控制，别浪费了。
第三个建议是"生产环境默认INFO就够了"。我见过有些团队在生产环境默认开DEBUG级别，结果用户手机存储空间被日志塞满，差评蜂拥而至。真的，除非你在排查一个持续存在且严重影响体验的问题，否则别在生产环境开DEBUG。
三、关键词过滤：最直接的招数
日志级别搞定之后，下一步就是用关键词来精准定位了。这一块可以说是过滤技巧的核心，我会分几个场景来细说。
3.1 基础关键词匹配
最简单粗暴的方法就是grep加上关键词。比如你想看所有跟网络相关的日志，可以这样：
这个组合拳打出去，基本能把网络模块的关键信息给薅出来。但这里有个问题：RTC日志里的信息往往是分散的，可能"丢包"这件事的相关日志分散在三四个不同的地方，光搜一个关键词可能看得云里雾里。
我的做法是建立一个"问题-关键词"的映射表。比如"卡顿"这个问题，我会同时搜索"jitter"、"buffer"、"fps"、"bitrate"这几个词，然后把搜到的结果放在一起看。有时候还要加上时间范围作为限定条件，这样才能把相关的上下文给串联起来。
3.2 进阶技巧：用正则表达式
普通的字符串匹配有时候不够用，这时候就得请出正则表达式了。
比如你想找出所有RTP序列号跳跃的情况，可以搜这样的模式：`Sequence number.*?jump.*?\d+.*?\d+`。这个正则能匹配类似"Sequence number jump from 1000 to 1050"这样的日志，既抓到了序列号变化，又看到了跳了多远。
再比如你想找所有码率在2Mbps以上的记录：`bitrate.*?(\d{4,})`这个模式能帮你快速筛选出高码率的时刻。注意正则里的\d{4,}是四位数以上，你可以根据实际情况调整。
还有一个我常用的技巧是用负向匹配来排除干扰信息。比如搜所有音频相关的日志，但排除掉DEBUG级别的：`audio.*?(?!.*DEBUG)`。这样能省去很多细碎的低级别日志，让关键信息更突出。
3.3 多条件组合查询
复杂问题往往需要多个条件同时满足，这时候就需要一点编程思维了。
举个具体的例子。假设用户反馈"视频有时候会突然变模糊"，这可能是分辨率切换导致的。你可以分几步来过滤：首先找到所有分辨率变化的日志，然后从中筛选出"降级"的情况，再看看降级前后网络的波动。伪代码大概是这个逻辑：
```
for each log_line in all_logs:
if "setVideoResolution" in log_line and "->" in log_line:
extract_resolution_before and resolution_after
if resolution_after < resolution>" | head -50`。这一步一步筛下来，最后留下的就是高度相关的信息了。
四、时间戳：串联信息的隐形线索
说到时间戳，这东西在RTC日志过滤里真的是个宝贝，但很多人可能没意识到它的价值。
RTC是实时系统，问题往往是"一系列事件"的结果，而不是"一个孤立的事件"。比如卡顿之前，可能先有网络波动的迹象，然后是缓冲区开始堆积，再然后才是帧率下降。如果只看某一时刻的日志，你只能看到结果；但如果用时间戳把前后的事件串起来，你就能看到因果关系。
我的习惯做法是：先定位到"异常事件"发生的时间点（通常在ERROR或WARN日志里会带有时间戳），然后向前后各扩展一段时间范围，把相关的日志都捞出来。比如异常发生在14:32:17，我可能会看14:32:00到14:32:30这半分钟内的所有日志。
这里有个小技巧：很多RTC日志的时间戳精度很高，精确到毫秒甚至微秒。如果你的grep工具支持Perl兼容的正则表达式，可以用`\d{2}:\d{2}:\d{2}\.\d{3}`这样的模式来精确匹配时间范围。对于性能分析来说，这种精度是必须的。
还有一点值得注意的是时区问题。如果你的服务分布在多个机房，日志时区不统一的话，比对时间会很痛苦。建议在收集日志的时候统一转换成UTC时间，或者至少标注清楚时区。
五、模块化过滤：化整为零的思路
前面提到过，RTC系统有很多模块。当日志量大的时候，我倾向于先把日志按模块拆开，再分别处理。
怎么拆分呢？大多数RTC日志都会有模块前缀或者特定格式的tag。比如音频模块可能统一用"[Audio]"开头，网络模块用"[Network]"。你可以先用正则把这些模块的日志分别提取出来：
```
grep -E '^\[Audio\]' logs.txt > audio_logs.txt
grep -E '^\[Network\]' logs.txt > network_logs.txt
grep -E '^\[Video\]' logs.txt > video_logs.txt
```
这样做的好处是什么？举个例子，如果你怀疑是音频问题，那直接把audio_logs.txt拖进编辑器分析就行，不用被视频和网络的一大堆日志干扰视线。而且这些拆出来的文件还可以用更细的关键词继续过滤，层层递进。
对于复杂问题，我会建一个Excel表格，把不同模块的关键指标列在一起对比。比如这样：
| 时间点 |
音频采样率 |
视频帧率 |
网络抖动 |
缓冲区水位 |
| 14:32:15.123 |
48000Hz |
30fps |
12ms |
65% |
| 14:32:16.456 |
48000Hz |
15fps |
45ms |
82% |
| 14:32:17.789 |
48000Hz |
-- |
120ms |
95% |
这种表格一做，问题脉络就清晰多了。14:32:16的时候帧率开始掉，同时抖动增加；到了14:32:17，帧率直接归零，缓冲区满了。明显是网络抖动导致的连锁反应。
六、特殊情况：生产环境的日志收集策略
开发环境好说，问题复现了直接把日志级别调高就行。但生产环境不一样，你没法让所有用户都开高日志级别，那日志量根本扛不住。
所以生产环境通常采用的是"按需收集"策略。声网在这方面有一些实践经验，可以参考。
首先是分级日志策略。日常只收集ERROR和少量WARN日志，这些日志量可控，而且能覆盖大部分严重问题。当用户反馈特定问题的时候，可以通过远程配置让该用户的SDK临时提升日志级别，收集一段时间之后再自动降级。
其次是结构化日志。日志不仅仅是文本，最好能带上结构化的上下文信息。比如一条网络状态日志，除了文字描述，还能包含当前网络类型、信号强度、延迟估计值等等结构化字段。这些字段可以用JSON格式嵌入日志里，后续用jq或者类似工具解析非常方便。
还有一个思路是预置问题场景。比如预先定义好"弱网"、"高丢包"、"频繁切换网络"等场景的关键词指纹，当这些场景出现的时候，SDK自动触发详细的日志收集。这样既能保证关键时刻不丢信息，又不用一直开着高日志级别。
七、工具选择：适合自己的就是最好的
最后聊聊工具这件事。我试过不少日志分析工具，最后发现没有完美的方案，关键是找到适合自己工作流的。
命令行派如我，grep、awk、sed这三个老搭档基本能满足90%的需求。它们的优势是轻量、可脚本化、处理大文件快。缺点是学习曲线陡，复杂分析写脚本比较费劲。
如果你的问题需要可视化展示，那可以考虑ELK Stack或者类似方案。日志聚合到Elasticsearch里，用Kibana做查询和可视化，能很方便地看到时间分布、关键词频率之类的统计信息。不过这套架构搭起来有点重，小团队可能不太值得。
还有一个我最近在用的是IDE自带的日志分析功能。比如Visual Studio Code装个日志语法高亮的插件，配合搜索功能，对付中等规模的日志文件体验挺好的。特别是当你需要同时看日志和源码对照的时候，IDE的优势就体现出来了。
工具这东西，真的没必要追求"最强大"，能让你高效定位问题的就是好工具。我自己就是IDE和命令行混着用，哪个顺手用哪个。
八、写到最后
不知不觉写了这么多，回头看看，好像把日志过滤这件小事给拆解得有点碎了。不过这就是我的做事风格——把大问题拆成小问题，一个一个解决掉。
日志过滤这件事，说到底就是"在信息海洋里找到针"的过程。RTC系统的日志量大、模块多、关联复杂，确实给调试带来了不少挑战。但只要掌握了正确的方法，其实也没那么可怕。
我的经验其实可以总结成三句话：第一，知道自己要找什么，比知道日志里有什么更重要；第二，时间戳是串联信息的钥匙；第三，工具是辅助，思路才是核心。
希望这些经验对正在搞RTC开发的朋友们有点帮助。技术这条路本来就是不断踩坑、不断总结的过程，谁也不是一开始就会的。慢慢来，别着急。
