rsyslog

定义

rsyslog 是一款开源的系统日志处理软件，运行于类 Unix 操作系统之上，用途是在 IP 网络中收集、加工和转发日志消息^[1]。它以守护进程的形式在后台持续运行，实现基本的 syslog 协议，并在此基础上扩展出基于内容的过滤、队列操作以及多种输出模块等功能^[1]。

与只做简单记录的传统工具相比，rsyslog 既能向下兼容原有配置文件格式，充当 sysklogd 的直接替代品，又被定位为通用的日志处理管道引擎^[3]。Debian 等发行版将其描述为「可靠的系统和内核日志守护进程」，并把它作为系统默认的 syslogd 使用^[2]。

原理

rsyslog 的处理流程被称为日志管道，由输入、规则集、动作和队列 4 个环节构成：输入负责接收数据，规则集负责过滤与转换，动作负责投递处理结果，队列在各环节之间缓冲消息^[4]。输入模块的名称以 im 开头，例如读取本地套接字的 imuxsock、对接 systemd 日志的 imjournal、监听网络的 imudp 与 imtcp，以及跟踪文本文件的 imfile^[4]。

规则集内部由条件判断和动作组成，可以调用 mmjsonparse、mmnormalize 等模块对消息做解析与规范化，再用动作把结果写出^[4]。动作默认按配置中出现的先后顺序串行执行，前一个动作可以修改甚至丢弃消息^[5]。

队列是连接各环节的机制，分为直接队列、链表队列和固定数组队列 3 种；链表队列可以选择配合磁盘缓冲，在目标不可达时把消息暂存到磁盘，从而避免丢失^[4]。每个输入、规则集或动作都可以拥有独立队列，为它们分配独立的工作线程。

消息本身沿用 BSD syslog 协议，该协议在 RFC 3164 中描述，包头由 PRI、HEADER 和 MSG 三部分组成^[6]。rsyslog 在此之上补充了带毫秒与时区信息的 ISO 8601 时间戳、可用于追踪转发路径的主机字段、TCP 传输、TLS 与 GSS-API 加密，以及对 RFC 5424、RFC 5425、RFC 5426 和 RELP 的支持^[1]。配置可使用名为 RainerScript 的脚本式语言书写，条件表达式形如 if ($programname == "sshd") then { ... }，在满足条件时执行后续动作^[5]。

发展历程

rsyslog 的源头可追溯到 1983 年的 BSD syslogd，它带来了设施与优先级路由、统一的日志服务以及稳定的消息格式，此后 Linux 采用 sysklogd 提供兼容的日志功能，但其传输不可靠、过滤能力有限且架构不具备模块化特性^[7]。2004 年，Rainer Gerhards 从 sysklogd 分支出 rsyslog 项目，目标是提供功能更丰富且具备可靠传输能力的日志守护进程，同时保持对原有 syslogd 的替代兼容性^[8]。

项目名称取自对 syslog-reliable 的支持计划，但早期版本并未实现该协议，也未支持基于 TCP 的日志传输，而是先加入了更强的可配置性和数据库写入能力；0.9.2 版开始支持通过普通 TCP 接收日志，1.11.0 版才在接收端实现了 RFC 3195^[9]。

2007 年，红帽公司的 Peter Vrabec 协助制作了 Fedora 的 RPM 包并加入 IPv6 支持，同年 11 月 Fedora 8 将 rsyslog 选为默认日志守护进程，项目 wiki 也在 8 月上线^[8]。2008 年是技术转折点：1 月 31 日发布的多线程队列引擎带来了并行处理与磁盘缓冲能力，2 月 28 日发布的 3.12.0 版首次引入 RainerScript 表达式支持^[10]。

到 2010 年前后，输入与输出模块的命名规范、JSON 模板结构化日志以及输入、规则集、队列与动作的分离已经成型^[10]。2014 年左右，rsyslog 在通用硬件上达到每秒数十万至近百万条消息的处理能力，并完善了 Elasticsearch 与 Kafka 输出模块；2018 年前后它进一步被用作通用事件管道引擎，而不只是 syslog 守护进程^[10]。

应用

rsyslog 被多个 Linux 发行版和 Unix 系统采用。Debian 自 5.0 版起用它取代 syslogd 与 klogd 作为默认的系统与内核日志守护进程^[11]。Fedora 从 8 版起将其设为默认，openSUSE 自 11.2 版起采用，红帽企业版 Linux 自第 5 版开始内置，SUSE Linux Enterprise Server 自 11 SP2 起以 rsyslog 替换 syslog-ng，此外它还提供 Solaris、FreeBSD、NetBSD、Gentoo 和 Arch Linux 等平台的支持^[11]。

在实际部署中，rsyslog 既可以作为单机日志收集器，把本地消息按设施和优先级写入不同日志文件，也可以作为中心服务器接收来自网络设备的日志，或作为中继节点把日志继续转发出去^[2]。它支持通过 RELP、TCP、TLS 等方式可靠传输，支持按需磁盘缓冲、电子邮件报警、发送者列表权限控制、故障时输出到备用位置，以及把日志写入 MySQL、PostgreSQL、MongoDB 等数据库^[2][12]。

在容器与可观测性场景中，rsyslog 可作为日志管道对接 Elasticsearch、Apache Kafka、Grafana Loki、Splunk HTTP 事件收集器等目标，并通过 imdocker、mmkubernetes 等模块读取容器与 Kubernetes 元数据^[13][12]。发行版通常以插件包的形式提供这些功能，例如 rsyslog-mysql、rsyslog-pgsql、rsyslog-kafka、rsyslog-elasticsearch、rsyslog-relp 等^[2]。

局限

rsyslog 的可靠性依赖所选的传输方式。原始 syslog 协议推荐使用 UDP，RFC 3164 规定单条消息长度不超过 1024 字节，该方式不存在发送者身份验证，消息可能被伪造、重放、丢失、乱序或损坏，也没有基于严重级别的优先级处理^[6]。使用 TCP 传输虽然避免了部分问题，但在应用层仍缺少确认机制，发送端的成功返回只表示数据已写入本地套接字缓冲区^[6]。

RFC 3195 所定义的 BEEP 传输虽提供可靠投递，但因开销较大、与后续标准兼容性不足，实践中很少被采用，rsyslog 至今也只在接收端支持它^[6]。用于弥补应用层可靠性的 RELP 协议并非 IETF 标准，目前实现它的库不多，选择集中式日志服务器时余地有限^[6]。

性能与可靠性之间也存在取舍。把日志写入数据库可能无法应对每秒数千条以上的消息量，因为数据库本身难以提供足够性能^[8]。开启每条写入后同步文件的功能会降低吞吐，因此默认并不启用^[14]。此外，TLS 只提供逐跳安全，经过中继的消息仍需自行判断其来源是否可信^[6]。在配置层面，动作按顺序串行执行，若某个目标不可达且该动作没有配置队列，消息会反复重试，短时间内表现为停滞^[5]。

参见

• syslog —— rsyslog 所实现并扩展的日志消息协议与标准体系。

• syslog-ng —— 另一款功能相近的 syslog 守护进程，rsyslog 在 2004 年出现时将其视为主要竞品。

• systemd —— 其日志组件 journald 与 rsyslog 通过 imjournal 模块对接，部分发行版已改用 journald 承担默认日志记录。

• RELP —— 随 rsyslog 工具集发展起来的可靠事件日志传输协议。

• Apache Kafka —— rsyslog 可通过 omkafka 模块向其写入日志消息。

• Elasticsearch —— rsyslog 可通过 omelasticsearch 模块将日志投递至其中。