golang日志centos为何丢失

在 CentOS 上运行 Go 程序日志“丢失”，通常不是 Go 本身的问题，而是 运行环境 / 日志写入方式 / 系统管理策略 导致的。下面按“最常见 → 较少见”的顺序给你系统性排查清单。

一、最常见原因（80% 都在这）

1️⃣ 程序以后台方式运行，输出被吞掉

很多人在 CentOS 上这样跑：

nohup ./app &

或

./app > /dev/null 2>&1 &

➡ 日志根本没写文件，直接丢了

✅ 正确做法：

nohup ./app >> /var/log/app.log 2>&1 &

2️⃣ 日志写到了 stdout / stderr，但你看错地方

Go 默认：

fmt.Println("xxx")
log.Println("xxx")

这些 只写到 stdout/stderr，不会自动写文件。

如果你是通过：

systemctl
supervisor
cron

运行，日志可能在：

journalctl -u your-service

或

/var/log/messages

✅ 建议：Go 程序一定要显式写日志文件或用日志库

3️⃣ systemd 吞日志（非常常见）

如果你用：

[Service]
ExecStart=/opt/app

但没有配置：

StandardOutput=file:/var/log/app.log
StandardError=file:/var/log/app.err

➡ 日志全进 journald
➡ 你直接 cat /var/log/app.log 是空的

✅ 解决：

journalctl -u your-service -f

或显式写文件。

二、Go 日志本身的问题

4️⃣ 用了 log 但没设置输出位置

log.SetOutput(os.Stdout)

如果你以为它写文件，其实没有。

✅ 正确：

log.SetOutput(&lumberjack.Logger{
    Filename:   "/var/log/app.log",
    MaxSize:    10,
    MaxBackups: 5,
})

5️⃣ 日志没 flush（程序崩溃 / kill）

Go 的 os.File.Write 是带缓冲的

如果你：

kill -9
panic 没 recover
容器被强杀

➡ 缓冲区日志直接丢失

✅ 建议：

使用 log/slog
或使用 zap / logrus
程序退出前 sync()

三、CentOS 系统级原因

6️⃣ 磁盘满 / inode 满

df -h
df -i

➡ 日志写不进去，但不报错（或只报一次）

7️⃣ SELinux 阻止写日志

CentOS 默认开启 SELinux

ls -Z /var/log/app.log

如果权限不对：

setenforce 0  # 临时关闭测试

✅ 正式解决：

semanage fcontext -a -t var_log_t "/var/log/app.log"
restorecon -v /var/log/app.log

8️⃣ logrotate 把日志“转没了”

CentOS 常见：

/var/log/app.log {
    missingok
    notifempty
    copytruncate
}

如果你：

没用 copytruncate
程序持有旧 fd

➡ 日志写到“已经被 rename 的文件”

✅ 最佳方案：

用 lumberjack
或 copytruncate

四、容器 / 云环境特例

9️⃣ Docker / Kubernetes

日志在：

docker logs xxx
kubectl logs pod

你写在：

/var/log/app.log

但容器一重启 → 文件没了

✅ 正确做法：

写 stdout
或挂 volume

五、快速自检清单 ✅

你可以逐条确认：

[ ] 日志是否写文件（不是 stdout）
[ ] 是否用 >> 或日志库
[ ] 是否 systemd / nohup
[ ] df -h / df -i
[ ] journalctl -u 服务名
[ ] SELinux 状态
[ ] logrotate 配置

六、推荐你直接用这套（最稳）

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

log.SetOutput(&lumberjack.Logger{
    Filename:   "/var/log/app/app.log",
    MaxSize:    50,
    MaxBackups: 7,
    Compress:   true,
})

如果你愿意，可以把下面信息发我，我可以直接帮你定位：

怎么启动的（systemd / nohup / docker）
日志代码（log / zap / 自写）
日志“丢失”的具体表现（空文件 / 没生成 / 中途停）

我可以给你精确修复方案。