大多数情况下，rsyslog 日志无法发送到远程服务器，根本原因通常集中在几类常见问题：默认未启用 UDP/TCP 模块，或者连接被防火墙、SELinux 直接拦截。更稳妥的排查方式是先执行 rsyslogd -N1，确认 imudp、imtcp 是否已经正确加载；如果没有加载，就在配置文件开头补充 module(load="imudp") 和 module(load="imtcp")，并同时配置对应的 input 规则，确保 Linux 日志远程同步与转发功能可正常工作。
rsyslog 配置远程转发时，为什么日志发不出去？
绝大多数场景下，rsyslog 日志远程转发失败，都是因为默认没有启用 UDP/TCP 网络模块，或者被防火墙、SELinux 策略拦截了连接。在正式修改配置前，建议先检查相关模块是否已经加载：
- 运行
rsyslogd -N1，如果提示imudp或imtcpnot found，就说明对应网络模块尚未加载 - 在
/etc/rsyslog.conf或/etc/rsyslog.d/50-default.conf开头添加：module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514") - UDP 转发速度快但不保证可靠送达，生产环境中的 Linux 日志远程转发通常更建议使用 TCP（加
@@前缀），但前提是接收端也必须同时开启 TCP 监听
如何把特定 facility 的日志单独发到远程服务器？
不能只依赖全局 *.* @@remote:514，否则所有系统日志都会混在一起，不利于分类管理。正确做法是通过规则匹配 + 模板定义 + 动作分离，实现特定 facility 日志单独转发：
- 定义模板，避免远程日志在时间戳、主机名等字段格式上不一致：
template(name="RemoteFormat" type="string" string="%protocol-version% %timestamp:::date-rfc3339% %hostname% %app-name% %procid% %msg%n")
- 按 facility 条件过滤并绑定模板：
if $syslogfacility-text == 'auth' then {
action(type="omfwd" target="192.168.10.20" port="514" protocol="tcp" template="RemoteFormat")
} $syslogfacility-text使用的是字符串值（例如auth、daemon），不是数字；比较时应使用==，除非确实有必要，否则不要使用=~做正则匹配
journalctl 日志能否直接远程转发？
不能直接转发，systemd-journald 本身并不提供原生网络输出能力。要实现 journalctl 日志远程转发，必须通过 rsyslog 或 syslog-ng 接入处理：
- 确认
/etc/rsyslog.conf中已启用$ModLoad imjournal（适用于 rsyslog v8+） - 重启
rsyslog服务后，journal 日志会自动注入 rsyslog 处理流程，再按照前面的转发规则发送到远程日志服务器 - 如果发现 journal 日志缺失，需要重点检查
imjournal是否启用，以及/run/systemd/journal/dev-log的权限是否为srw-rw---- systemd-journal - 需要注意的是，journal 中的
_HOSTNAME和SYSLOG_IDENTIFIER字段会映射为 rsyslog 的$hostname和$programname，因此也可以直接用于日志过滤和分类转发
远程转发失败时，怎么快速定位是哪一环断了？
排查 rsyslog 远程转发失败时，不要只盯着配置文件本身，按本地、网络、接收端分层验证通常更高效：
- 本地测试：使用
logger -p auth.info "test msg"手动写入一条日志，再通过tail -f /var/log/syslog查看是否成功生成 → 先排除应用层或本地日志写入问题 - 本地收发测试：在本机启动临时接收端
nc -u -l -p 514（UDP）或nc -l -p 514（TCP），然后再次发送日志，观察能否收到 → 用于判断 rsyslog 输出动作是否真正生效 - 网络连通性测试：通过
telnet 192.168.10.20 514（TCP）或nc -u 192.168.10.20 514（UDP）检测端口连通情况 → 确认是否存在防火墙、路由或安全策略限制 - 接收端检查：在远程服务器上执行
ss -tuln | grep :514，确认监听地址是0.0.0.0:514，而不是仅监听本地回环地址127.0.0.1:514
最容易被忽略的，往往是接收端的 bind 地址以及 SELinux 的 syslogd_port_t 上下文设置——即使端口已经开放，SELinux 仍然可能导致日志被静默丢弃，从而造成 Linux 远程日志同步失败。
