linux日志分层存储:systemd-journald二进制日志(/run/log/journal或持久化/var/log/journal)、rsyslog文本日志(/var/log/messages等)、内核dmesg环缓冲区、auditd审计日志(/var/log/audit/audit.log)。

日志到底存在哪儿?别只记 /var/log 就完事
Linux 日志不是统一存一个地方,而是分层、分流、多格式共存。你看到的 /var/log/messages 或 /var/log/secure 只是 rsyslog 转发落地的文本副本;真正的第一手日志往往先经过 systemd-journald,以二进制形式暂存在 /run/log/journal(重启即丢),或持久化到 /var/log/journal(需手动开启)。内核启动阶段的日志甚至根本没走用户空间,只在 dmesg 环缓冲区里——/var/log/dmesg 文件只是开机后的一次快照。
- 查实时系统事件,优先用
journalctl -u sshd -n 20,不是tail -f /var/log/secure;后者可能有几秒延迟,且漏掉服务启动前的日志 -
/var/log/messages在 CentOS/RHEL 7+ 上默认不存在,被rsyslog配置为只收systemd转发来的部分消息,内容比journalctl少得多 - 审计类操作(如 sudo、用户登录)优先看
/var/log/audit/audit.log,它由内核auditd直接写入,绕过 syslog 流程,更难篡改
journalctl 查询慢、卡死?多半是没加过滤或没持久化
journalctl 默认读整个二进制日志库,如果没开持久化、又刚重装过系统,它会从内存里捞数据,速度还行;但一旦启用了 Storage=persistent 且运行了几周,未加约束的 journalctl 就可能卡住——不是 bug,是它真在扫描几百 MB 的索引文件。
- 永远带时间范围:
journalctl --since "2026-02-10" --until "2026-02-11 14:00",避免全量扫描 - 按服务查比关键词更稳:
journalctl -u nginx --priority err比journalctl | grep "502"快一个数量级,且不丢上下文 - 如果发现
journalctl --disk-usage显示超 1G,而SystemMaxUse=500M已设却无效,检查是否漏写了sudo systemctl restart systemd-journald
logrotate 配置了却不转?常见于权限、路径、定时器三处断点
logrotate 不是常驻进程,它靠 cron 每天调用一次 /etc/cron.daily/logrotate 触发。这意味着:配置改了不生效,不是语法错,很可能是 cron 没跑、目标文件权限不对、或日志路径和实际不符。
- 手动测试用:
logrotate -d /etc/logrotate.d/myapp(-d 表示 dry-run),看输出里是否出现rotating pattern和renaming,没有就说明匹配失败 - 确保日志文件属主可写,且
logrotate配置里的create 644 root root中的用户对目录有写权限;常见坑是应用以www-data写日志,但create指定root,导致新文件创建失败 - 若日志路径含变量(如
/var/log/app/<code>$(hostname)/access.log),logrotate不解析 shell 变量,必须写死或用外部脚本生成配置
远程日志转发为什么收不到?rsyslog 的 UDP 与 TLS 不是简单开关
配好 *.* @192.168.1.100:514 却没日志?UDP 默认无确认、易丢包,防火墙、路由、接收端 rsyslog 是否监听 UDP 都得验;想用 TLS 加密,则发送端和接收端证书、模块加载、端口(通常是 6514)、协议版本必须严格对齐。
- 先确认本地
rsyslog是否真正加载了模块:rsyslogd -v | grep imudp(UDP)或rsyslogd -v | grep gtls(TLS) - UDP 场景下,在接收端执行:
sudo ss -uln | grep :514,没输出说明rsyslog没监听,检查/etc/rsyslog.conf是否有module(load="imudp")和input(type="imudp" port="514") - TLS 转发时,
$DefaultNetstreamDriverCAFile必须指向接收端签发的 CA 证书,且发送端日志规则末尾要加;RSYSLOG_ForwardFormat,否则接收端解析失败
日志系统最麻烦的从来不是“怎么配”,而是“哪一层在说话”。journalctl 看到的,rsyslog 不一定转发;rsyslog 转发了,logrotate 可能压根没管那个文件;logrotate 转了,应用自己又开了个新日志句柄继续往旧文件写……链路一长,问题就藏在交接缝里。










