Linux /var/log 目录结构解析

1次阅读

根本原因在于是否被logrotate管理:系统服务默认配置logrotate规则,而手动直写日志不会触发轮转;journald与syslog是两套独立体系,日志位置和查看方式不同。

Linux /var/log 目录结构解析

为什么 /var/log 里有的日志会自动轮转,有的却越攒越多?

linux 日志行为不一致,根本原因在于是否被 logrotate 管理。系统服务(如 syslognginx)默认常配 logrotate 规则,而你自己用 echo "xxx" >> /var/log/myapp.log 这种直写方式,不会触发任何轮转。

  • logrotate 配置文件通常在 /etc/logrotate.d/ 下,每个服务一个配置片段
  • 轮转是否生效,取决于该配置是否启用 dailysizerotate 等关键指令
  • 手动测试:运行 logrotate -d /etc/logrotate.d/nginx-d 表示 dry-run,只打印动作不执行)
  • 常见坑:配置文件权限错误(非 root:root 或含写权限),logrotate 会直接跳过

journald/var/log/syslog 是两套日志体系,别混着查

systemd 系统默认启用 journald,它把内核、服务、用户会话日志全收进二进制文件(/run/log/journal//var/log/journal/),而传统 rsyslogsyslog-ng 写的才是文本型 /var/log/syslog/var/log/messages

  • journald 日志用 journalctl,不是 tail -f /var/log/syslog
  • 若关闭了 journald 持久化(Storage=volatile),重启后 /var/log/journal/ 为空,但 /var/log/syslog 仍存在(如果 rsyslog 在运行)
  • 二者可能重复记录同一事件,比如 ssh 登录既出现在 journalctl _COMM=sshd,也出现在 /var/log/auth.log
  • 性能影响:journald 默认内存缓存 + 异步刷盘,比纯文件追加更轻量;但文本日志便于 grepawk 直接处理

/var/log/boot.log/var/log/kern.log 不是所有发行版都默认生成

这些文件是否存在,取决于底层日志服务是否显式配置了对应 facility 或输出路径。

  • /var/log/boot.log:多数 ubuntu/debian 有,centos/RHEL 8+ 默认不生成(systemd 启动过程日志已归入 journalctl -b
  • /var/log/kern.log:由 rsyslogkernel.<em></em> 规则决定,若配置里没写 .kern;*.info;mail.none;authpriv.none;cron.none /var/log/kern.log,就不会产生
  • 容易误判:看到 ls /var/log | grep kern 没结果,就以为内核没打日志——其实 dmesgjournalctl -k 才是权威来源
  • 兼容性提示:容器环境或 minimal 系统(如 Alpine)通常压根不装 rsyslog/var/log 下只有应用自己写的日志

自定义应用日志该往哪放?别硬塞进 /var/log 根目录

直接 touch /var/log/myapp.log 并写入,看似省事,但会破坏权限模型和轮转逻辑。

  • 正确做法:新建子目录 /var/log/myapp/,属主设为运行该应用的非 root 用户(如 chown myapp:myapp /var/log/myapp
  • 必须配 logrotate:在 /etc/logrotate.d/myapp 中指定路径、轮转条件、create 644 myapp myapp
  • 避免踩坑:不要让应用以 root 权限直接写 /var/log/myapp.log,否则轮转后新文件可能权限错误,导致下次写入失败(Permission denied
  • 替代方案:应用直接对接 systemd-journald(如用 sd_journal_print()logger -t myapp),完全绕过文件管理

日志路径本身不复杂,难的是谁在管它、怎么管、管到哪一级——漏掉任意一层,都会让排查时卡在“这日志到底去哪了”。

text=ZqhQzanResources