1. 简述
该文章参考rfc5424，并对其内容进行了简练。
可能有的同学还使用过BSD Style 的syslog格式，这种格式定义在[RFC3164]中，这种格式使用很广泛，但是没有严格的格式定义，每个平台定义都不一样，是一种过时的格式。有兴趣的可以了解一下。
在开始之前，有必要简单解释下什么是syslog。做过linux开发和运维的同学肯定经常使用syslog。syslog是一个协议，协议规定了什么呢？syslog用于传送事件通知消息。该协议允许使用多种传输协议去发送syslog消息。它还允许供应商以结构化的方式扩展消息格式。
另外可能没有接触过syslog的同学，首次读该文章会有一些不理解的地方，但是请不要去抠字眼和陷进去，你应该往后继续看，慢慢就会理解的。
2. syslog定义
rfc5424规定syslog是一个分层架构，它有以下三层：
- "syslog content" syslog消息内容
- "syslog application" 该层负责syslog的生成，解析，路由，和存储syslog
- "syslog transport" 该层为消息的传输层
syslog有以下几个概念上的分层：
- ”originator" 生成syslog内容携带一个消息
- “collector" 收集syslog内容
- ”relay" 转发消息，从originator层或者其他的relay层接收消息并把转发到collector层或者其他relay层
- "transport sender" 传递syslog消息到特定的传输协议
- "transport receiver" 获取syslog消息从特定的传输协议
下图显示了按层分隔的不同实体 +---------------------+ +---------------------+ | content | | content | |---------------------| |---------------------| | syslog application | | syslog application | (originator, | | | | collector, relay) |---------------------| |---------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +---------------------+ +---------------------+ ^ ^ | | --------------------------
3. 基本原则
syslog通信需要遵循以下原则:
- syslog协议不提供消息投递确认机制。尽管一些传输协议提供状态信息，概念上，syslog是一个简单的单工通信协议
- originator和relay可以把相同的消息发送到多个collector和relay
- originator, relay和collector可能驻留在同一个系统
3.1 部署场景例子
部署场景例子如下图所示，正如图所示，relay可以发送全部或者部分他们收到的消息，也可以发送他们内部生成的消息。
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
4. 传输层协议
rfc5424没有定义任何的传输层协议。但是它以独立于传输层的方式描述syslog消息的格式 ，syslog的传输层协议定义在别的rfc文件中，比如在[RFC5426]中定义了一种与传统的UDP传输一致的协议，想要了解的可以去看一下。
4.1 传输层最小需求
此规范的所有实现必须支持基于tls的协议 如[RFC5425]所述。
该规范的所有实现也应该支持[RFC5426]中描述的基于udp的传输。
建议该规范的部署使用基于TLS的运输。
5. Syslog消息格式
syslog消息有如下ABNF [RFC5234]定义:
注：ABNF是一种格式说明语言，可以简单了解下，下面ABNF说明里包含了很多ABNF中定义的字符，你可以参照 ABNF [RFC5234]的定义了解对应的字符
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; range 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; not starting with BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; UTF-8 string as specified
; in RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
5.1 消息长度
syslog消息长度限制由使用的传输映射层决定。本质上没有上限。每一个传输映射定义了所需的最小最大消息长度支持，且最小最大值必须至少480字节长。
5.2 HEADER
header中使用的字符集必须是7位ascii码，下面我们对header字段中包含的每个字段进行单独解释
5.2.1 PRI
PRI由尖括号括起来的，尖括号里是1到3个十进制数字。这个十进制数字我们成为优先级值(PRIVAL), 这个值是计算出来的，可以表示出两个字段：设施(Facility)和严重性(Severity),
设施和严重性的值不是标准值，但是经常使用。下表描述了设施值得信息，设施值必须在0到23(包括)的范围内。
Numerical Facility
Code
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon (note 2)
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
Table 1. Syslog Message Facilities
下表将对严重性级别及其数值进行说明。严重性值必须在0到7(包括)的范围内。
Numerical Severity
Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
Table 2. Syslog Message Severities
优先级值是由设施值和严重性值计算出来的，计算算法为（Facility * 8） + Severity 例如 Facility = 20 且Severity =5，则优先级值为165。把这个值使用尖括号括起来就是PRI的内容了: <165>
5.2.2 VERSION
VERSION字段表示syslog协议规范的版本,如果修改了HEADER格式的任意部分，则该版本号就必须增加，rfc5424规范定义的版本是“1”
5.2.3 TIMESTAMP
TIMESTAMP字段是一个形式化的时间戳,定义在[RFC3339].
然而[RFC3339]允许多种语法，syslog协议做了了进一步的限制。TIMESTAMP值必须遵循这些限制:
- 此语法中的“T”和“Z”字符必须是大写。
- 必须使用“T”字符。
- 不能使用闰秒。
originator应该包含TIME-SECFRAC如果时间精度和性能允许。
如果sys应用程序无法获取系统时间syslog应用程序应该使用NILVALUE作为TIMESTAMP
5.2.3.1 例子
Example 1
1985-04-12T23:20:50.52Z
这表示UTC时间的1985-04-12T23:20:50.52
Example 2
1985-04-12T19:20:50.52-04:00
这表示的时间与例1中相同，但用US东部标准时间
Example 3
2003-10-11T22:14:15.003Z
这表示2003年10月11日下午10:14:15,3毫秒,UTC时间
Example 4
2003-08-24T05:14:15.000003-07:00
这表示2003年8月24日上午05:14:15,3微秒，-07:00表示它当地时间是UTC -7小时
Example 5 一个无效的时间戳
2003-08-24T05:14:15.000000003-07:00
这个示例与示例4几乎相同，但它是指定的TIME-SECFRAC纳秒。这就导致了TIME-SECFRAC长度超过允许的6位，这使它无效.
5.2.4 HOSTNAME
HOSTNAME字段标识发送这个syslog消息的机器。 一个syslog应用程序应该首先提供最具体的可用价值。HOSTNAME字段内容的优先顺序如下
如下:
1. FQDN
2. Static IP address
3. hostname
4. Dynamic IP address
5. the NILVALUE
5.2.5 APP-NAME
APP-NAME字段应该标识设备或应用程序起源的信息。它是一个没有特殊语义的字符串。它用于过滤relay或collector上的消息。
5.2.6 PROCID
这个字段没有任何特定的语法或者语义，通常用于提供进程名或进程syslog系统的ID,值的变化表明syslog报告出现了中断
5.2.7 MSGID
MSGID应该标识消息的类型。例如,一个防火墙可能使用MSGID“TCPIN”来处理传入的TCP流量 ，MSGID“TCPOUT”用于发送TCP流量。
具有相同MSGID的消息应该反映具有相同语义的事件 。字段本身是一个没有特殊语义的字符串。它是用来过滤的relay或collector上的消息。
5.3 STRUCTURED-DATA
结构化数据提供了一种以定义良好的方式表达信息的机制 .易于解析和解释的数据格式。有多个使用场景。它可以表示关于syslog元消息或特定于应用程序的信息
例如，流量计数器、IP地址等信息。
STRUCTURED-DATA可以包含零个，一个或者多个架构化数据元素，在本文档中称为“SD-ELEMENT”。
如果没有结构化数据元素，则使用structured - data字段必须包含NILVALUE。
结构化数据的字符集必须使用ascii码，除了PARAM-VALUE，它必须使用UTF-8编码
收集器可以忽略格式错误的结构化数据元素。一个中继器必须转发格式不正确的结构化数据而不作任何更改。
5.3.1 SD-ELEMENT
SD-ELEMENT由名称和参数name-value对组成。name称为SD-ID。name-value对被称为“SD-PARAM”
5.3.2 SD-ID
SD-ID是区分大小写的，并且唯一的，同一个syslog消息不能包含相同的SD-ID
SD-ID有两种命名格式: 参见[rfc5424]
- 不包含@符号的名称是预分配的保留字。当前这些保留字定义在规范[rfc5424]里，有IANA(互联网数字分配机构)组织管理，这里就不一一解释了
- 任何人可以定义除了保留名字之外的SD-ID, 格式为name@<private enterprise number>，例如：“ourSDID@32473”. @前面的部分没有特定的格式，但必须是可打印的ascii字符，不能包含@，=，]，"，空格或者控制字符，@后面的部分必须是一个私有企业id，“enterpriseId”必须是IANA维护的“SMI网络管理私有企业代码” ，这个号码必须唯一且必须在IANA注册
5.3.3 SD-PARAM
个SD-PARAM由一个名称(称为PARAM-NAME)和一个值(称为PARAM-VALUE)。
PARAM-NAME是区分大小写的。PARAM-NAME是在SD-ID范围内的，所以不同SD-ID的同名PARAM-NAME是不同的
要支持国际字符，PARAM-VALUE字段必须为使用utf - 8编码。syslog应用程序可以发出任何有效的UTF-8序列。syslog应用程序必须接受任何有效的UTF-8序列
在PARAM-VALUE里这三个字符都必须转义'"'，'\'和']'。使用反斜杠转义
5.3.4 Change Control
定义SD-ID和PARAM-NAME之后，这些对象的语法和语义绝不能改动。应该改变现有的对象时，必须创建一个新的SD-ID或PARAM-NAME，并且旧的保持不变。可选的PARAM-NAMEs可以添加到现有SD-ID。
5.3.5 Example
在下面的例子中，仅仅显示了结构化数据部分，
Exampl 1 - 有效的
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]
这个结构化数据元素的SD-ID为“exampleSDID@32473”，有三个参数。
Example 2 - 有效的
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
这与示例1中的相同，但使用了第二个结构化数据元素，注意他们之间没有空格
Example 3 - 无效的
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] [examplePriority@32473 class="high"]
这个例子和2几乎是一样的，但是它有一个微妙的错误在两个结构化数据元素之间有一个SP(空格)字符。这是无效的。它将导致STRUCTURED-DATA 字段
在第一个元素之后结束。第二个要素是解释为MSG字段的一部分。
Example 4 - 无效的
[ exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
这个例子和2差不多。它还有一个微妙的错误——SP字符出现在第一个括号之后。一个结构化的数据元素SD-ID必须紧跟在开始的括号后面，因此SP字符使结构化数据无效。syslog应用程序可以丢弃此消息。
5.4 MSG
MSG部分包含一个自由格式的字符串，MSG字段应该(不一定)使用UNICODE字符集，使用UTF-8编码，如果syslog应用程序不能编码在Unicode中的MSG，它可以使用任何其编码。
如果syslog应用程序使用UTF-8编码MSG, 则该字符串必须以Unicode字节顺序掩码(BOM)开始, 对于UTF-8该BOM是%xEF.BB.BF（16进制）
5.5 Example
以下是有效的syslog消息示例。每个例子描述都可以在下面找到。这些例子是基于类似的例子来自[RFC3164]，读者可能很熟悉。在本例中不可打印的Unicode BOM使用"BOM"表示。
Example 1 - with no STRUCTURED-DATA
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8
在本例中，VERSION是1，设施(Facility)值是4, 严重性(Severity)值是2。这个消息创建在UTC时间的2003-10-11T22:14:15.003，这个消息来源于一个主机名为“mymachine.example.com”的主机。APP-NAME是su，PROCID是未知的，MSGID是ID47，MSG是"'su root' failed for lonvick..."，使用UTF-8 BOM编码。
在这个消息里没有结构化数据，所以STRUCTURED-DATA字段被标记为“-”
Example 2 - with no STRUCTURED-DATA
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.
在这个例子里，VERSION还是1，Facility是20，Serverity是5，消息创建时间是2003-08-24T05:14:15.000003-07:00，HOSTNAME是“192.0.2.1”，APP-NAME是myproc，PROCID是8710，没有MSGID被标记为“-”，没有结构化数据被标记为“-”，具体消息是："%% It's time to make the do-nuts."，因为缺少Unicode BOM，这个syslog应用程序不知道这个MSG部分的编码。
Example 3 - with STRUCTURED-DATA
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
这个示例是在示例1之后修改的。然而，这一次它包含STRUCTURED-DATA, 带有值"[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]"的单个元素. MSG本身是"An application event log entry..."，MSG开头的BOM表示UTF-8编码。
Example 4 - STRUCTURED-DATA Only
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"][examplePriority@32473
class="high"]
这个例子显示了一条只有结构化数据而没有MSG消息部分。这是一个有效的消息。
至此，[rfc5424]协议内容基本上就讲解完了，还有一些是对保留SD-ID的解释，有兴趣的可以自己看一下，这里就不列举了，还有一些其他安全相关的东西，这里也不列举了
1650
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
