Syslog

关注
义项:系统日志协议标准
Syslog

Syslog是一种用于在网络中传递事件通知消息的标准协议,主要用途是把各类设备与程序产生的日志集中传送到日志服务器进行存储与分析[1]。它最初在20世纪80年代作为Sendmail项目的一部分被开发出来,此后逐步成为Unix和Linux系统上通用的日志记录方案[2]。目前其现行标准为2009年发布的RFC 5424,该文档取代了2001年的RFC 3164,并采用内容与传输分离的分层架构[3]。

百科 图文
目录
  1. 定义
  2. 原理
  3. 发展历程
  4. 应用
  5. 局限
  6. 参见

定义

Syslog是一种把事件通知消息从一台计算机系统传送到另一台计算机系统的正式规范,属于日志记录领域的通信标准[4]。它本身只规定消息的格式与传输方式,并不规定日志的存储格式,后者被认为超出协议范围,也不影响系统之间的互操作[1]。

在传送过程中,每台设备都可以作为消息的产生方,把日志发送给收集方,整个过程不需要发送端与接收端之间进行严格的协调[5]。消息中的设施值与严重级别值由互联网号码分配局(IANA)登记管理,设施值限定在0至23之间。

原理

现行标准把syslog划分为3个层次:syslog内容层承载消息中的管理信息,syslog应用层负责消息的生成、解释、路由和存储,syslog传输层负责把消息送入和取出传输链路[6]。这种分层设计的目的是把消息内容与传输方式解离开来,使每一层都能方便地扩展,从而避免为每一种传输方式重复编写代码[7]。

按功能划分,产生消息的实体称为产生方,收集消息以供进一步分析的实体称为收集方,从产生方或其他中继接收消息并转发的实体称为中继,另外还有与具体传输协议对接的传输发送方和传输接收方[1]。协议不提供消息送达确认,因此在概念上属于纯粹的单向通信[6]。

在RFC 5424规定的消息头中,优先级由设施与严重级别共同编码,计算方式为 $PRI = Facility \times 8 + Severity$[8]。设施共24种,用于区分消息来源,例如0号对应内核消息、4号对应安全与授权消息、16至23号留作本地自定义用途;严重级别共8级,从0级系统不可用一直到7级调试信息。

在传输方式上,syslog既可使用用户数据报协议,也可使用传输控制协议,还可在传输层安全协议之上运行[9]。由于TCP提供的是连续字节流,发送方需要在相邻消息之间进行分帧,RFC 6587给出了两种方法:一种是在每条消息前加上其字节长度,另一种是用换行符之类的分隔字符区分消息[10]。

发展历程

syslog在20世纪80年代由Eric Allman作为Sendmail项目的一部分开发,最初仅供Sendmail使用。由于它实用性较强,其他程序也陆续采用,后来逐渐成为Unix和Linux系统上的标准日志方案,在其他操作系统上也出现了多种实现[2]。该协议本身自1980年起即已在实际中使用,其发明一般被归功于Sendmail程序的作者[4]。

在较长一段时间里,syslog只是一种事实标准,没有权威的正式规范,各家实现之间甚至存在互不兼容的情况。为了提高安全性,互联网工程任务组成立了相关工作组;2001年,当时的实际状况被记录在RFC 3164中[2]。RFC 3164名为《BSD Syslog协议》,由C. Lonvick编写,于2001年8月发布,属于信息性文档,描述的是从实践中观察到的行为[3]。

2009年3月,R. Gerhards编写的RFC 5424发布,它取代了RFC 3164,成为现行标准轨道上的syslog定义[3]。与旧文档相比,RFC 5424只规定消息格式,传输方式被移入配套文档,由RFC 5426规定UDP传输映射、RFC 5425规定TLS传输映射[11]。

应用

syslog的典型用途是把分散的日志汇聚到集中式服务器,便于监控与分析,在系统管理、安全审计和故障排查中均有使用。较常见的场景包括追踪网络设备的接口状态变化、路由更新和防火墙命中记录,以及监控服务器上的磁盘空间、处理器负载、服务故障和用户登录情况[8]。

设施与严重级别的划分方便了日志的路由与存储策略,例如把认证日志交给安全团队、把内核日志交给系统管理员、把防火墙事件交给安全信息与事件管理系统[8]。在Android等系统中,内核和系统守护进程也沿用syslog风格的日志方式[12]。

在实际部署中,不同传输方式各有取舍。UDP以端口514为历史默认,开销最低,但不建立会话也不确认接收,队列溢出或拥塞时数据包会被静默丢弃,发送方与收集方都得不到提示;TCP在字节层面保证有序传输;TLS在端口6514上提供加密与对端认证;RELP则在会话层提供消息级确认[9]。由于旧式明文传输缺乏保障,跨信任边界或涉及受监管数据的日志通常改用加密传输[13]。

局限

协议本身不提供送达确认,所以丢失消息时发送端可能无从知晓,概念上它只是一种单向通信[6]。以UDP作为承载方式时这一问题尤为明显:该协议无连接、无确认,也无拥塞控制,当交换设备队列达到容量时数据包被丢弃,发送方和收集方都不会收到任何提示;超过网络最大传输单元的消息会在IP层被分片,只要丢失一个分片,整条消息就会作废[9]。

改用TCP只能提供字节级的可靠性,而非消息级的可靠性:连接中断时,已经由应用交给本机内核缓冲区、但尚未发送出去的消息仍可能丢失,因此需要在发送端配置可落盘的队列,在收集方不可用期间暂存消息[10]。

TLS可以解决机密性、完整性和对端身份认证问题,但对可用性没有帮助,仍需依靠发送端的磁盘队列和收集端的故障转移目标来应对中断[13]。启用TLS还会带来额外代价:证书的签发与轮换增加了运维工作,握手和加密带来一定的处理器开销,而且加密流量在没有会话密钥时无法直接通过抓包分析,增加了网络层面的排查难度[10]。此外,RFC 3164规定的旧式格式没有年份和时区,只支持可打印ASCII字符,字符编码、消息长度等方面的限制也使其在新场景中逐渐被RFC 5424格式取代[11]。

参见

参考资料

  1. RFC 5424: The Syslog Protocol [引用日期2026-10-14]
  2. Syslog [引用日期2026-10-14]
  3. RFC Search Detail [引用日期2026-10-14]
  4. Overview of syslog protocol [引用日期2026-10-14]
  5. RFC 3164: The BSD Syslog Protocol [引用日期2026-10-14]
  6. RFC 5424: The Syslog Protocol [引用日期2026-10-14]
  7. RFC5424 - The Syslog Protocol (SYSLOG) [引用日期2026-10-14]
  8. syslog-basics-logging [引用日期2026-10-14]
  9. Syslog 协议:完整指南 [引用日期2026-10-14]
  10. Syslog Protocols: A Complete Guide [引用日期2026-10-14]
  11. what-is-syslog [引用日期2026-10-14]
  12. content [引用日期2026-10-14]
  13. syslog-forwarding-over-tls [引用日期2026-10-14]
词条评价
词条统计

浏览次数:2 次

阅读量:0 次 · 阅读完成量:0 次

最近更新:2026-10-13T21:59:28Z

历史版本

本条目引用的词条
互联网号码分配局 Eric Allman 互联网工程任务组 用户数据报协议 传输控制协议 传输层安全协议 安全信息与事件管理