Java Commons IO Tailer怎样跟踪日志文件轮转

Java Commons IO Tailer 跟踪日志轮转时，关键不是不停读取同一个文件名，而是把“旧文件改名、新文件出现、原路径短暂不存在”分别处理。监听器里的 fileRotated() 只表示检测到轮转，它发生在重新打开之前；如果日志框架还没创建新的 app.log，随后收到 fileNotFound() 也可能是正常的过渡状态。应用应记录这些状态，等待下一轮检查，而不是立刻把 Tailer 判定为永久故障。

官方地址：https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/input/Tailer.html

实际落地时优先使用 Tailer.builder()，明确字符集、轮询间隔、首次读取位置和 setReOpen 策略；用 TailerListener 区分新行、轮转、暂时缺文件和异常，并在应用关闭时调用 close()。

轮转不是简单的文件变小

常见的轮转动作是先把正在写入的 app.log 改名为 app.log.1，再创建新的 app.log。这时文件名相同，但底层文件对象已经换了。只盯着长度变化，容易把截断、轮转和暂时未创建混成一个问题。

Tailer 的回调边界比较实用：新行通过 handle(String) 交给监听器；检测到轮转时调用 fileRotated()；新文件暂时找不到时调用 fileNotFound()；读取发生异常则进入 handle(Exception)。我更愿意把回调当作状态信号，而不是在其中直接触发重启、告警升级或耗时的业务写入。

用 Builder 把跟踪策略写清楚

Commons IO 新版 API 推荐通过 Builder 组装 Tailer。下面的示例从末尾开始读取已有日志，使用 UTF-8 和一秒检查间隔，并让 Tailer 在读取分块之间重新打开文件。代码只负责接收事件；真正的日志解析或消息投递应放入有界队列，避免阻塞 Tailer 线程。

// 配置一个可停止的日志跟踪器；业务处理不要阻塞回调线程
Path logPath = Path.of("/var/app/logs/app.log");
TailerListener listener = new TailerListenerAdapter() {
    @Override
    public void handle(String line) {
        // 这里只做轻量分发，生产环境应交给有界队列或异步消费者
        log.info("app.log: {}", line);
    }

    @Override
    public void fileRotated() {
        // 轮转发生在重新打开之前，可记录一次边界事件
        log.info("app.log rotated; waiting for the new file");
    }

    @Override
    public void fileNotFound() {
        // 新文件尚未创建时可能短暂触发，不要立即判定为永久失败
        log.warn("app.log is temporarily unavailable");
    }

    @Override
    public void handle(Exception ex) {
        // 保留异常上下文，是否重试由上层生命周期策略决定
        log.error("tailer read failed", ex);
    }
};

Tailer tailer = Tailer.builder()
        .setPath(logPath)
        .setCharset(StandardCharsets.UTF_8)
        .setDelayDuration(Duration.ofSeconds(1))
        .setTailFromEnd(true)
        .setReOpen(true)
        .setTailerListener(listener)
        .get();

// 应用停止时调用 close，让跟踪线程完成当前循环并退出
tailer.close();

setTailFromEnd(true) 适合只关心启动后的新日志；如果需要补读现有文件，应改为 false，同时评估重复消费。setReOpen(true) 会在分块之间关闭并重新打开文件，便于某些轮转方式释放旧文件句柄，但也会增加打开操作。间隔、字符集和队列策略要按实际日志量调整，不能把一秒当成通用性能阈值。

三个方案怎么选，轮转边界在哪里

如果需求只是一次性读取文件，普通 Files.lines 更简单；如果需要持续跟随、处理轮转并接收异常回调，Tailer 的职责更贴合；如果要同时监控很多目录、精确感知创建与重命名事件，才值得考虑基于 WatchService 自己维护状态机。后者自由度更高，但也要自行解决事件丢失、重复通知、文件句柄和重连。

因此，单个日志文件的轮转跟踪通常选 Tailer；只有当“目录事件本身”比“持续读文件内容”更重要时，才把 WatchService 纳入方案。无论选哪种方式，都要让下游消费具备幂等性，因为轮转瞬间的重开和重试不应被设计成绝对不重复。

上线前要确认的四个细节

第一，确认日志框架的轮转方式是重命名、截断还是直接替换文件；不同动作会影响读取位置和重复风险。第二，确认编码，默认字符集不等于业务日志编码。第三，确认 fileNotFound() 的处理是等待、降级还是告警，尤其要给新文件创建留出时间。第四，应用退出路径必须调用 close()，并观察监听器线程是否能够结束。

fileRotated 后为什么还会收到 fileNotFound？

因为轮转回调发生在重新打开前，而日志框架可能先完成旧文件改名、稍后才创建同名新文件。应把它视为可恢复的短暂状态，结合持续时间和应用生命周期决定是否告警。

setReOpen 一定要设置为 true 吗？

不一定。它影响分块之间的关闭与重新打开行为，适合需要更积极释放旧文件句柄或配合轮转的场景，但会增加打开操作。应按操作系统、日志框架和吞吐量压测后决定。

Tailer 的价值在于把持续读取的基础循环和轮转回调准备好，但它不会替应用决定告警阈值、消息幂等或业务解析。把文件状态信号、消费策略和关闭动作分开设计，轮转后就不必靠猜。