rsyslog可靠日志传输需用TCP+磁盘队列或RELP协议：TCP配置@@地址、持久化队列与无限重试；RELP需加载imrelp/omrelp模块并监听指定端口；可选TLS加密增强安全；须通过断网测试、抓包及日志验证确认机制生效。
要让 rsyslog 实现可靠的日志传输确认机制，核心是避开 UDP 的无连接、无确认缺陷，改用具备重传、有序、确认特性的传输层或协议层方案。生产环境真正能提供“确认机制”的主流选择只有两种：TCP 基础确认 + 队列保障，以及 RELP（Reliable Event Logging Protocol）——它在 TCP 上封装了应用层 ACK，是 rsyslog 官方推荐的高可靠性方案。
启用 TCP 传输并配置持久化队列
TCP 本身提供三次握手、序列号、ACK 确认和重传，已比 UDP 可靠得多；但默认配置下，若网络瞬断或服务端不可达，rsyslog 可能丢弃日志。必须配合磁盘队列与失败重试策略才能构成完整确认闭环：
- 客户端配置中使用 @@（双@）表示 TCP 协议，例如：
*.* @@192.168.1.100:514 - 强制启用磁盘队列缓存未送达日志：
$ActionQueueFileName fwdRule1$ActionQueueMaxDiskSpace 1g$ActionQueueSaveOnShutdown on$ActionResumeRetryCount -1（无限重试，直到送达） - 确保服务端监听 TCP 514 端口，并防火墙放行：
firewall-cmd --permanent --add-port=514/tcp
部署 RELP 协议实现应用层确认
RELP 是专为日志设计的可靠协议，每条消息发送后必须收到服务端返回的 ACK 才算成功，丢失自动重发，且支持会话恢复，可靠性远超裸 TCP：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 服务端安装 RELP 支持：
yum install rsyslog-relp -y（CentOS/RHEL）或apt install rsyslog-relp -y（Debian/Ubuntu） - 服务端加载模块并监听 RELP 端口（如 20514）：
module(load="imrelp")input(type="imrelp" port="20514" ruleset="remote") - 客户端配置 RELP 输出：
*.* :omrelp:192.168.1.100:20514 - 重启两端 rsyslog 后，可通过
ss -tlnp | grep :20514验证监听状态
可选增强：TLS 加密 + 双向认证
仅靠 TCP 或 RELP 保证“送达”，不等于“安全送达”。如需防中间人窃听或伪造，应在上述任一可靠通道上叠加 TLS：
- 生成服务端证书和私钥（CA 签发或自签），配置
omfwd或omrelp的tls.参数 - 客户端指定 CA 证书路径，并启用
tls.authmode="x509/name"或"x509/fingerprint"校验服务端身份 - 注意：TLS 会增加 CPU 开销，建议搭配硬件加速或合理调整线程数
验证确认机制是否生效
光配不验等于没配。关键验证点有三个：
- 客户端执行
logger "test-reliable-$(date +%s)"，立即断开服务端网络，再恢复；稍等 10–30 秒后检查服务端对应日志文件是否完整收到该条 - 服务端用
journalctl -u rsyslog -f | grep relp或tcpdump -i any port 20514 -A抓包，观察是否有 ACK 包交互 - 查看客户端 rsyslog 日志：
tail /var/log/syslog | grep -i "queue\|fail\|retry"，确认无持续失败记录，且队列长度趋于 0
