Golang 日志在 CentOS 上的压缩策略
一 策略总览与选择
在 CentOS 环境下管理 Golang 应用日志，通常有三条主流路径可选：
- 借助系统自带的
logrotate工具，按时间或大小轮转日志，并自动调用gzip进行压缩； - 在 Go 程序内部，通过集成第三方库（例如
lumberjack）来实现日志的滚动与压缩，让应用实现自我管理； - 完全自主编写轮转逻辑，根据时间或大小触发，再配合
gzip压缩与定期清理脚本。
那么，该如何选择呢？这里有几个简单的判断原则：
- 如果你的服务器上已有统一的日志管理规范，或者你希望利用系统工具进行集中管理，那么
logrotate是首选，它能与现有的运维体系无缝集成。 - 如果你追求应用的“自包含”性，希望程序不依赖外部定时任务（这在容器化部署中很常见），那么
lumberjack这类库会更适合。 - 只有当你的归档规则非常特殊，比如有特定的命名格式或合规性要求，现有方案都无法满足时，才值得投入精力去实现自定义方案。
二 使用 logrotate 的系统级压缩策略
这是最经典、最省心的方式。配置起来也不复杂，通常只需在 /etc/logrotate.d/ 目录下为你的应用创建一个配置文件，例如 /etc/logrotate.d/golang-app。
一个典型的配置示例如下：
/var/log/myapp/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0640 root adm
sharedscripts
postrotate
# 可选：通知应用重新打开日志文件（如 systemd 服务）
systemctl reload myapp.service >/dev/null 2>&1 || true
endscript
}这里面有几个关键参数，直接决定了日志的“命运”：
daily和rotate 7：组合起来意味着按天轮转，并且只保留最近7份历史日志。compress与delaycompress：这对搭档很有意思。compress表示要压缩，而delaycompress则会让压缩动作延迟到下一次轮转时再执行。这样做的好处是，最新的一份历史日志仍然是明文，万一需要紧急排查问题，可以直接查看，无需先解压。missingok和notifempty：前者让日志文件不存在时不报错，后者则避免轮转空文件，算是一些贴心的容错处理。create 0640 root adm：轮转后创建新日志文件时，指定其权限和属主。这关乎安全和多用户环境下的权限管理。postrotate脚本段：这里是精髓所在。轮转完成后，通常需要通知你的 Go 应用重新打开日志文件，以便后续日志能写入新文件。对于使用 systemd 管理的服务，一个systemctl reload命令往往是最高效的方式。
配置好后，别忘了验证和运行：
- 先用调试模式跑一遍，看看配置是否有误：
sudo logrotate -d /etc/logrotate.d/golang-app。 - 确认无误后，可以强制执行一次轮转：
sudo logrotate -f /etc/logrotate.d/golang-app。 - 至于定时执行，无需操心——
logrotate通常由系统的crond每日自动调用，除非你有特殊调度需求，否则不必额外配置 cron 任务。
三 在 Go 程序内使用 lumberjack 实现压缩
如果你希望日志管理逻辑与应用本身紧密绑定，那么 lumberjack 库是一个优雅的选择。首先，引入依赖：
go get gopkg.in/natefinch/lumberjack.v2接着，在代码中集成非常简单。下面是一个按文件大小滚动并自动压缩的示例：
package main
import (
"log"
"gopkg.in/natefinch/lumberjack.v2"
)
func main() {
log.SetOutput(&lumberjack.Logger{
Filename: "/var/log/myapp.log", // 日志文件路径
MaxSize: 10, // 单个文件最大 10 MB
MaxBackups: 7, // 最多保留 7 个历史文件
MaxAge: 28, // 文件最多保留 28 天
Compress: true, // 启用 gzip 压缩
})
log.Println("hello, this will be rotated and compressed")
}这种方案特别适用于容器化环境、短生命周期的进程，或者任何你希望应用能“拎包入住”、不依赖宿主机特定工具的场景。一切都在程序的控制之内。
四 自定义轮转与压缩脚本
当标准方案都无法满足你的需求时，就该自定义脚本上场了。核心思路很清晰：在 Go 程序中监听条件（时间或大小），触发时执行“重命名旧文件 -> 创建新文件 -> 压缩旧文件 -> 清理过期文件”这一系列操作。
一个高度简化的代码逻辑示例如下：
// 触发轮转时，将当前日志文件重命名为带时间戳的备份文件
os.Rename("app.log", "app.log."+time.Now().Format("20060102-150405"))
// 然后需要重新打开 “app.log” 文件，以便后续日志继续写入
// 异步或定时压缩旧文件
exec.Command("gzip", "app.log.20060102-150405").Run()
// 定期清理，例如删除30天前的压缩日志
exec.Command("find", "/var/log/myapp", "-name", "app.log.*.gz", "-mtime", "+30", "-delete").Run()需要注意的是，这条路看似自由，实则坑也不少。你必须妥善处理并发写日志时的安全（比如加锁）、程序收到终止信号时的优雅关闭、以及文件句柄的及时释放等问题。因此，它通常只推荐给那些有特定归档命名规则或严格合规要求的团队。
五 压缩策略与运维要点
最后，无论选择哪种策略，一些共通的运维要点都值得关注：
- 压缩算法与性能：默认的
gzip在压缩率和速度上取得了良好平衡，且兼容性极佳。如果磁盘空间非常紧张，且可以接受更高的 CPU 开销，可以考虑压缩率更高的算法如zstd，但这通常需要你自行集成或选用支持该算法的工具链。 - 保留策略：
rotate 7或MaxAge: 28这些数字不是拍脑袋来的。需要根据业务日志量、磁盘空间和合规性要求来设定，核心目标是防止历史日志无声无息地吃满磁盘。 - 权限与安全：日志可能包含敏感信息。建议将日志目录和文件权限设置为
0640，属主为root:adm这类组合，只允许必要用户和组读取。在多服务部署时，更要注意日志路径的隔离，避免相互覆盖。 - 应用重开文件：这是使用外部轮转工具（如 logrotate）时最容易出错的一环。务必在
postrotate脚本中通过systemctl reload或向进程发送SIGHUP信号，确保应用能及时切换到新日志文件，否则日志会继续写入已被轮转走的旧文件句柄。 - 监控与告警：日志管理不能是“设好就不管”。需要对日志目录的磁盘容量、压缩任务是否失败、轮转过程是否出错等建立监控和告警。毕竟，因日志满盘导致服务宕机的事故，可一点也不少见。
