📚 课程目录第3章 rsyslog核心架构

3. rsyslog 核心架构：模块化设计、输入/输出/解析模块、队列与多线程模型

rsyslog 是 Linux 系统中最主流的日志收集与转发守护进程，其设计哲学围绕高性能、高可靠性与可扩展性展开。理解 rsyslog 的核心架构，是配置远程日志收集与排查故障的基础。本章将深入剖析其模块化设计、输入/输出/解析模块、队列机制与多线程模型。

3.1 模块化设计：插件驱动的日志管道

rsyslog 摒弃了单体架构，采用插件化设计。核心引擎仅负责消息路由与调度，所有具体的 I/O 操作、数据解析、格式化与输出均由独立的模块完成。这种设计带来了极高的灵活性：用户可以根据需求加载必要的模块，避免资源浪费，并能够轻松扩展对新协议或数据源的支持。

  核心优势：
  按需加载： 仅加载所需模块，降低内存占用与启动时间。
功能隔离： 单个模块的故障（如输出模块阻塞）不会直接导致整个引擎崩溃。
生态丰富： 社区与厂商可以独立开发模块，支持从传统 syslog 到 JSON、Kafka、Elasticsearch 等多种格式与目标。

模块通过 rsyslog.conf 中的 module(load="模块名") 指令加载。模块内部通常包含一个或多个插件，例如 imuxsock 模块提供 imuxsock 输入插件。

3.2 输入模块：日志的入口

输入模块负责从各种数据源接收原始日志消息。它们是日志管道的起点，决定了 rsyslog 能够处理哪些类型的日志源。

模块名称	插件名	功能描述	典型场景
imuxsock	imuxsock	从本地 Unix Socket（/dev/log）读取日志	接收本地应用程序通过 syslog() 函数发送的日志
imklog	imklog	从内核日志缓冲区（/proc/kmsg）读取日志	收集内核产生的所有日志消息
imtcp	imtcp	通过 TCP 协议接收远程 syslog 消息	可靠地收集远程设备或服务器的日志
imudp	imudp	通过 UDP 协议接收远程 syslog 消息	快速、低开销地收集大量远程日志（允许丢包）
imrelp	imrelp	通过 RELP 协议接收远程日志	需要可靠传输且支持应用层确认的场景
imfile	imfile	监控并读取文本文件（如 Apache/Nginx 访问日志）	将非 syslog 格式的应用程序日志纳入 rsyslog 管理

配置示例： 加载 TCP 输入模块并监听 514 端口。

module(load="imtcp")
input(type="imtcp" port="514")

3.3 解析模块：消息的格式化

原始日志消息通常是纯文本字符串。解析模块（Parser Module）负责将这些字符串分解为结构化的键值对，如 timestamp、hostname、facility、severity、msg 等。rsyslog 内置了多种解析器，也支持自定义。

pmrfc3164： 解析传统的 BSD syslog 格式（RFC 3164）。这是最常用的解析器，兼容性最好。
pmrfc5424： 解析新的 IETF syslog 格式（RFC 5424）。支持结构化数据（SD-ELEMENT），格式更规范。
pmlastmsg： 一个简单的“最后消息”解析器，用于性能测试或特殊场景。
pmnull： 不进行任何解析，将整条消息作为 msg 字段保留。

故障排查要点： 如果远程日志显示的时间、主机名或严重级别不正确，90% 的原因是解析器选择错误或解析规则不匹配。例如，发送方使用 RFC 5424 格式，但接收方配置了 RFC 3164 解析器，会导致字段错位。

3.4 输出模块：日志的目的地

输出模块将经过解析和过滤后的日志消息写入到最终目标。这是日志管道的终点，决定了日志的存储、转发或索引方式。

模块名称	插件名	功能描述	典型场景
omfile	omfile	将日志写入本地文件	标准本地日志存储（/var/log/messages）
omfwd	omfwd	将日志转发到远程 syslog 服务器	集中式日志收集（UDP/TCP/RELP）
omelasticsearch	omelasticsearch	将日志直接写入 Elasticsearch 集群	构建日志分析平台（ELK Stack）
omkafka	omkafka	将日志发布到 Apache Kafka 主题	构建高吞吐量日志流处理管道
ommysql	ommysql	将日志写入 MySQL/MariaDB 数据库	需要结构化存储与 SQL 查询的场景

3.5 队列与多线程模型：高性能的基石

rsyslog 的高性能核心在于其异步队列与多线程模型。消息从输入模块进入后，不会立即被输出模块处理，而是先放入一个或多个队列中，由工作线程池异步消费。

3.5.1 队列类型

rsyslog 支持三种主要的队列类型，通过 $MainMsgQueueType 或 queue.type 参数配置。

队列类型	参数值	特点	适用场景
Direct	Direct	无队列，输入线程直接调用输出模块。阻塞时会导致输入阻塞。	调试、低负载、对实时性要求极高的场景。
LinkedList	LinkedList	基于内存的链表队列。入队快，出队由工作线程处理。支持多线程。	大多数通用场景，性能与可靠性的平衡选择。
FixedArray	FixedArray	基于固定大小数组的队列。入队出队速度极快，但队列满时会阻塞。	高吞吐量、对延迟敏感、队列大小可预测的场景。
Disk	Disk	基于磁盘文件的队列。数据持久化到磁盘，防止内存溢出或进程崩溃丢失。	高可靠性场景，如金融交易日志、审计日志。

3.5.2 多线程模型

rsyslog 使用生产者-消费者模型。输入模块（生产者）将消息放入主队列，一个或多个工作线程（消费者）从队列中取出消息，执行过滤、解析和输出操作。

主队列（Main Queue）： 所有输入消息首先进入的全局队列。
动作队列（Action Queue）： 每个输出动作（如写入文件、转发到远程）可以拥有独立的队列，实现动作级别的隔离与并发。
工作线程数： 通过 $MainMsgQueueWorkerThreads 或 queue.workerThreads 配置。增加工作线程数可以提升多核 CPU 的利用率，但过多的线程会导致上下文切换开销。

3.5.3 队列配置实战

以下是一个典型的队列配置示例，展示了如何为主队列和动作队列设置参数以优化性能与可靠性。

# 主队列配置：使用 LinkedList，4 个工作线程，队列最大 100000 条
global(
    queue.type="LinkedList"
    queue.workerThreads="4"
    queue.size="100000"
    queue.dequeueBatchSize="16"
)

# 动作队列配置：为转发到远程服务器的动作启用独立队列
action(
    type="omfwd"
    target="192.168.1.100"
    port="514"
    protocol="tcp"
    queue.type="LinkedList"
    queue.workerThreads="2"
    queue.size="50000"
    queue.highWatermark="40000"
    queue.lowWatermark="10000"
)

  性能调优建议：
  高吞吐量场景： 使用 FixedArray 队列，并适当增加 queue.dequeueBatchSize（如 32 或 64）以减少锁竞争。
高可靠性场景： 使用 Disk 队列，并设置 queue.saveOnShutdown="on" 确保进程退出时数据不丢失。
避免队列溢出： 监控 rsyslogd 的日志，如果出现 queue full 或 discarding message 的警告，需要增大 queue.size 或增加工作线程数。