rsyslog 不适用于百万级节点集中日志采集，仅可作为边缘层轻量代理；需分层解耦，由kafka等中间件承担核心转发与缓冲，rsyslog须限于单机或小规模汇聚，并启用异步队列、relp、tls及严格连接限制。
直接说结论：rsyslog 本身不适用于百万级节点的集中化日志采集，它不是为这种规模设计的。强行用单层或简单多层 rsyslog 转发会迅速遇到性能瓶颈、连接数溢出、丢包率飙升、模板解析延迟、磁盘 I/O 崩溃等问题。真正的百万级架构必须分层解耦，rsyslog 只能承担其中某一级的轻量角色（如边缘汇聚），不能做核心枢纽。
为什么 rsyslog 不适合百万节点直连或浅层转发
rsyslog 的 TCP 连接模型是每个客户端独占一个 socket，百万并发连接意味着百万级 file descriptor 占用和内核调度压力；UDP 虽无连接，但缺乏流控与重传，网络抖动下丢包不可控；其单进程/多线程模型在高吞吐下易成瓶颈；日志落盘若未配异步写+轮转+压缩，磁盘将率先打满；默认模板引擎在每条日志都做字符串解析时 CPU 消耗陡增。
可行的多层级架构中 rsyslog 的准确定位
在可落地的百万级方案里，rsyslog 应被限制在最前端——作为“边缘日志代理”，只负责本机或同机房少量主机的日志收拢与初步过滤，再交由更健壮的中间件接力：
-
第1层（边缘层）：每台服务器或每 10–50 台同网段主机部署本地 rsyslog，启用 imudp + imtcp，仅收集 auth、kern、messages 等关键设施，用
if $programname == 'nginx' then @@...做粗粒度过滤，转发至本区域汇聚节点（非中心） - 第2层（区域汇聚层）：使用 Kafka 或 Fluentd 集群接收边缘层数据，完成协议统一（RFC5424）、字段标准化、分区分片、缓冲削峰；rsyslog 在此层不参与，仅作为 Kafka 的可选输入插件（需加载 omkafka 模块）
- 第3层（中心处理层）：Logstash/Flink/自研解析器消费 Kafka Topic，做字段提取、敏感信息脱敏、指标聚合；结果写入 Elasticsearch 或对象存储；rsyslog 完全退出该层
-
补充说明：若必须用 rsyslog 承担第2层，须搭配 relp 协议（可靠事件日志协议）+ disk-assisted queue + TLS 加密，并严格限制每实例最大连接数（
$InputTCPServerStreamDriverMode 1+$InputTCPServerConnectionLimit 1000），单节点上限建议不超 5000 节点
边缘层 rsyslog 必须启用的关键配置项
若你已在第1层使用 rsyslog，以下配置是稳定运行的基础（以 CentOS/RHEL 8+ 为例）：
- 加载模块：
module(load="imudp") module(load="imtcp") module(load="omrelp") - 限流与队列：
$ActionQueueFileName fwdq; $ActionQueueMaxDiskSpace 2g; $ActionQueueSaveOnShutdown on; $ActionResumeRetryCount -1 - 安全加固：
$DefaultNetstreamDriver gtls; $DefaultNetstreamDriverCAFile /etc/pki/tls/certs/ca.pem; $DefaultNetstreamDriverCertFile /etc/pki/tls/certs/client.crt; $DefaultNetstreamDriverKeyFile /etc/pki/tls/private/client.key - 转发规则（Reliable）：
*.* :omrelp:10.10.20.5:20514;RSYSLOG_ForwardFormat（目标为第2层 Kafka-Relay 节点） - 关闭冗余功能：
$OmitLocalLogging on; $IMJournalStateFile /var/lib/rsyslog/journal.state
验证与可观测性不能依赖默认方式
百万级下传统 tail -f /var/log/messages 或 rsyslogd -N1 无法反映真实链路状态：
- 用
rsyslogd -d抓取启动时初始化日志，确认模块加载无 warning - 监控
/proc/sys/net/core/somaxconn和/proc/sys/fs/file-nr，防止连接队列溢出或句柄耗尽 - 在边缘节点部署轻量 exporter（如 rsyslog_exporter），暴露
rsyslog_queue_length、rsyslog_forward_failures_total等指标到 Prometheus - 定期抽样比对：从某台源主机写入一条带唯一 trace_id 的测试日志，检查是否在第2层 Kafka 中对应 partition 出现且时间戳偏差
不复杂但容易忽略：百万级成败不在转发协议本身，而在于每一层的容量规划、失败降级策略（如本地磁盘缓存 fallback）、以及日志生命周期管理（保留策略、冷热分离）。rsyslog 是把好刀，但不能拿它去建摩天大楼的地基。
