Linux 日志系统原理与运维实践

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/$(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 转了，应用自己又开了个新日志句柄继续往旧文件写……链路一长，问题就藏在交接缝里。