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 没跑、目标文件权限不对、或日志路径和实际不符。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 手动测试用：
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 转了，应用自己又开了个新日志句柄继续往旧文件写……链路一长，问题就藏在交接缝里。
