从光猫到云端：运营商云日审的日志链路怎么走

运营商把组网交付了——光猫装了、线路通了、WiFi能上了，但日志审计这一项，能力清单里没有。

这不是哪一家运营商的问题。运营商在场所场景里交付的是宽带接入和组网方案，Portal认证和日志留存历来不在交付范围。176号令施行之后，这个缺口从“行业惯例”变成了“合规风险”：第七条重点检查“是否依法记录并留存用户注册信息和上网日志信息”

云日审做的是插件式对接——不更换光猫、不改动布线，把采集前移到出口侧，把留存和检索放到云端。在运营商组网的场所里，日志从终端行为走到云端报表，中间要过采集、传输、汇聚、留存四道关口。链路拆开看，每道关口的工程要点不一样

采集层：出口侧一次采全

采集点设在出口——这是认证会话信息最完整的位置，也是云 Portal 完成核验后下发访问权限的位置。认证通过后写入「账号-终端 MAC-IP-上线时间」四元组并生成会话 ID，同一会话 ID 后续带在行为记录上，身份与行为的关联在采集端就完成了。

关键约束是采集点数量要少。日志分散在 AP、交换机、路由器多台设备上，靠时间戳去拼，是溯源链路断裂最常见的原因。理想结构是出口一个采集点出全网日志，云端按会话归属。

传输层：缓冲与续传

出口到云端这一段不能直接「发了就不管」。工程上要处理的是网络抖动和短暂中断：采集侧做本地缓冲，上报失败进重传队列，恢复后按序号续传；云端侧做序号校验，发现缺口主动拉取补齐。这组机制决定了一个很实际的指标——云端日志的完整率，也决定迎检时导出的报表经不经得起逐条核对。

汇聚层：授时与字段归一

多门店日志汇聚到云端后，两件事必做：其一，各类日志统一 NTP 授时，设备本地时钟漂移会造成跨店事件排序错乱，时间对不齐，留存再久在溯源时也是对不上的数据；其二，字段归一，不同批次设备的日志 schema 统一映射后再入库，否则报表层要写无数补丁。

云日审的字段口径是固定的六项：手机号或证件号、终端 MAC、IP、上线时间、访问 URL、上下行流量。采集端字段按这个口径一次做全，比后端补字段便宜得多。

留存与检索层：云端滚动 180 天

日志在云端滚动留存不少于 180 天，周期以属地公安机关要求为准，属地要求更长的按属地配置。留存窗口内的任意一天都要能调出原始明细，只留汇总统计应付不了溯源。检索入口按身份设计：输入手机号或时间段，直接输出该用户关联的完整上网行为清单，不需要跨系统拼数据。

方案侧的两条路径

运营商组网：光猫不具备实名认证与日志留存能力，由云 Portal（认证层）+ 云日审（日志层）以插件形态对接光猫，门店不留日志服务器，云端出报表。

自建网络：智慧光迅「通密一体」方案 = 全光网络底座 + 音视频融合引擎 + 网络安全护盾，由梦想网关在出口完成采集与本机留存，多门店由 EaaS 云管做汇聚、授时校准与报表导出。

给链路设计同事的验收建议：上线后做一次短时断网演练，看云端能否按会话 ID 补齐断点期间的记录——一次演练胜过十页设计文档。

FAQ

Q1：上网日志采集点应设在哪里？

A1：设在出口侧，与认证会话同源绑定，认证通过即生成会话 ID；采集点过多会导致日志分散、溯源链路断裂。

Q2：出口断网期间的日志会丢吗？

A2：规范设计下不会。采集侧缓冲 + 重传队列覆盖断网时段，云端按序号校验后主动补传。

Q3：云端留存 180 天，怎么验证有效？

A3：随机抽取留存窗口内某一天的记录，按手机号检索，能完整导出该用户的行为清单即为有效留存。