Rsyslog主队列阻塞问题分析与解决方案

问题现象

在RHEL 8.10系统上运行的Rsyslog 8.2102.0版本出现了一个典型问题：服务启动后约30秒即停止写入日志文件。系统管理员观察到增加CPU核心数（从4核提升至16核）能暂时缓解问题，但无法从根本上解决问题。

根本原因分析

经过深入排查，发现问题根源在于Rsyslog的队列处理机制。具体表现为：

1. TCP转发目标不可达：配置中存在多个使用TCP协议转发日志到外部设备的action
2. 队列阻塞链式反应：当目标设备不可达时，action队列会持续积压
3. 主队列级联阻塞：action队列填满后，会反向阻塞主队列(main_queue)的处理

技术原理详解

Rsyslog的队列处理机制采用生产者-消费者模型：

1. 主队列：接收所有输入源的日志消息
2. Action队列：每个输出动作(action)都有自己的队列
3. 阻塞传播：当下游队列(如action队列)无法及时消费时，会通过背压机制影响上游队列

在默认配置下，当action队列因目标不可达而填满时，会阻塞主队列的消息处理，导致整个日志收集系统停滞。

解决方案与最佳实践

1. 紧急恢复措施

• 检查并修复TCP转发目标的连通性
• 临时禁用故障的转发规则

2. 配置优化建议

# 主队列配置优化
main_queue(
    queue.type="LinkedList"
    queue.size="200000"
    queue.workerthreads="8"
    queue.dequeuebatchsize="1000"
    queue.maxdiskspace="2g"
    queue.saveonshutdown="on"
    queue.filename="mainqueue"
)

# Action队列独立配置
action(
    type="omfwd"
    target="remote-server"
    port="514"
    protocol="tcp"
    queue.type="LinkedList"
    queue.size="10000"
    queue.maxdiskspace="1g"
    queue.discardmark="9750"  # 达到97.5%容量时开始丢弃
    queue.highwatermark="9000"
    queue.lowwatermark="2000"
    queue.timeoutenqueue="5000"  # 5秒入队超时
    queue.discardseverity="5"   # 丢弃notice级别以下消息
    action.resumeinterval="30"  # 30秒后重试
)

3. 监控体系建设

建议配置impstats模块实现系统自监控：

module(load="impstats" interval="60" severity="7")
ruleset(name="monitoring") {
    action(
        type="omfwd"
        target="monitoring-server"
        port="514"
        protocol="udp"
        queue.type="LinkedList"
        queue.size="5000"
    )
}

预防性措施

1. 网络隔离：关键转发目标应配置双机热备
2. 分级存储：重要日志与普通日志分离处理
3. 容量规划：根据业务量合理设置队列大小
4. 告警机制：对队列积压情况设置阈值告警

总结

Rsyslog作为企业级日志收集系统，其队列处理机制既保证了可靠性，也带来了潜在的级联阻塞风险。通过合理的队列配置、完善的监控体系和预防性措施，可以有效避免类似问题的发生，确保日志系统的稳定运行。建议管理员定期审查转发目标的可用性，并对关键业务日志配置独立的处理通道。