Linux 用 logrotate 管理 Go 服务日志：copytruncate、权限和轮转验证

线上 Go 服务的日志文件最容易被忽略：程序一直正常跑，/var/log/order-api/app.log 却从几百 MB 慢慢涨到几个 GB。直接删掉它并不能解决问题，进程可能还握着原来的文件描述符，甚至继续往一个已经没有文件夹入口的文件里写。这个小项目用 logrotate 做轮转、保留和压缩，再用状态文件与实际文件结果复查配置是否真的生效。

先把问题缩小到一个真实日志文件

假设服务用户是 orderapi，程序把访问日志写到 /var/log/order-api/app.log。先不要急着安装一堆监控组件，观察文件当前是谁创建的、增长速度如何，以及服务是否仍在写入。

sudo ls -lh /var/log/order-api/app.log
sudo stat /var/log/order-api/app.log
sudo du -sh /var/log/order-api
sudo tail -n 20 /var/log/order-api/app.log

ls 能看到大小，stat 能补充所有者、权限和最近修改时间，du 则能避免只盯着一个文件而漏掉历史轮转文件。若文件夹里已经有一批 .log.1 或 .gz，先把它们的总量记下来，后面验收才有基线。

准备一个能持续写日志的 Go 小服务

为了让验证可重复，下面的程序每秒写一行简短日志。示例故意把日志文件路径作为启动参数传入，实际部署时可以改成配置文件或环境变量；重点是让进程持续持有同一个日志文件。

package main

import (
    "flag"
    "log"
    "os"
    "time"
)

func main() {
    path := flag.String("log-path", "/var/log/order-api/app.log", "日志文件")
    flag.Parse()

    file, err := os.OpenFile(*path, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0640)
    if err != nil {
        log.Fatal(err)
    }
    defer file.Close()

    logger := log.New(file, "order-api ", log.LstdFlags|log.Lmicroseconds)
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()

    for now := range ticker.C {
        logger.Printf("health tick at=%s status=ok", now.Format(time.RFC3339))
    }
}

编译前先创建文件夹，并让服务账号拥有文件夹而不是只拥有单个文件。这样轮转后新文件的创建权限才有明确依据。

sudo install -d -o orderapi -g orderapi -m 0750 /var/log/order-api
go build -o /usr/local/bin/order-api-log ./main.go
sudo -u orderapi /usr/local/bin/order-api-log \
  -log-path /var/log/order-api/app.log

另开一个终端观察增长：

watch -n 2 'ls -lh /var/log/order-api && tail -n 3 /var/log/order-api/app.log'

给 logrotate 写一份可解释的轮转规则

在 Debian、Ubuntu 等常见系统中，可以把项目规则独立放在 /etc/logrotate.d/order-api。下面的配置按天检查，保留 14 个历史文件，轮转后压缩，并在复制完成后截断原文件。

/var/log/order-api/app.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    copytruncate
    create 0640 orderapi orderapi
}

daily 是检查周期，不代表每次检查都一定产生新文件；文件为空时，notifempty 会跳过轮转。delaycompress 让刚轮转出来的第一份历史文件暂不压缩，下一轮再压缩，便于某些仍在短暂读取旧文件的程序处理。

这里选择 copytruncate 是因为示例程序没有提供重新打开日志文件的信号处理。logrotate 会先复制当前内容，再把原文件截断为零，Go 进程仍然写着原路径对应的文件描述符。它改动小，但复制和截断之间可能有极短的写入竞争窗口，所以高价值、强审计日志更建议让程序支持收到信号后关闭并重新打开日志文件。

先用调试模式验证，不要一上来改生产日志

规则写好后，第一步是让 logrotate 只展示计划，不改变文件。调试输出里应该能看到目标文件、轮转条件和动作；如果路径拼错、权限不足或规则语法有问题，这一步通常就会暴露。

sudo logrotate -d /etc/logrotate.d/order-api

注意输出里的三个信号：规则是否被读取、目标文件是否存在、当前状态是否被判断为“今天已经轮过”。若输出显示因为时间条件跳过，不要误判成配置失效，调试模式本来就会按状态文件和日期判断。

为了做一次不依赖日期的实验，可以在测试机上临时加入 size 1M，或手工把文件写到超过阈值后使用强制轮转。生产环境不要为了验证而随意缩短全局规则的周期。

sudo logrotate -d -s /tmp/order-api.logrotate.status \
  /etc/logrotate.d/order-api

用强制轮转观察文件、权限和压缩结果

测试机上可以使用强制模式执行一次。命令返回后，先看文件列表，再看服务是否仍在写新产生的 app.log。

sudo logrotate -f -s /tmp/order-api.logrotate.status \
  /etc/logrotate.d/order-api
sudo ls -lah /var/log/order-api
sudo stat /var/log/order-api/app.log
sudo tail -n 5 /var/log/order-api/app.log

第一次轮转常见的结果是 app.log 重新变小，同时出现 app.log.1。由于配置使用了 delaycompress，第一轮不一定马上出现 .gz；再执行一轮，旧文件才会进入压缩阶段。这个细节很容易让人误以为 compress 没生效。

最后验收：轮转成功不等于日志链路完整

验收至少做四件事。第一，检查当前文件还在增长；第二，确认历史文件内容不是空的；第三，确认权限没有让普通用户读到不该读的日志；第四，确认状态文件记录了本次轮转。

sudo timeout 8 tail -f /var/log/order-api/app.log
sudo zcat /var/log/order-api/app.log.2.gz | tail -n 3
sudo stat -c '%A %U:%G %s %n' /var/log/order-api/*
sudo cat /tmp/order-api.logrotate.status

如果系统使用全局状态文件，位置通常是 /var/lib/logrotate/status，不要把测试用的 -s /tmp/... 误认为生产配置。轮转后的日志还应接入现有采集器，确认采集端能识别新文件名；本地文件变小，只能证明轮转动作发生了。

在高并发服务上，copytruncate 的窗口可能不适合审计日志。更稳的升级路径是让 Go 程序监听信号、关闭旧文件并重新打开同一路径，然后用 postrotate 通知服务。这个改动需要结合进程管理方式、信号处理和采集端一起回归，不能只抄一行配置。

常见问题

copytruncate 会不会百分之百不丢日志？

不能这样保证。复制和截断之间存在竞争窗口，写入量越大越应该评估重开文件方案。它适合低改造成本的普通运行日志，不适合作为所有审计场景的默认答案。

为什么配置了 compress，第一轮没有 .gz？

如果同时配置了 delaycompress，刚产生的第一份历史文件会延后一轮压缩。先看 app.log.1 是否存在，再执行下一轮复查。

logrotate -d 会真的删除或截断日志吗？

不会，-d 是调试模式，主要用于展示判断和动作。真正改变文件前，先用它检查路径、状态文件和权限。

新日志文件为什么变成 root 所有？

通常是规则没有写正确的 create 用户组，或者文件夹权限不允许服务用户创建文件。用 stat 同时查看文件夹和文件，再核对 create 0640 orderapi orderapi。

把这套检查留成上线清单

小服务第一次接入 logrotate 时，真正值得留下的是验收记录：日志路径、服务用户、轮转周期、保留数量、是否延迟压缩、轮转后服务是否继续写入，以及采集端是否能看到新文件。配置不是写完就结束，至少完成一次调试、一次测试轮转和一次真实文件复查，后面再把规则纳入主机初始化或配置管理。