Syslog 协议：完整指南

Syslog 消息通过四种传输协议之一，从设备传输到集中式收集器或 syslog 服务器。UDP 传输大量遥测数据，但在负载高时会丢包。TCP 提供可靠的有序传输。TLS 在 TCP 之上增加了加密。RELP 更进一步，确认每条消息，确保在连接断开时不会丢失数据。

Syslog 协议比较

用户数据报协议 (UDP)

UDP是syslog的原始传输协议，与BSD syslog协议一起在RFC 3164中定义。现代消息格式规范RFC 5424废弃了RFC 3164，但通过RFC 5426中的单独传输映射保留了UDP兼容性。由于其低开销和最小的实现占用，UDP仍然是大多数网络设备的默认选择。UDP是无连接且无确认的，这使其轻量但也不可靠。

缺乏确认是核心权衡。UDP发送方向收集器发送消息时不建立会话，也不确认接收。当拥塞路由器丢弃数据包或队列满时丢弃数据包，发送方和收集器均不会收到通知，消息丢失。

因此，UDP不适合必须保存的日志数据。身份验证事件、数据库审计跟踪以及任何具有合规影响的日志源应使用可靠传输。

默认端口： UDP 514。有关syslog传输的完整端口参考，请参阅syslog port 514。

何时接受UDP

UDP在特定场景下仍然是合适的选择：

• 高流量网络设备遥测： 在高负载下，防火墙、路由器和交换机每秒可生成数千条syslog消息。UDP防止发送方因网络背压而阻塞。
• 本地网络收集： 在丢包率低的LAN段，收集器与源拓扑接近，UDP数据包丢失在实际中可忽略不计。
• 非关键操作日志： 调试跟踪和信息事件，偶尔丢失消息不会影响操作或取证结果。

使用UDP的局限性

• 负载下的无声丢包： UDP无拥塞控制。当交换机队列达到容量时，数据包被丢弃，发送方和收集器均无任何提示。
• MTU分片： 超过网络MTU的syslog消息在IP层被分片。任何单个分片丢失都会导致整个消息丢弃。
• 无交付保证： UDP不提供确认接收的机制。如果消息丢失会影响事后调查或合规报告，应使用TCP或RELP。

配置UDP syslog收集

在rsyslog中，启用UDP输入模块：

$ModLoad imudp
$UDPServerRun 514

在syslog-ng中，等效的source块如下：

source s_udp {
    udp(ip("0.0.0.0") port(514));
};

两种配置均监听默认UDP端口。仅当环境已将514保留给其他服务或syslog流量跨多个端口分段时，才修改端口。

传输控制协议 (TCP)

TCP作为syslog协议被引入以解决UDP的可靠性缺陷。定义于RFC 6587（通过TCP传输Syslog消息），它在发送方和收集器之间建立连接，按顺序传递消息，并重传传输层未确认的数据包。在大多数现代syslog部署中，TCP是默认选项。rsyslog和syslog-ng均优先支持基于TCP的收集。

TCP的面向会话特性意味着发送方能感知收集器不可达。连接重新建立后，本地缓冲区中的消息可重试，且会话内日志顺序端到端保持。

默认端口： TCP 514是历史默认；某些实现当严格遵循RFC 6587时使用端口601。

RFC 6587中的帧定界方法

与UDP中每条消息都是独立数据报不同，TCP传递连续字节流。为使接收方区分一条syslog消息与下一条，RFC 6587定义了两种帧定界方法：

• 字节计数帧定界： 每条消息前缀其字节长度，后跟空格，再后跟消息本身。这是可变长度消息的首选方法，尤其是遵循RFC 5424格式的消息，其结构化数据元素使消息长度不可预测，因为接收方准确知道每条消息的结束位置。
• 非透明帧定界： 消息由分隔符字符分隔，最常见的是换行符（\n）。此方法实现简单，但当消息中合法包含分隔符字符时会失败。

大多数现代收集器支持两者。配置不同厂商的发送方和接收方时，需确认两端帧定界方法一致。不匹配会导致消息被无声地拼接或拆分。

何时选择TCP

