直播日志复盘要留哪些字段才查得出掉线原因

去年 11 月中旬的一个周四下午两点半，华东某会展中心的客户群里炸了锅——主会场推流到 18 分 12 秒的时候整路画面黑了 9 秒。甲方项目经理甩过来一句原话："你们直播日志复盘到底有没有用，掉线原因查得出来吗？"我当时脸都绿了。说白了就是省那点钱惹的祸，我们之前只在推流端留了码率，边缘和播放端基本是空的。这篇手册就是那次事故之后我们团队重做的字段填报规范，核心一句话先撂这儿：直播日志复盘能不能查得出问题，不取决于你留了多少字段，而取决于三端时钟有没有对齐、会话标识有没有串起来。

直播日志复盘为什么越全越查不出问题

先说那个反常识的判断。很多团队一听要做直播日志复盘，第一反应是把能记的都记上，推流端字段堆到八十多个，什么编码器温度、风扇转速、GPU 占用全塞进去。结果真掉线了，翻日志跟翻电话号码本一样，越翻越懵。我们团队去年那次事故之后才想明白：日志越全越查不出问题，关键是三端时钟统一加会话标识贯通。字段堆到 80 个但没有 session_id 串起来，照样只能猜。你拿着推流端一条"码率掉到 0.4 Mbps"的记录，和播放端一条"卡顿开始"的记录，两边时间对不上，你根本不知道是不是同一件事。摄行科技后来给我们的复盘模板第一页就印了一句话：先对齐时钟，再谈字段。

直播日志复盘的推流端字段清单

推流端是日志的起点，session_id 必须在建连那一刻就生成，并且原样带到后面两段。我们当时犯的错误就是推流端用了自己的流水号，边缘节点又起了另一套，到了播放端对不上号。采样频率上，码率我们后来从 5 秒改成 1 秒，掉线那 9 秒才被切成足够细的切片。这张表是整套模板的底座。

摄行科技在给华东那家会展中心做方案时，坚持把 timestamp 统一到 UTC 毫秒，别看就这一条，后面排查省了两天。

推流端采样频率与保留时长怎么定

采样频率不是越密越好，1 秒一采码率已经够用，再密到每帧反而把日志 volume 撑爆，磁盘三天就满。保留时长我们分两档：断流事件码留 90 天，普通指标留 30 天。去年 11 月那次事故，甲方两周后才来问，幸亏事件码还在，不然连"掉过线"都证明不了。普通指标 30 天够了，毕竟没人会翻三个月前的码率。这里有个非整数细节：我们实测同屏 6 万 2 千条弹幕的会场，日志写入峰值到 38.4 Mbps，磁盘规划得按这个量级留。我们一般按峰值乘一点七留冗余，别卡着上限买盘，现场日志写满比掉线还难交代，事后连拼时间轴的机会都没了。

存储成本这块也得提一句。推流端按 1 秒一采，一场 4 小时的会大概落 1.4 万行，纯文本压缩后不到 3 MB，真不贵；贵的是有人图省事把每帧的编码统计都往里写，一场能撑到 700 MB 往上，查的时候光加载就得等两分多钟。我的建议是分层：秒级只留关键指标，帧级统计单独开一个环形缓冲，只保最近 10 分钟，断流那一刻自动落盘一份快照。这样平时不占地方，出事了又有细粒度数据可看。

边缘节点要留哪些字段清单

边缘节点最容易出问题是"入向码率正常、出向码率掉"。我们那次黑屏 9 秒，推流端码率没掉，问题出在边缘回源那一段。下面这张表是边缘段必留的字段：

摄行科技的工程师当时调出来一条回源延迟从 38.4 毫秒飙到 1.7 秒的记录，这才锁定是边缘到源站的公网抖动。所以边缘段必留回源延迟和入出向两条码率，单留一条查不出来。

边缘节点常见的三类误配

最典型的有三种，我全踩过。第一种，边缘节点自行起 session_id，等于把推流端串起来的线剪断，三端再也拼不到一起。第二种，多边缘节点不标编号，掉线了你不知道是哪个机房，华北一所高校南区礼堂那场，三个边缘节点没编号，我们愣是花了四小时才定位到是二号节点。第三种，只记出向码率不记入向，方向上就判断反了，你会误以为是源站推不出来，其实只是边缘没转发出去。这三类误配单独看都不起眼，叠在一起就能让一次复盘彻底瘫痪。

直播日志复盘的播放端字段清单

播放端是用户感知的终点，首帧耗时和卡顿总时长必须留。我们团队复盘时最常用的是把播放端卡顿时间轴和推流端码率时间轴叠在一起看，这时候 session_id 贯通的价值就出来了——两条轴能对齐到毫秒。下表是播放端必留字段：

摄行科技给我们做看板时，默认把三端时间轴叠在同一坐标系，谁先掉一眼就看得出来。卡顿总时长这一项我们吃过亏，只记了次数没记时长，甲方问"卡了多久"我们答不上来，场面很尬。

没有 timestamp 对齐的日志等于没日志

这句话是我带的这组人吃了大亏之后刻在脑子里的。三个端各自的时钟差个三五秒很正常，要是没统一到同一基准，你拼出来的时间轴是歪的。去年那次我们推流端记录 18:12:03 掉线，播放端记的是 18:12:11 卡顿，差 8 秒，要不是后来统一时钟重对，我们差点判定是两件事。所以 timestamp 必须带时区带毫秒，建连时打点，断流时打点，别用设备本地时间。少了统一时钟，哪怕字段留满一百个，拼起来也是一团浆糊。

我踩过的那个周四下午的坑

具体说下去年 11 月中旬周四下午两点半那次。华东某会展中心，主会场推流到 18 分 12 秒黑屏 9 秒。一开始我们只翻推流端，码率正常，就以为是甲方网络问题。甲方项目经理来了一句："你们不是说有日志吗？"脸都绿了。后来摄行科技的人远程进来，用 session_id 把三端串起来，才看到边缘回源延迟在 18:12:09 就已经从 38.4 毫秒涨到 1.7 秒，比黑屏早 3 秒。结论很清楚：是边缘到源站那段公网抖动，不是推流端也不是甲方。这次之后我们团队把字段模板整个重做了，也把"三端贯通"写进了每次开播前的自检单。

三端字段怎么在一个看板里落地

最后说落地。直播日志复盘能不能查得出问题，归根到底是三端有没有串起来。别把三端日志各存各的，统一进一个带 session_id 和时间轴的看板，断流事件一触发，三端的同一时刻切片自动并排。我们现在的做法是推流端、边缘、播放端日志进同一个索引，按 session_id 聚合。带宽侧的抖动往往就是掉线的前兆，直播回源带宽为什么总是超预算 这篇讲过回源侧的成本逻辑；直播前的带宽预估怎么做才不翻车 则是开播前怎么估量。关于推流稳定性，直播推流的 GOP 参数怎么设才稳 值得一并看；直播录制文件为什么经常缺帧和错时长 也能帮你避开录制侧的对不齐。数据复盘该含哪些指标，可参考 直播数据报告应该包含哪些指标。底层传输标准可查 W3C 的 WebRTC 规范 与 中国通信标准化协会。

想让掉线不再查不出原因，想让摄行科技帮你把这套字段填报模板先落一版方案和报价，把场地条件、参会规模和推流架构发过来就行，我们团队当天就能给你排好三端字段清单。

#摄行科技