syslog协议

RFC3164 - The BSD Syslog Protocol

文档状态

本文档提供了互联网委员会的信息。它不指定任何一种网络规范。对本文档的发布是不受限制的。

摘要

本文描述了syslog协议的实测行为。本协议在互联网上已经使用了很多年，是用来传送事件通知信息的。最初，这个协议在University of California Berkeley Software Distribution (BSD) TCP/IP系统实现中开发，它的实现和管理价值在于，它可以让不同系统相互通信，同时可以嵌入其他网络产品中。

目录

1. 概述

从一开始，生命依赖于信息的传递。对于有自我意识的有机物单位来说，这些信息可以传达很多信息。可能表示危险，食物或其他生命的必需品，以及其他东西。在很多情况下，这些信息被传递到其他个体中，不需要任何应答。和人类交流和创建的过程一样，这些简单的道理同样适用于社会联系。例如，严重的气象预报可能由很多频道同时播出，一场飓风的将保通过电视和电台以及船上的旗语同时传递。在大多数情况下，不对这些警告信息进行任何应答是需要的，或者是期望的。遵循同样的原则，操作系统，进程和应用程序都会发送自己状态的信息，或表示某种事件发生的信息。这些事件信息对于机器操作者通常是很重要的。当操作系统，进程和应用程序变得越来越复杂后，系统开始致力于将这些信息进行分来和日志记录，同时可以让操作人员更快速的从简单的状态信息中区分出问题的通知。Syslog进程是这种系统中被很多操作系统广泛接受的。这个进程的灵活性可以让操作人员配置发送从哪台机器的进程中发出。从一个方面来说，syslog进程接受到的信息可以保存在不同的文件中，同时在设备的控制台进行显示。从另一个方面来说，syslog进程可以通过配置将信息转发到网络中的另一台syslog进程中。Syslog进程对少量事件可以进行网络提醒，因为它知道很多系统操作员没有时间访问系统来查看注册在这里的信息。运行在远程设备上的Syslog进程，可以配置成为将信息加入文件中，或继续转发到其他机器中。

用最简单的话将，syslog协议提供了一种让机器通过IP网络将信息发送通知信息到事件接收器（syslog服务器）的功能。因为每一个进程，应用程序和操作系统是分开开发的，syslog 的信息的内容大多都是不同的。正因为这个原因，组成信息的内容没有任何假设。这个协议只是简单的传递这些信息。在任何情况下，有一个设备发出消息。那台机器上的Syslog进程可能将信息发送给收集器。不需要任何应答。

Syslog协议和进程的基本原则是它的简单性。在发送者和接收者之间不需要协调。实际上，syslog信息的发送者可以在接收者没有配置好或根本不存在的情况下进行发送。相反，很多设备会在没有任何配置和定义的情况下收到消息。这种简单性让syslog更容易接受和部署。

1.1. 事件和生成的消息

操作系统，进程和应用程序的编写者完全清楚他们将生成的事件。在某些情况下，生成消息用来说明状态。可以是一段时间一次，也可以由其他方式触发，例如在程序退出时。在其他情况下，消息是由遇到的条件产生的。在这些情况下，不管是状态消息或者包含一些类型的警告都可能被产生。操作系统、进程和应用程序的编写者可能会在详单中确定消息的数量。这些详单中通常包括发出消息的设备，同时包含消息的严重级别。这样，操作员可以有选择的筛选消息，可以更快的定位更加重要的和有处理时间限制的消息，同时可以将状态或消息信息放在文件中，将来阅读他们。其他显示和保存信息的方式也可以存在。

必须在设备中配置一些规则，这些规则可以告诉设备显示还是转发事件消息。这些规则是十分灵活的。管理员可能希望所有的信息都保存在本地，同时所有高优先级的消息都会转发到另一台设备中。他们可能发现，将某些设备的信息发送到一些或所有用户的设备中，同时显示在系统控制台上是很合适的。然而，管理员决定将事件信息发送到syslog收集器中，在收集器中包含了组成设备的信息以及发送的严重级别，同时定义了远程接收器。例如，系统管理员可能想让所有由邮件设备发出额消息被转发到一个特定的事件信息收集器中。管理员还可以让所有内核生成的事件信息被发送到另一台syslog接收器中，同时，将内核产生的critical 严重级别的消息发送到第三天设备中。同时，将显示在系统控制台中的信息email给部分用户，同时将他们保存在设备本地磁盘的文件中。反之，可以将本地进程产生的消息显示在控制台中，但不保存也不转发。所有事件的规则都在设备中生成。因为管理员知道收集器会收集到哪种类型的事件，他们会在syslog服务器中配置相应的规则。

消息的内容因创建者而异。建议将消息按照一定格式编写，这样人们就可以阅读他们。在消息中加入时间戳和发出消息的设备以及进程的标识符是一个很好的建议。但他们都不是必须的。

假设任何进程和设备都有可能产生事件消息。可能包含没有任何本地存储空间的设备，例如，打印机，路由器，集线器，交换机以及无盘工作站。在这种情况下，事件消息必须被发送到收集器中，同时必须别记录这样操作员就可以查看了。

1.2. 消息接收者的操作

定义当消息接收到之后如何处理超过了本文的范围。和1.1节的描述一样，他们通常展示被部分用户，保存在磁盘中，再次转发或是上述操作的组合。决定接收到消息如何处理的配置和本地生成消息如何处理的配置是同样的。

作为一个非常普遍的规则，通常是很多设备将消息发到相关的少数收集器中。这种扇入操作允许管理员在相关的少数仓库中汇总信息。

2. 传输层协议

Syslog使用用户数据报（UDP）作为底层传输层协议。Syslog的UDP端口为514。如果消息是由syslog进程发出，建议源端口也是514，不是514也是合法的。如果发送者使用比514大的端口号，那么建议接下来的其他消息也由这个端口发出。

3. 架构定义

本文中将使用如下定义：

l 生成消息的设备被称作“device”。

l 可以接收消息的设备又将消息转发给了其他设备，称作“relay”。

l 接收消息但不进行转发的设备称作“collector”。通常称作syslog服务器。

l 发出消息或转发消息的设备被称作“sender”。

l 任何接收消息的设备，包括转发或收集都称作“receiver”。

设备的架构可以分为以下几点：

1. 发送者发出消息时不知道接收者是collector还是relay。

2. 发送者可以配置成将同一个消息发送给多个接收者。

3. relay可以发送所有从上一个relay或collector收到的消息。某些情况下他们不转发所有信息，他们同时作为collector和relay。在下图中，一些设备被定义成relay。

4. relay可以生成自己的消息，同时将他们发送给下一个relay或collector。这种情况下，他们作为device。这些device同时被定义为下图中的relay。

图1中描述的架构在第一个知道最后一个的时候是合法的。这些例子的其他组都是可接受的。在下图中，所有的relay都可以透传一些或所有他们接收到的消息。

+------+ +---------+

|Device|---->----|Collector|

+------+ +---------+

+------+ +-----+ +---------+

|Device|---->----|Relay|---->----|Collector|

+------+ +-----+ +---------+