systemd-journald 是日志架构底层核心，直接捕获完整启动链及细粒度事件；rsyslog 作为其下游消费者，通过 imjournal 模块转发日志并落地为文本文件；非 syslog 应用日志常绕过该架构直写文件。
systemd-journald 是日志架构的底层核心
linux 系统日志不是单一服务在工作，而是由 systemd-journald 打底、rsyslog（或 syslog-ng）做转发和落地的分层结构。从 2014 年起，主流发行版（RHEL/centos 7+、ubuntu 16.04+、debian 8+）默认启用 systemd-journald，它不依赖文件系统，直接将日志写入二进制索引数据库（/run/log/journal/ 内存中，或 /var/log/journal/ 持久化），记录粒度极细：内核早期输出、initrd 日志、服务 stdout/stderr、甚至容器和 cgroup 事件都能捕获。
关键点在于：systemd-journald 是唯一能拿到“完整启动链”日志的服务；而传统 syslog 守护进程（如 rsyslog）默认只从 journald 的 API 接收日志流，并不直接读取内核或 early-boot 数据——除非你显式配置 $ForwardToJournal off 并启用 imklog 或 imuxsock 模块。
rsyslog 负责日志的路由、过滤与持久化落地
rsyslog 不是“替代”journald，而是它的下游消费者。它通过 imjournal 模块监听 journald 的 socket，按规则把日志分发到不同目标：/var/log/messages、/var/log/secure、远程服务器，甚至数据库。它的配置逻辑围绕三要素展开：facility（来源类别）、priority（级别如 err、notice）、target（目标路径或地址）。
- 常见陷阱：
/etc/rsyslog.conf中若未加载imjournal模块（即缺少$ModLoad imjournal），rsyslog就收不到 journald 日志，导致/var/log/messages空或严重滞后 - 优先级匹配注意：
authpriv.*匹配所有级别（包括 debug），而authpriv.err只匹配err及更高级别（crit、alert、emerg） - 异步写入优化：
-/var/log/secure开头的短横线表示“延迟刷盘”，提升性能但断电可能丢最后几条日志
/var/log 下的日志文件其实是“派生品”，不是源头
很多人误以为 /var/log/messages 是系统原生日志源，其实它是 rsyslog 根据规则聚合写入的文本文件。真正权威、不可篡改、带结构化字段（_PID、_COMM、_HOSTNAME、SYSLOG_IDENTIFIER）的日志只存在于 journald 数据库中。这意味着：
-
tail -f /var/log/messages看不到服务刚启动时的 stderr 输出，但journalctl -u sshd -f可以 -
grep "Failed password" /var/log/secure可能漏掉未被 rsyslog 规则捕获的认证事件；而journalctl _SYSTEMD_UNIT=sshd.service | grep "Failed"更全 - 日志轮转（
logrotate）只作用于/var/log/下的文本文件，不影响 journald 数据库存储；journald 自身靠/etc/systemd/journald.conf中的SystemMaxUse=和MaxRetentionSec=控制磁盘用量
非 syslog 应用日志常绕过整套架构
像 nginx、mysql、dockerd 这类应用，默认往往直接写自己的日志文件（如 /var/log/nginx/access.log），不走 syslog 接口，也不进 journald——除非你手动配置它们启用 syslog 输出（如 nginx 的 error_log syslog:server=127.0.0.1:514;）。这类日志的特点是：
- 格式完全自定义，无统一时间戳/优先级字段，
journalctl查不到 - 权限和轮转需单独管理（比如用
logrotate配置/etc/logrotate.d/nginx） - 安全审计时容易遗漏：SELinux 或 auditd 规则若只监控
/var/log/，就捕获不到这些独立日志的写入行为
真正复杂的不是架构本身，而是搞清每条日志究竟走了哪条路径——journald 原始流？rsyslog 过滤后文本？还是应用直写文件？漏看任何一层，排查问题时就可能卡在“日志明明该有，却死活找不到”的状态。