排查rsyslog高并发日志丢失，需先确认日志是否真丢失还是未达预期位置；通过logger测试+journalctl和messages比对定位环节；检查imuxsock缓冲、输出队列、网络连通性及规则过滤。
排查 rsyslog 在高并发下的日志丢失，核心是确认“日志是否真丢了”，还是“只是没落到预期位置”。很多所谓“丢失”，其实是日志被丢弃、卡在队列、写入失败或被过滤了，而非彻底消失。
先确认日志是否真的没产生
高并发场景下，日志丢失常始于源头。用 logger 主动注入测试消息，验证整个链路是否通畅：
- 执行 logger "test-$(date +%s)" 发送一条带时间戳的日志
- 立刻查 journalctl -n 5 --no-pager | grep test —— 看 journald 是否收到
- 再查 tail -n 5 /var/log/messages | grep test —— 看 rsyslog 是否落地
如果 journalctl 能看到但 /var/log/messages 没有，说明问题出在 rsyslog 的接收或写入环节；如果 journalctl 都没记录，就要检查 /dev/log socket 是否正常（ls -l /dev/log 应为 srw-rw-rw-），或 systemd-journald 是否异常。
检查 rsyslog 输入模块与缓冲能力
rsyslog 默认使用 imuxsock 接收本地日志，它依赖内存缓冲。高并发时若缓冲区太小，新日志会直接丢弃（不报错）：
- 查看当前配置中是否启用并调优 imuxsock：grep -A5 "imuxsock" /etc/rsyslog.conf /etc/rsyslog.d/*.conf
- 关键参数应包含：
$SystemMaxMessageSize 64k（避免大日志截断）
$IMUXSockRateLimitInterval 0（关闭速率限制，或设为合理值如 10）
$IMUXSockRateLimitBurst 200（每秒允许突发 200 条） - 修改后必须重载：systemctl reload rsyslog（非 restart，避免中断）
定位输出端瓶颈：队列与远程转发
日志丢失最常见于输出阶段——尤其是转发到远程服务器时网络抖动或目标不可达，rsyslog 默认会丢弃无法发送的日志（除非显式配置队列）：
- 检查配置中是否有 action(type="omfwd" 类规则，并确认是否启用磁盘队列：
$ActionQueueType LinkedList
$ActionQueueFileName fwdq
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on - 查看队列状态：rsyslogd -d 2>&1 | grep -i queue 或观察 /var/lib/rsyslog/ 下是否有 fwdq* 文件生成
- 用 netstat -tnp | grep :514 和 telnet remote-syslog 514 验证连通性
验证规则是否意外过滤或静默丢弃
高并发下，某些模糊匹配或条件判断可能因性能原因被跳过，或触发隐式丢弃规则：
- 临时注释掉所有 if $programname == ... then ... 类条件路由规则，只保留基础写入（如 *.* /var/log/messages），观察是否还丢
- 检查是否有 stop 或 ~（discard）操作被误加在通用规则前
- 开启调试日志快速定位：
在 /etc/rsyslog.conf 顶部添加
$DebugFile /var/log/rsyslog-debug.log
$DebugLevel 2
然后 systemctl restart rsyslog，复现后查 debug 日志中是否有 dropped、discarded、rate limited 等关键词
