rsyslog 与 systemd-journald 是分工协作关系：journald 负责统一采集和结构化存储，rsyslog 负责分类过滤、持久化文本日志及远程转发；前者适合本地快速检索，后者更适配企业级归档、审计与跨平台汇聚。
rsyslog 和 systemd-journald 不是互斥关系，而是分工协作：journald 负责统一采集和结构化存储，rsyslog 负责分类、过滤、持久化文本日志及远程转发。集中日志方案中，journald 适合本地快速检索，rsyslog 更适配企业级归档、审计与跨平台汇聚。
日志来源与采集方式不同
journald 是 systemd 原生组件，直接从内核消息、early boot 输出、systemd 服务的 stdout/stderr、以及 /dev/log（兼容 syslog 协议）实时捕获所有事件，无需应用主动调用 syslog()；它把日志以带索引的二进制格式写入内存或磁盘（如 /var/log/journal），自带完整元数据（_PID、_UID、_COMM 等）。
rsyslog 是传统 syslog 协议的强化实现，本身不主动“采集”，而是被动接收来自应用程序 syslog() 调用、/dev/log、网络 UDP/TCP 端口、甚至 journald 的日志流（通过 imjournal 模块）。它更依赖程序是否适配 syslog 接口，对老旧脚本或容器内未配置日志驱动的应用可能漏收。
转发能力与集中日志适配性差异明显
rsyslog 是集中日志架构的事实主力：
- 原生支持 TLS 加密、队列缓冲（disk-assisted）、负载均衡、重试机制，生产环境稳定性强
- 可按 facility/level/内容正则等多维条件精准路由，例如将 authpriv.* 发往 SIEM，kern.warning 发往告警平台，mail.* 写入专用归档库
- 输出目标丰富：文件、MySQL/PostgreSQL、Elasticsearch、Kafka、HTTP API、远程 syslog 服务器等
- 日志格式完全可控，支持自定义 template，便于下游解析（如 JSON 格式直送 ELK）
journald 的远程转发能力有限：
- 本身不内置网络转发模块，需借助 rsyslog（imjournal）或 systemd-cat + netcat 等间接方式外发
- 无法按内容做过滤，只能按 unit、priority、_SYSTEMD_UNIT 等元数据做粗粒度筛选
- 二进制 journal 格式不通用，远端接收方必须支持 systemd 日志解析（如 journal-remote 或特定 SIEM 插件），兼容性差
持久化、查询与运维习惯的取舍
rsyslog 日志默认落盘为纯文本（/var/log/messages、secure 等），可用 tail、grep、awk、logrotate 直接处理，符合管理员长期形成的排查习惯，也满足等保/合规对日志留存格式的要求。
journald 查询高效但受限：
- journalctl 支持时间范围、服务名、优先级、字段匹配（如 journalctl _COMM=sshd -p err），响应快
- 但无法用标准文本工具直接读取，导出需加 -o json 或 -o verbose，且原始二进制 journal 文件不可被第三方审计工具直接扫描
- 默认仅内存暂存（/run/log/journal），重启即丢；启用持久化需手动创建 /var/log/journal 并赋权，否则无法保留历史
典型集中日志部署推荐组合
生产环境不建议只用 journald 或只用 rsyslog，推荐分层协作：
- 采集层：journald 兜底收集全部系统事件（含早期启动、内核、服务 stdout）
- 处理层：rsyslog 启用 imjournal 模块，持续拉取 journal 流，同时监听 /dev/log 和 TCP 514 接收其他设备日志
- 分发层：rsyslog 按规则分流 —— 本地文本归档 + 加密发往中心 syslog 服务器 + 关键事件推 Kafka
- 存储层：中心服务器用 rsyslog 或专用日志平台（如 Graylog、Loki）统一入库、索引、告警
这种模式兼顾了完整性、灵活性与可审计性，既不丢失 journald 的结构化优势，又发挥 rsyslog 在转发、过滤和生态集成上的成熟能力。
