OpenTAP 会话日志轮转与 Latest 链接机制

背景

在长期跑自动化测试时，日志既要“持续可写”，又不能“无限膨胀”。OpenTAP 在 SessionLogs 里实现了一套比较务实的会话日志策略：启动即建日志、按大小滚动、保留最近集合，并额外提供 Latest.txt 作为稳定入口。这个设计看起来简单，但把并发进程、跨平台、磁盘清理三个问题放在了一起。

框架分析

入口在 PluginManager.Load()，它会先调用 SessionLogs.Initialize()，保证插件系统初始化前就有日志可写。随后 CLI 层在 CliActionExecutor 中根据 EngineSettings.Current.SessionLogPath 再执行一次 SessionLogs.Rename()，把日志文件落到最终路径。也就是说，日志路径有“先初始化、后归位”的两段式流程。

SessionLogs 内部核心是 FileTraceListener：达到 LogFileMaxSize 后触发 FileSizeLimitReached，新文件按 __1、__2 递增。清理策略由 RemoveOldLogFiles() 执行，限制文件数量和总大小（默认最多 20 个、总计 2GB），同时保留至少两个文件，避免极端情况下把历史全删空。

实现过程

一个容易忽略的细节是 “最近日志索引” 文件 .opentap_recent_logs。OpenTAP 用命名互斥锁 opentap_recent_logs_mutex 来保护多进程读写，避免并发启动时互相覆盖。另一个关键点是 MakeLatest()：每次切换日志都会尝试创建 Latest.txt 硬链接，外部工具只盯一个固定文件名就能拿到当前会话输出。

可复现命令（用于快速验证调用链和关键实现）：

cd /home/ops/clawd/repos/opentap
grep -R "SessionLogs.Initialize\|SessionLogs.Rename\|FileSizeLimitReached\|MakeLatest" -n Engine

注意事项

第一，Latest.txt 使用硬链接，跨文件系统或权限受限场景可能失败，源码里采用了“尽力而为+吞异常”策略。第二，NoExclusiveWriteLock 允许日志文件被删除时继续写入“空洞流”，适合某些容器/挂载目录场景，但排障时要意识到“进程仍在写，文件却看不到”的现象。第三，日志清理依赖 recent 列表，如果部署环境频繁清理隐藏文件，保留策略会退化。

小结

SessionLogs 的价值不在“写文件”本身，而在它把日志生命周期做成了一个可运维的闭环：初始化早、重定位清晰、滚动可控、最新文件可追踪、历史可回收。对需要长期运行的测试系统来说，这比单纯追加日志更可靠，也更容易接入外部监控与采集。

关键源码路径

• Engine/SessionLogs.cs
• Engine/PluginManager.cs
• Engine/Cli/CliActionExecutor.cs
• Engine/EngineSettings.cs