只要日志丢失会带来操作或合规后果，TCP都是合适的选择：

• 服务器和应用日志： 必须保留以支持事件响应的身份验证事件、数据库事务和应用错误。
• 合规驱动的日志收集： 任何受监管审计约束、期望完整日志交付证据的工作负载。
• 跨段收集： 当日志经过多个网络跳点，UDP的无声丢包会在每跳累积。

使用TCP的局限性

• 字节级保证，非消息级： TCP保证在活跃连接上有序字节传递。应用已发送至本地内核缓冲区但连接断开前未传输的消息仍可能丢失。
• 发送端缓冲很重要： rsyslog和syslog-ng提供可配置的磁盘辅助队列以在收集器宕机时保存消息。没有这些，长时间停机会导致事件丢失，尽管TCP在线路层可靠。
• 需要消息级保证时，请改用RELP。

配置TCP syslog收集

在rsyslog中，启用TCP输入模块：

$ModLoad imtcp
$InputTCPServerRun 514

在syslog-ng中，等效的source块如下：

source s_tcp {
    tcp(ip("0.0.0.0") port(514));
};

基于 TLS 的 Syslog（加密 syslog）

Syslog over TLS将标准TCP syslog会话封装在TLS加密隧道中，定义于RFC 5425（Syslog的TLS传输映射）。现代syslog消息格式规范RFC 5424要求合规实现至少使用TLS传输，RFC 5425详细定义了该映射。它提供了普通TCP不具备的三项属性：传输中消息内容的机密性、防篡改的完整性保护，以及使用X.509证书的发送方与收集器之间的相互认证。

TLS是大多数涉及跨不受信任网络传输日志数据的合规体系中要求的传输方式。PCI DSS明确要求对穿越公共网络的持卡人数据相关日志使用强加密。HIPAA安全规则对日志中引用的受保护健康信息也有类似要求。实际上，任何离开受控网络段的日志流量都应使用TLS。

默认端口： TCP 6514

权衡

• 证书管理： TLS 需要在收集器上安装证书，并且为了双向认证，每个发送端也需安装证书。证书的轮换、吊销和信任链管理增加了运维负担。
• CPU 消耗： TLS 握手和每会话加密对双方的 CPU 造成适度负担。对于每秒接收数万个消息的收集器来说，这种消耗是可测量的，但在现代硬件上很少成为瓶颈。
• 调试复杂性： 未获得会话密钥时，无法通过抓包查看加密流量，这增加了网络级故障排查的难度。

配置 TLS syslog 收集

在 rsyslog 上，通过加载 GnuTLS 网络流驱动并指向证书文件来启用 TLS：

$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile   /etc/ssl/ca.pem
$DefaultNetstreamDriverCertFile /etc/ssl/collector-cert.pem
$DefaultNetstreamDriverKeyFile  /etc/ssl/collector-key.pem

$ModLoad imtcp
$InputTCPServerStreamDriverMode 1
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerRun 6514

可靠事件日志协议 (RELP)

RELP 由 rsyslog 项目开发，用于解决基于 TCP 的 syslog 的特定缺陷：TCP 保证活跃连接上的字节传输，但连接断开时任何在传输中的消息都会丢失，且双方均不知情。RELP 弥补了这一缺陷。

RELP 在 TCP 之上运行，增加了应用层确认。每发送一条 syslog 消息，接收方都会返回确认，标识该特定消息。发送方维护会话状态，并在本地缓冲区保存未确认的消息。当连接中断后重新建立时，RELP 会重新发送之前会话中未确认的消息——无重复，无丢失。

实际区别：

• TCP 保证活跃连接上的字节传输。
• RELP 保证连接断开时消息的传递。

默认端口： TCP 2514

何时选择 RELP

在不允许消息丢失的环境中，RELP 的额外复杂性是值得的：

• 受监管行业： 金融服务、医疗保健和政府工作负载，每个事件都必须保留以供审计。
• 多跳 syslog 中继： 传递链中的每个额外中继都是 TCP 断开可能丢失传输中消息的节点。RELP 保证逐跳传递。
• 广域网链路： 跨越具有可变延迟和周期性断开的广域网的日志流量，受益于 RELP 的重连和恢复机制。

