systemd-journald 日志转发远程 syslog：rsyslog 对接与丢日志排查

发布时间：2026-09-19 04:31 更新时间：2026-09-19 04:31 阅读量：0

很多站长把日志集中到一台日志服务器上，方便检索和留存，结果配完转发后总觉得「日志少了」。问题通常不在网络，而在 journald 和 rsyslog 这两个日志组件之间的分工没理清：journald 负责收集内核与 systemd 单元的日志，rsyslog 负责落盘和转发，两者默认是「接力」关系而不是「复制」关系。这篇就把链路拆开讲，给出可直接照抄的配置，再说明日志丢失该从哪里查。

先搞懂 journald 与 rsyslog 的分工

在主流发行版上，systemd-journald 会把内核消息、服务标准输出、syslog 兼容消息都收进自己的二进制日志里，默认存放在 /var/log/journal/（持久化）或 /run/log/journal/（内存，重启即失）。rsyslog 通过读取 journald 的 socket 或 imjournal 模块拿到这些消息，再写入 /var/log/messages、/var/log/syslog 等文本文件，或者转发到远端。

所以「转发到远程 syslog」有两条路：一是让 rsyslog 从 journald 读消息再转发（推荐，过滤规则灵活）；二是直接在 journald 里配置 ForwardToSyslog、ForwardToSocket 之类的开关。后者虽然简单，但过滤能力弱，排查时也不容易看清丢在哪一段。生产环境一般用第一种。

另外要确认一个前提：日志服务器的时间必须准。各个节点时间不同步时，集中检索会一片混乱，chrony/NTP 该配就配。

rsyslog 从 journald 读日志并转发

先确认 rsyslog 装了 imjournal 模块，多数发行版的 rsyslog 包都自带。编辑 /etc/rsyslog.conf，在模块加载区加入下面三行，让 rsyslog 从 journald 读取消息：

module(load="imjournal"
       StateFile="imjournal.state"
       Ratelimit.Interval="0"
       Ratelimit.Burst="0")

其中 Ratelimit.Interval="0" 表示不限速，避免短时间大量日志被 rsyslog 自身丢弃；StateFile 记录读取位置，重启后不会重复或漏读。接着在规则区加一条转发规则，把全部消息发往日志服务器：

*.* @@10.0.0.20:514

注意 @@ 表示 TCP（可靠，推荐），单个 @ 表示 UDP（快但可能丢包）。改完先做语法检查再重启，不要直接重启等报错：

rsyslogd -N1
systemctl restart rsyslog

接收端（日志服务器）同样要开启 TCP 监听。在它的 /etc/rsyslog.conf 中加载 imtcp 模块并设置模板与落盘路径，例如：

module(load="imtcp")
input(type="imtcp" port="514" ruleset="remote")
template(name="RemoteLog" type="string"
  string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")
ruleset(name="remote") {
  action(type="omfile" dynaFile="RemoteLog")
}

这样每台机器会按主机名分目录落盘，后续排查方便按机器过滤。input 的语法在新版本 rsyslog 中更推荐这种写法，具体以你系统上的官方文档为准。

日志丢失了该从哪里查

转发配好却「少日志」，按下面顺序排查效率最高。

第一，看 journald 自己有没有限速。journald 默认对同一服务的日志做速率限制，短时间刷屏会被丢弃，日志里会出现类似「Suppressed N messages」的提示。可以在 /etc/systemd/journald.conf 中调整 RateLimitIntervalSec 与 RateLimitBurst，调大后执行 systemctl restart systemd-journald 生效。注意放宽限速意味着磁盘写入压力变大，别一味调大。

第二，看 journald 是否真的把消息交给了 rsyslog。用 journalctl -u 服务名 -f 实时观察，同时用 tail -f /var/log/messages 对照。如果 journald 有、文本文件没有，问题在 rsyslog 的读取或过滤规则；如果两边都有、远端没有，问题在转发链路。

第三，确认 journald 的转发开关。检查 /etc/systemd/journald.conf 中 ForwardToSyslog 是否为 yes（多数发行版默认开启），改完记得重启 journald。

第四，检查接收端端口和防火墙。UDP 514 丢包很常见，尤其是网络抖动或接收端处理不过来时；换成 TCP 能显著降低丢失概率。同时确认接收端磁盘没满、rsyslog 没被限速，接收端的 imtcp 也支持 Ratelimit.* 参数。

第五，注意日志轮转。远端文件如果没配 logrotate，长时间跑下来会把磁盘写满，写满之后新日志自然进不来，表现就像「转发突然停了」。

最后提醒一句：转发不是备份。链路和接收端都可能出问题，关键业务日志建议在本地保留一份，远端再存一份，本地留存周期按合规和磁盘容量自行权衡。

整体思路就是让 rsyslog 承担「读取 journald + 过滤转发」的角色，用 TCP 提高可靠性，遇到丢日志时按「journald 限速 → rsyslog 读取 → 网络转发 → 接收端落盘」四段逐层定位。先把链路跑通，再根据日志量调整限速和轮转策略，集中日志平台才算真正可用。

继续阅读