酒店WiFi认证Portal认证绕不开一个话题：日志。上网实名认证做完了，日志留不住、查不了，等于白做。对酒店来说，日志不只是给监管看的，也是自己排查问题、界定责任的重要依据。但日志这件事，从留存到查询，里头的门道不少，做不好就变成"存了一堆数据，真要用的时候抓瞎"。
先明确日志要留哪些东西。酒店场景下，跟认证相关的日志至少要能覆盖这么几类：认证日志，记录谁在什么时间通过什么方式完成了认证；上网行为日志，记录终端访问网络的时间、地址这些信息；还有终端和地址的对应关系，也就是哪台设备用了哪个地址。这些信息合在一起，才能支撑"什么人、什么时间、做了什么"的追溯。日志字段怎么定义、覆盖到什么程度，跟系统能力和部署方式有关，方案阶段就要跟实施方对齐清楚。
留多久是个硬问题。酒店上网日志的留存时长，要符合当地监管要求。不同地区、不同监管口径下，要求可能不一样，常见的要求是留存不低于一定时长。酒店在做方案的时候，要跟当地监管口径确认清楚，别凭印象拍脑袋。日志的存储还要考虑容量，留存时间长、数据量大，存储方案就要跟着规划，本地存储还是云端存储、怎么备份、怎么防丢失，都要提前想。
日志要能查，这是比留存更实际的要求。酒店日常用得最多的场景，是客人投诉或者监管检查时，需要查某个时间、某个房间、某个手机号的上网记录。认证系统的日志查询，至少要支持按时间、按认证账号或手机号、按终端信息这些维度检索，查出来的结果要能看明白、能导出。有的酒店还会需要把日志定期导出备份，或者按监管要求做上报对接。这些功能有没有、好不好用，直接影响酒店日常运营的效率。
还要说清楚日志能力和审计系统能力的边界。认证系统自带的日志，通常能覆盖认证事件和基础的上网记录，这是一套能力；独立的日志审计系统，能做更完整的行为审计、分析、上报，那是另一套能力。酒店WiFi认证Portal认证方案里，要说清楚当前方案提供的是哪一层，别把认证系统的日志能力吹成完整的审计系统。合规结论要按已确认的监管要求和项目实施范围来说，不能笼统承诺"绝对合规"。
日志的安全也值得重视。日志里包含住客的手机号、上网记录这些个人信息，存储和查询都要有权限控制，不能谁都能看。日志数据要防止被篡改、丢失，加密存储、定期备份是基本要求。酒店在制定日志管理制度的时候，要明确谁能查、怎么查、查了做什么用途，这些规范既是对住客信息的保护，也是酒店自己的风险防线。
最后说实操层面的建议。酒店WiFi认证Portal认证的日志，从上线第一天就要把"留存、查询、导出、权限"这几件事跑通，不要等监管检查来了再临时抱佛脚。日常运维里，前台和IT处理客人网络投诉，认证日志是定位问题最快的入口：这个房间这个时间到底认证成功没有，一查就知道。日志把好用的价值发挥出来，它就不只是合规负担，还是酒店网络运营的帮手。
日志字段的明细，值得在方案里写清楚。认证类日志，通常要记录认证账号、认证方式、认证时间、认证结果；上网类日志，通常要记录终端信息、地址信息、上网起止时间、访问的站点和应用、流量情况。有的部署还涉及地址转换的对应关系，用于溯源链路补证。这些字段合起来，才能回答"谁在什么时间上了什么网"这个核心问题。字段覆盖到哪一层，跟系统能力和部署方式有关，要跟实施方逐项对齐。
日志的存储方式，本地和云端各有取舍。本地存储，数据在自己手里，访问和管理都方便，但要自己准备存储设备、做备份，运维成本高一些。云端集中存储，不需要本地硬件投入，扩容灵活，备份和检索由云端平台负责，但数据在第三方，酒店要评估合规风险，确认云端存储满足当地监管和自身的数据安全要求。新建酒店和改造酒店，存储方案的起点不同，选择也会不一样。
日志查询的实际场景，酒店可以提前梳理一遍。最常见的几类：监管检查要查某个时间段的上网记录；客人投诉网络问题要查某间房某天的认证情况；安全事件要追溯某台设备的访问轨迹。围绕这几类场景，确认查询功能能不能满足，查询响应时间在预期数据量下能不能接受。这些在使用中才会暴露的问题，验收阶段就应该测一轮。
日志管理制度也要跟上。谁能查日志、查了做什么用、查询要不要留痕、导出给谁，这些规范酒店要定出来。日志涉及住客个人信息，权限收得越紧，风险越小。运维人员离职、岗位变动，权限要及时调整。制度定在系统建设的时候，比出了事再补要从容得多。