linux日志系统是journald与rsyslog分工协作的实时数据管道：journald负责高保真结构化采集与快速检索，rsyslog负责标准化分发、持久化归档及远程转发。
Linux 日志系统不是简单地“把错误写进文件”，而是一套随系统演进而不断重构的实时数据管道。Syslog 架构和 journald 并非新旧替代关系，而是职责分工明确的协作体系：前者负责日志的标准化分发与长期归档，后者专注高保真、低延迟的结构化采集。
传统 Syslog 的设计逻辑与瓶颈
Syslog 本质是一套协议（RFC 5424）加实现（如 rsyslog），它定义了日志的来源（facility）、级别（severity）、格式和传输方式。早期 syslogd 把服务进程通过 syslog(3) 系统调用写入 /dev/log 的消息，按规则路由到不同文本文件——比如 auth.log 存 SSH 登录、kern.log 存内核消息。
但这种模式存在硬伤：
- 启动前日志丢失：syslog 服务本身要靠 systemd 启动，内核初始化、initrd 阶段的日志无法捕获；
- 纯文本无索引：查“某进程在某秒内报错”得靠 grep + tail -n 扫全文件，慢且不准；
- 时间精度仅到秒，多线程服务日志易交错，难以还原真实执行顺序；
- 权限与路径依赖强：应用若直接写文件（如 Nginx 写 /var/log/nginx/error.log），就完全绕过 syslog 流程。
journald 解决了什么核心问题
journald 是 systemd 的原生组件，从内核第一行输出开始就监听日志流，不依赖任何用户态服务。它把日志存为带元数据的二进制结构体（含 _PID、_UID、_COMM、_CMDLINE、纳秒级时间戳等），并建立内存+磁盘双索引。
这意味着：
- 所有日志——包括 kernel message、early-boot、cgroup 事件、容器 stdout/stderr——统一入口，无需配置就能关联；
- journalctl -u nginx --since "2026-07-05" -p err 不是读文件，而是按索引快速定位，响应常在毫秒级；
- 日志自带上下文：同一请求中，Nginx 错误、systemd 服务状态变更、内核 socket 调用失败可按 _HOSTNAME 和时间戳自动串联；
- 默认启用压缩与轮转，/var/log/journal/ 下的文件按大小或时间自动归档，避免填满根分区。
两者如何协同而非互斥
现代发行版（Ubuntu 22.04、Debian 12、CentOS Stream）普遍采用“journald 收集 + rsyslog 落地”的双轨模式：
- journald 是源头：所有服务 stdout/stderr 默认重定向到它，内核日志通过 /dev/kmsg 接入；
- rsyslog 作为消费者：加载 imjournal 模块，从 /run/systemd/journal/syslog socket 实时读取 journal 数据流；
- rsyslog 再按规则写入传统文件：auth.* → /var/log/auth.log，mail.* → /var/log/mail.log，同时支持转发到远程 SIEM 或数据库；
- 关键提示：/var/log/messages 这类文件只是派生副本，不是权威源；真正完整、不可篡改的日志只存在于 /var/log/journal/ 或内存中的二进制索引里。
排查时该先看哪个
别一上来就 tail -f /var/log/messages。先确认当前系统主干：
- 运行 systemctl is-active systemd-journald 确认 journald 是否运行；
- 执行 ls /var/log/journal/，有非空目录说明持久化已启用；
- 查 systemctl list-units --type=service | grep rsyslog，判断 rsyslog 是否启用；
- 若只需快速定位故障，优先用 journalctl -b -p 3（本启动会话的 err 及以上）；
- 若需长期审计或对接外部系统，再查 rsyslog 输出的文本文件或远程日志。