生态系统支持

RELP 在 rsyslog 中通过 imrelp 和 omrelp 模块原生支持。syslog-ng 后续添加了 RELP 支持，且在当前版本中可用。网络设备和第三方 syslog 发送器的支持不均衡——许多防火墙、交换机和旧版日志代理仍仅支持 UDP 和 TCP。设计基于 RELP 的收集架构前，请确认发送端支持 RELP。

配置 RELP syslog 收集

在发送端（rsyslog）：

$ModLoad omrelp
*.* :omrelp:collector.example.com:2514

在接收端（rsyslog）：

$ModLoad imrelp
$InputRELPServerRun 2514

如何选择 syslog 协议

决策通常取决于日志源、数据敏感性以及发送端与收集器之间的网络路径。

网络设备：防火墙、路由器、交换机

大多数网络硬件默认使用 UDP，且许多型号仍不支持其他协议。当收集器位于同一低丢包网络段时，使用 UDP。若厂商支持且日志数据用于安全调查而非仅运维监控，则使用 TCP。

服务器和应用日志

使用 TCP。现代 Linux 服务器运行 rsyslog 或 syslog-ng 时，TCP 的开销可忽略不计，而认证事件、应用错误和数据库活动的日志丢失在事件响应中代价巨大。

跨越不受信任网络的日志

使用 TLS。任何离开受控网络段的日志流量——数据中心间、云工作负载到本地收集器，或跨公共互联网——都应加密。纯 TCP 会暴露凭证数据、会话令牌和内部主机名给网络路径中的任何人。

合规约束的工作负载（PCI DSS、HIPAA、SOX、ISO 27001）

以 TLS 作为基础。若合规制度或内部控制框架要求可证明的消息级传递保证，则增加 RELP。TLS 负责保密性和完整性；RELP 负责传递保障。

多跳或广域网日志中继

使用 RELP。每个额外的中继跳点都会引入可能断开的连接，且纯 TCP 下每次断开都会无声丢失若干传输中消息。RELP 是唯一能跨重连保留消息的常用传输协议。

空气隔离或非关键本地日志

UDP 可接受。在流量低且日志内容非关键的隔离网络中，UDP 的开销优势超过 TCP 理论上的可靠性优势。

使用 EventLog Analyzer 应该选择哪个 syslog 协议？

产品支持所有四种协议，选择取决于发送端和日志数据的敏感性：

• UDP 514 应用于不支持其他协议的网络设备，以及受信任网络段上的非关键运维日志。
• TCP 514 是服务器和应用日志的默认推荐，适用于消息丢失不可接受的场景。
• TLS 6514 是 PCI DSS 要求 4（公共网络上持卡人数据相关日志的强加密）和 HIPAA 安全规则传输保护的强制要求，也是任何离开受控网络段的日志流量的正确选择。
• RELP 应用于合规控制或内部框架要求在连接断开时可证明消息级传递的场景。

EventLog Analyzer 如何收集 syslog

内置的 syslog 服务器同时监听 UDP 514、TCP 514 和 TLS 6514，无需单独的收集器或特定协议实例。设备继续使用其支持的传输方式发送数据，EventLog Analyzer 将接收的数据规范化为单一的解析和分析管道。自定义日志解析器处理厂商特定格式以及任何非开箱即用识别的人类可读日志结构。

用于威胁检测和合规性的 syslog 报告

收集后，来自仅支持 UDP 的网络设备、通过 TCP 连接的服务器和 TLS 加密的云工作负载的 syslog 消息会出现在统一的日志管理仪表板中。超过 1,000 个预定义报告涵盖最常见的 syslog 来源，关联引擎可检测跨日志来源的模式。

EventLog Analyzer 还提供针对 PCI DSS、HIPAA、SOX、ISO 27001、GDPR、FISMA、GLBA、GPG 13、ISLP 和 Cyber Essentials 的预定义合规报告。TLS 6514 收集确保传输中的日志数据符合加密要求。归档日志经过加密并保留以满足监管要求。

常见问题解答