Go Lumberjack 多个进程为什么不能共用同一个轮转文件

Go Lumberjack 不适合让多个进程共用同一个轮转文件，因为它按单进程写入的假设维护活动文件、大小计数和备份清理。每个 Logger 的互斥锁只保护自己的实例，不能协调另一个进程。更稳妥的方案是给每个实例分配独占的文件与备份名称空间，或者把多进程日志交给独立采集层统一处理。

官方地址：https://github.com/natefinch/lumberjack

这里讨论 v2 的 gopkg.in/natefinch/lumberjack.v2。如果单进程时正常，扩成多个 worker 后才出现轮转异常，首先应检查输出路径是否被多个进程共用，而不是先增大 MaxSize 或关闭压缩。

从异常现象追踪所有写入者

设想两个独立 worker 都把 Filename 配成同一个 worker.log。它们启动时分别创建 Logger，拥有各自的内存状态。低负载时日志看起来可能只是混在一起；轮转发生后，活动路径、已打开句柄和归档文件之间才开始暴露不一致。

排查时需要记录每个服务实例实际解析后的完整日志路径，同时查清是否还有外部轮转任务、重复创建的 Logger 或另一个版本进程。两个不同的配置字符串也可能经由共享挂载或符号链接指向相同文件空间，不能只比较配置表面文字。

日志分散在预期之外的备份、活动文件看似增长不符合配置、归档操作失败等都可以成为线索，但具体表现取决于操作系统和存储环境。不能仅凭某一种现象断言已经定位，也不能把本文的分析当成一次真实故障记录。

一把实例锁看不到另一个进程

Lumberjack 的 Logger 保存自己的 size、file 和互斥锁等状态。A 的锁不会让 B 停止写入，也不会把 A 的大小计数同步给 B。即使单次追加写在某个环境下没有交错，轮转还涉及关闭句柄、重命名旧文件、创建新活动文件及管理备份，远不止一次 Write。

以常见的类 Unix 文件语义理解风险：某进程完成路径重命名，并不代表另一个进程已经打开的句柄自动切换到新活动文件。因此“两个进程都写同一个文件名”不等于“两个进程一直写同一个当前文件对象”。其他平台可能表现为不同错误，但不应由此推导出多进程共用受到支持。

备份也属于同一个管理范围。同名配置会让各实例识别并处理同一批归档，压缩和清理动作可能相互干扰。只给进程中的写入函数再套一把 sync.Mutex，不能覆盖另一个进程，更不能把这套本来没有协调协议的轮转逻辑变成跨进程事务。

给每个进程分配独占目录

修复应先明确“谁拥有活动文件以及对应备份”。按实例拆分目录，是容易检查的一种做法：A 管自己的活动文件与归档，B 管另一套；集中搜索日志由采集层完成。一个进程内部则让业务模块共享同一个输出实例，不要每个模块都用相同路径重新 new 一个 Logger。

下面的原创初始化示例通过 MkdirTemp 分配唯一目录，用于说明独占所有权，不会在退出时删除日志。代码使用 errors.Join，需要 Go 1.20 或更新版本，并依赖 Lumberjack v2。它没有实际运行，也没有通过大量写入制造轮转。

package main

import (
    "errors"
    "fmt"
    "log"
    "os"
    "path/filepath"

    "gopkg.in/natefinch/lumberjack.v2"
)

func run() (err error) {
    root := "./logs"
    if err := os.MkdirAll(root, 0700); err != nil {
        return fmt.Errorf("创建日志根目录: %w", err)
    }
    // 每次启动分配独占目录；目录会保留，不是退出即删除的临时数据。
    dir, err := os.MkdirTemp(root, "report-worker-")
    if err != nil {
        return fmt.Errorf("分配实例日志目录: %w", err)
    }
    output := &lumberjack.Logger{
        Filename: filepath.Join(dir, "worker.log"),
        MaxSize: 32,
        MaxBackups: 4,
        MaxAge: 7,
        Compress: true,
    }
    defer func() {
        // 真实服务应先停止并等待所有日志生产者，再关闭输出。
        if closeErr := output.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭日志输出: %w", closeErr))
        }
    }()
    logger := log.New(output, "", log.LstdFlags|log.LUTC)
    fmt.Fprintln(os.Stderr, "本次实例日志目录:", dir)
    // Output 返回写入错误，便于初始化失败时交给调用方处理。
    if err := logger.Output(1, "实例日志初始化完成"); err != nil {
        return fmt.Errorf("写入启动日志: %w", err)
    }
    // 业务模块共享 logger 或同一个 output，不再为同一路径新建实例。
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

示例的随机目录会一直保留。MaxAge 与 MaxBackups 只约束相应 Logger 识别的备份，不能替你回收所有历史启动目录。因此真实部署需要额外的目录保留策略，且只能在确认没有活跃写入者后回收旧目录。

如果希望重启后继续使用固定目录，可以由部署系统提供唯一实例标识，再保证同一标识不会被两个并存进程同时占用。仅用 PID 命名在跨机器、跨容器或共享存储环境中不够稳妥：PID 可以重复，也会被复用。滚动更新的新旧实例重叠期间同样要保持独占关系。

按实际部署选择修复路径

迁移时先修改新实例的路径分配，记录实际目录，再逐步退出旧的共用写入者。不要在仍有旧进程运行时直接删除或搬走历史日志。若已经使用外部轮转工具，也要明确由哪一方负责轮转，避免两种机制同时管理同一个活动文件。

采用进程间文件锁并不是给现有配置补一行就完成。若坚持设计共享文件方案，需要把所有写入、大小状态、句柄切换、备份生成和清理纳入一致协议；本文不建议将它当作 Lumberjack 原有能力，也不提供一个只保护部分操作的伪修复。

修复之后观察什么

应关注每个活跃进程的实际日志目录是否唯一、活动日志与归档是否归属于对应实例、写入及轮转错误是否仍出现，以及采集层是否把新目录纳入范围。改变路径后看不到日志，也可能只是采集配置还指向旧路径，不能把它误判成应用没有写入。

这些是建议的复查项，不是本文声称已经完成的验证结果。日志目录总容量也需要监控，因为实例拆分后，每个实例的保留上限相加，才接近整体磁盘预算；单实例配置不能代表整机或整个共享卷的容量限制。

关闭 Compress 就能共用了吗？不能。压缩只是归档管理的一部分，活动句柄与轮转状态仍然各自独立。

同一进程创建两个相同 Filename 的 Logger 呢？也应避免。锁和状态属于实例，多个实例不会自动因为路径相同就共享协调。让它们引用同一个输出对象更清楚。

重启后沿用同一个独占文件可以吗？关键是前一个写入者已经结束，文件空间由当前单一实例管理。若新旧进程并存，则需要拆分，不能仅以“这是重启”作为独占保证。

参考：Lumberjack 官方单进程使用约定；v2 Logger 状态与轮转实现。