CentOS 环境下 Golang 日志轮转策略
策略总览
在 CentOS 上管理 Golang 应用的日志轮转，通常有两条清晰的主线可供选择：
- 借助系统级的
logrotate工具，按时间或大小对日志文件进行归档与清理。 - 在程序内部集成第三方库（例如
lumberjack），实现按大小或时间的自动切割。
当然，这两种方式也可以结合使用，形成互补：让应用程序负责按大小切割，而系统层面的 logrotate 则负责按时间进行压缩和最终清理。
方式一：使用 logrotate 的系统级策略
这是最经典、最符合 Unix 哲学的做法。其核心在于编写一个配置文件，交由系统定时执行。
一个典型的配置示例如下（通常保存在 /etc/logrotate.d/golang）：
/path/to/your/golang/app/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0640 root adm
sharedscripts
postrotate
/path/to/your/golang/app/restart.sh
endscript
}这里有几个关键指令值得细说：
- daily：指定按天轮转。当然，你也可以换成
size 100M来按文件大小触发。 - rotate 7：保留最近 7 份归档文件，更旧的会自动删除。
- compress / delaycompress：对旧日志进行压缩以节省空间。
delaycompress通常用于避免刚轮转出来的日志文件被立即压缩，方便排查最新问题。 - missingok / notifempty：如果日志文件不存在也不报错；如果是空文件，则不进行轮转。
- create 0640 root adm：轮转后新建日志文件的权限、属主和属组。
- postrotate … endscript：轮转后执行的脚本。这一步至关重要，常用于通知应用程序或重启服务，以确保其重新打开新的日志文件句柄。
配置好后，验证与运行就很简单了：
- 语法检查：执行
sudo logrotate -d /etc/logrotate.d/golang（调试模式，只模拟不实际执行）。 - 强制执行：执行
sudo logrotate -f /etc/logrotate.d/golang可立即触发一次轮转。 - 运行保障：
logrotate本身由系统的定时任务（如cron）定期调用，通常已预置，无需额外操心。
方式二：应用内置轮转 lumberjack
如果你希望将轮转逻辑完全封装在程序内部，实现应用的自包含，那么 lumberjack 是一个极佳的选择。它让日志切割变成了几行代码的事。
看一个简单的集成示例：
import (
"log"
"gopkg.in/natefinch/lumberjack.v2"
)
log.SetOutput(&lumberjack.Logger{
Filename: "/path/to/your/golang/app/logs/myapp.log",
MaxSize: 10, // 单个文件最大 10 MB
MaxBackups: 7, // 最多保留 7 个备份文件
MaxAge: 30, // 备份文件最长保留 30 天
Compress: true, // 启用压缩
})这种方式的特点非常鲜明：按大小触发切割、自动命名与清理、部署极其简单。当然，代价是需要引入第三方依赖，并需权衡其带来的运行时微小开销。
方式三：结合 syslog 或第三方日志库
除了上述两种主流方式，还有更灵活的路径：
- 输出到系统日志：让 Golang 应用将日志直接写到标准输出（stdout/stderr），然后由
rsyslog或syslog-ng这类系统日志守护进程进行采集。它们能根据设施、程序名等策略进行后续的轮转、压缩甚至转发到远程服务器，非常适合构建集中化的日志管理平台。 - 使用结构化日志库：如果你在使用像
logrus、zap这类功能强大的结构化日志库，它们通常也能与lumberjack无缝配合。这样既能享受按大小轮转的便利，又能保留结构化日志输出的强大能力。
如何选择与落地建议
面对这些选项，该如何决策呢？这里有几个清晰的思路：
- 如果你的运维体系倾向于统一治理，服务器上已经运行着各类应用，那么优先使用
logrotate。它是系统级的方案，侵入性低，配置集中，易于审计和管理。 - 如果你的应用是容器化的，或是短生命周期的进程，希望实现真正的“一次构建，随处运行”，那么优先使用
lumberjack。它将依赖内嵌在应用中，部署时无需关心宿主机环境。 - 如果你们正在或将要搭建统一的集中式日志平台（如 ELK Stack），那么让应用输出到 stdout/stderr，由
rsyslog或日志采集器（如 Filebeat）负责后续策略，会是更面向未来的架构。
无论最终选择哪种方式，落地时务必盯紧以下几个关键点：
- 明确触发条件（是按天还是按大小）、保留份数或天数、以及压缩与清理策略。
- 一定要配置可靠的通知或重启动作，确保应用在日志轮转后能重新打开文件句柄，避免日志继续写入已被重命名的旧文件。
- 定期使用调试模式验证配置是否按预期工作，同时监控磁盘使用情况和日志的完整性，这才是保障服务稳定的最后一道防线。
