Network Working Group R. Gerhards
Request for Comments: 5424 Adiscon GmbH
Obsoletes: 3164 March 2009
Category: Standards Track
Network Working Group R. Gerhards
Request for Comments: 5424 Adiscon GmbH
Obsoletes: 3164 March 2009
Category: Standards Track
The Syslog Protocol
系统日志协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.
本文档描述用于传递事件通知消息的syslog协议。该协议利用分层体系结构，允许使用任意数量的传输协议传输系统日志消息。它还提供了一种消息格式，允许以结构化方式提供特定于供应商的扩展。
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.
本文档的编写考虑了传统syslog的原始设计目标。需要一个新的分层规范是因为可靠和安全的系统日志扩展的标准化工作受到缺乏独立于标准跟踪和传输的RFC的影响。没有本文档，其他标准需要定义自己的syslog数据包格式和传输机制，随着时间的推移，这将引入微妙的兼容性问题。该文档试图为SysLoC扩展提供基础。这种分层体系结构方法还提供了坚实的基础，允许为每个系统日志功能编写一次代码，而不是为每个传输编写一次。
This document obsoletes RFC 3164.
本文件淘汰RFC 3164。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Definitions .....................................................4
4. Basic Principles ................................................5
4.1. Example Deployment Scenarios ...............................6
5. Transport Layer Protocol ........................................7
5.1. Minimum Required Transport Mapping .........................7
6. Syslog Message Format ...........................................8
6.1. Message Length .............................................9
6.2. HEADER .....................................................9
6.2.1. PRI .................................................9
6.2.2. VERSION ............................................11
6.2.3. TIMESTAMP ..........................................11
6.2.4. HOSTNAME ...........................................13
6.2.5. APP-NAME ...........................................14
6.2.6. PROCID .............................................14
6.2.7. MSGID ..............................................14
6.3. STRUCTURED-DATA ...........................................15
6.3.1. SD-ELEMENT .........................................15
6.3.2. SD-ID ..............................................15
6.3.3. SD-PARAM ...........................................16
6.3.4. Change Control .....................................17
6.3.5. Examples ...........................................17
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Definitions .....................................................4
4. Basic Principles ................................................5
4.1. Example Deployment Scenarios ...............................6
5. Transport Layer Protocol ........................................7
5.1. Minimum Required Transport Mapping .........................7
6. Syslog Message Format ...........................................8
6.1. Message Length .............................................9
6.2. HEADER .....................................................9
6.2.1. PRI .................................................9
6.2.2. VERSION ............................................11
6.2.3. TIMESTAMP ..........................................11
6.2.4. HOSTNAME ...........................................13
6.2.5. APP-NAME ...........................................14
6.2.6. PROCID .............................................14
6.2.7. MSGID ..............................................14
6.3. STRUCTURED-DATA ...........................................15
6.3.1. SD-ELEMENT .........................................15
6.3.2. SD-ID ..............................................15
6.3.3. SD-PARAM ...........................................16
6.3.4. Change Control .....................................17
6.3.5. Examples ...........................................17
6.4. MSG .......................................................18
6.5. Examples ..................................................19
7. Structured Data IDs ............................................20
7.1. timeQuality ...............................................20
7.1.1. tzKnown ............................................21
7.1.2. isSynced ...........................................21
7.1.3. syncAccuracy .......................................21
7.1.4. Examples ...........................................21
7.2. origin ....................................................22
7.2.1. ip .................................................22
7.2.2. enterpriseId .......................................22
7.2.3. software ...........................................23
7.2.4. swVersion ..........................................23
7.2.5. Example ............................................23
7.3. meta ......................................................24
7.3.1. sequenceId .........................................24
7.3.2. sysUpTime ..........................................24
7.3.3. language ...........................................24
8. Security Considerations ........................................24
8.1. UNICODE ...................................................24
8.2. Control Characters ........................................25
8.3. Message Truncation ........................................26
8.4. Replay ....................................................26
8.5. Reliable Delivery .........................................26
8.6. Congestion Control ........................................27
8.7. Message Integrity .........................................28
8.8. Message Observation .......................................28
8.9. Inappropriate Configuration ...............................28
8.10. Forwarding Loop ..........................................29
8.11. Load Considerations ......................................29
8.12. Denial of Service ........................................29
9. IANA Considerations ............................................30
9.1. VERSION ...................................................30
9.2. SD-IDs ....................................................30
10. Working Group .................................................31
11. Acknowledgments ...............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
Appendix A. Implementer Guidelines ...............................34
A.1. Relationship with BSD Syslog ..............................34
A.2. Message Length ............................................35
A.3. Severity Values ..........................................36
A.4. TIME-SECFRAC Precision ....................................36
A.5. Case Convention for Names ................................36
A.6. Syslog Applications Without Knowledge of Time ............37
A.7. Notes on the timeQuality SD-ID ............................37
A.8. UTF-8 Encoding and the BOM ................................37
6.4. MSG .......................................................18
6.5. Examples ..................................................19
7. Structured Data IDs ............................................20
7.1. timeQuality ...............................................20
7.1.1. tzKnown ............................................21
7.1.2. isSynced ...........................................21
7.1.3. syncAccuracy .......................................21
7.1.4. Examples ...........................................21
7.2. origin ....................................................22
7.2.1. ip .................................................22
7.2.2. enterpriseId .......................................22
7.2.3. software ...........................................23
7.2.4. swVersion ..........................................23
7.2.5. Example ............................................23
7.3. meta ......................................................24
7.3.1. sequenceId .........................................24
7.3.2. sysUpTime ..........................................24
7.3.3. language ...........................................24
8. Security Considerations ........................................24
8.1. UNICODE ...................................................24
8.2. Control Characters ........................................25
8.3. Message Truncation ........................................26
8.4. Replay ....................................................26
8.5. Reliable Delivery .........................................26
8.6. Congestion Control ........................................27
8.7. Message Integrity .........................................28
8.8. Message Observation .......................................28
8.9. Inappropriate Configuration ...............................28
8.10. Forwarding Loop ..........................................29
8.11. Load Considerations ......................................29
8.12. Denial of Service ........................................29
9. IANA Considerations ............................................30
9.1. VERSION ...................................................30
9.2. SD-IDs ....................................................30
10. Working Group .................................................31
11. Acknowledgments ...............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
Appendix A. Implementer Guidelines ...............................34
A.1. Relationship with BSD Syslog ..............................34
A.2. Message Length ............................................35
A.3. Severity Values ..........................................36
A.4. TIME-SECFRAC Precision ....................................36
A.5. Case Convention for Names ................................36
A.6. Syslog Applications Without Knowledge of Time ............37
A.7. Notes on the timeQuality SD-ID ............................37
A.8. UTF-8 Encoding and the BOM ................................37
This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.
本文档描述了syslog的分层体系结构。此体系结构的目标是将消息内容与消息传输分离，同时为每一层实现简单的可扩展性。
This document describes the standard format for syslog messages and outlines the concept of transport mappings. It also describes structured data elements, which can be used to transmit easily parseable, structured information, and allows for vendor extensions.
本文档描述了系统日志消息的标准格式，并概述了传输映射的概念。它还描述了结构化数据元素，可用于传输易于解析的结构化信息，并允许供应商扩展。
This document does not describe any storage format for syslog messages. It is beyond of the scope of the syslog protocol and is unnecessary for system interoperability.
本文档不描述syslog消息的任何存储格式。它超出了syslog协议的范围，对于系统互操作性来说是不必要的。
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard would need to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature instead of once for each transport.
本文档的编写考虑了传统syslog的原始设计目标。需要一个新的分层规范是因为可靠和安全的系统日志扩展的标准化工作受到缺乏独立于标准跟踪和传输的RFC的影响。如果没有本文档，其他标准将需要定义自己的syslog数据包格式和传输机制，随着时间的推移，这将引入微妙的兼容性问题。该文档试图为SysLoC扩展提供基础。这种分层体系结构方法还提供了坚实的基础，允许为每个syslog功能编写一次代码，而不是为每个传输编写一次代码。
This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field.
本文档淘汰了RFC 3164，RFC 3164是一个信息性文档，描述了该领域中的一些实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Syslog utilizes three layers:
Syslog使用三层：
o "syslog content" is the management information contained in a syslog message.
o “系统日志内容”是包含在系统日志消息中的管理信息。
o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
o “系统日志应用程序”层处理系统日志消息的生成、解释、路由和存储。
o The "syslog transport" layer puts messages on the wire and takes them off the wire.
o “syslog传输”层将消息放到线路上，并将它们从线路上取下。
Certain types of functions are performed at each conceptual layer:
在每个概念层执行某些类型的功能：
o An "originator" generates syslog content to be carried in a message.
o “发起者”生成要在消息中携带的系统日志内容。
o A "collector" gathers syslog content for further analysis.
o “收集器”收集系统日志内容以供进一步分析。
o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
o “中继”转发消息，接受发起者或其他中继发送的消息，并将其发送给收集器或其他中继。
o A "transport sender" passes syslog messages to a specific transport protocol.
o “传输发送方”将系统日志消息传递给特定的传输协议。
o A "transport receiver" takes syslog messages from a specific transport protocol.
o “传输接收器”从特定的传输协议获取系统日志消息。
Diagram 1 shows the different entities separated by layer.
图1显示了由层分隔的不同实体。
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------
Diagram 1. Syslog Layers
图1。系统日志层
The following principles apply to syslog communication:
以下原则适用于系统日志通信：
o The syslog protocol does not provide acknowledgment of message delivery. Though some transports may provide status information, conceptually, syslog is a pure simplex communications protocol.
o syslog协议不提供消息传递的确认。尽管某些传输可能提供状态信息，但从概念上讲，syslog是一个纯粹的单工通信协议。
o Originators and relays may be configured to send the same message to multiple collectors and relays.
o 发起者和中继器可以配置为向多个收集器和中继器发送相同的消息。
o Originator, relay, and collector functionality may reside on the same system.
o 发起者、中继和收集器功能可能位于同一系统上。
Sample deployment scenarios are shown in Diagram 2. Other arrangements of these examples are also acceptable. As noted, in the following diagram, relays may send all or some of the messages that they receive and also send messages that they generate internally. The boxes represent syslog-enabled applications.
示例部署场景如图2所示。这些例子的其他安排也是可以接受的。如图所示，在下图中，继电器可以发送其接收的全部或部分消息，也可以发送其内部生成的消息。这些框表示启用系统日志的应用程序。
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
Diagram 2. Some Possible Syslog Deployment Scenarios
图2。一些可能的系统日志部署场景
This document does not specify any transport layer protocol. Instead, it describes the format of a syslog message in a transport layer independent way. Syslog transports are defined in other documents. One such transport is defined in [RFC5426] and is consistent with the traditional UDP transport. This transport is needed to maintain interoperability as the UDP transport has historically been used for the transmission of syslog messages.
本文档未指定任何传输层协议。相反，它以独立于传输层的方式描述syslog消息的格式。系统日志传输在其他文档中定义。[RFC5426]中定义了一种这样的传输，它与传统的UDP传输一致。由于UDP传输历来用于系统日志消息的传输，因此需要此传输来保持互操作性。
Any syslog transport protocol MUST NOT deliberately alter the syslog message. If the transport protocol needs to perform temporary transformations at the transport sender, these transformations MUST be reversed by the transport protocol at the transport receiver so that the relay or collector will see an exact copy of the message generated by the originator or relay. Otherwise, end-to-end cryptographic verifiers (such as signatures) will be broken. Of course, message alteration might occur due to transmission errors or other problems. Guarding against such alterations is not within the scope of this document.
任何系统日志传输协议不得故意更改系统日志消息。如果传输协议需要在传输发送方执行临时转换，则这些转换必须由传输接收方的传输协议逆转，以便中继器或收集器将看到发起者或中继器生成的消息的精确副本。否则，端到端加密验证器（如签名）将被破坏。当然，由于传输错误或其他问题，可能会发生消息更改。防止此类变更不在本文件范围内。
All implementations of this specification MUST support a TLS-based transport as described in [RFC5425].
本规范的所有实现必须支持[RFC5425]中所述的基于TLS的传输。
All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426].
本规范的所有实现还应支持[RFC5426]中所述的基于UDP的传输。
It is RECOMMENDED that deployments of this specification use the TLS-based transport.
建议此规范的部署使用基于TLS的传输。
The syslog message has the following ABNF [RFC5234] definition:
系统日志消息具有以下ABNF[RFC5234]定义：
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
SYSLOG-MSG=标头SP结构化数据[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
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
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
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 (")
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
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
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 = "-"
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. Each transport mapping defines the minimum maximum required message length support, and the minimum maximum MUST be at least 480 octets in length.
系统日志消息大小限制由正在使用的系统日志传输映射决定。本身没有上限。每个传输映射定义了所需的最小-最大消息长度支持，最小-最大消息长度必须至少为480个八位字节。
Any transport receiver MUST be able to accept messages of up to and including 480 octets in length. All transport receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Transport receivers MAY receive messages larger than 2048 octets in length. If a transport receiver receives a message with a length larger than it supports, the transport receiver SHOULD truncate the payload. Alternatively, it MAY discard the message.
任何传输接收器必须能够接受长度不超过480个八位字节的消息。所有传输接收器实现都应该能够接受长度不超过2048个八位字节的消息。传输接收器可接收长度大于2048个八位字节的消息。如果传输接收器接收到长度大于其支持长度的消息，则传输接收器应截断有效负载。或者，它可以丢弃该消息。
If a transport receiver truncates messages, the truncation MUST occur at the end of the message. After truncation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA. The transport receiver MAY discard the message or MAY try to process as much as possible in this case.
如果传输接收器截断消息，则截断必须发生在消息末尾。截断后，消息可能包含无效的UTF-8编码或无效的结构化数据。在这种情况下，传输接收方可能会丢弃该消息，或者可能会尝试尽可能多地处理该消息。
The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field as described in [RFC5234]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968].
标头中使用的字符集必须是[RFC5234]中所述八位字段中的七位ASCII。这些是“美国信息交换标准代码”[ANSI.X3-4.1968]中定义的ASCII码。
The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1.
标头格式旨在提供与旧的基于BSD的系统日志的一些互操作性。有关详细信息，请参见附录A.1。
The PRI part MUST have three, four, or five characters and will be bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character, %d60), followed by a number, which is followed by a ">" ('greater-than'
PRI部分必须有三个、四个或五个字符，并且将以尖括号作为第一个和最后一个字符进行绑定。PRI部分以一个前导“<”（“小于”字符，%d60）开头，后面是一个数字，后面是一个“>”（“大于”
character, %d62). The number contained within these angle brackets is known as the Priority value (PRIVAL) and represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
字符%d62）。这些尖括号中包含的数字称为优先级值（PRIVAL），表示设施和严重性。优先级值由一个、两个或三个十进制整数（ABNF数字）组成，使用的值为%d48（表示“0”）到%d57（表示“9”）。
Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive.
设施和严重性值不规范，但经常使用。下表中对其进行了描述，仅供参考。设施值必须在0到23（含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)
0内核消息1用户级消息2邮件系统3系统守护程序4安全/授权消息5 syslogd内部生成的消息6行打印机子系统7网络新闻子系统8 UUCP子系统9时钟守护程序10安全/授权消息11 FTP守护程序12 NTP子系统13日志审计14日志警报15时钟守护程序（注2）16本地使用0（local0）17本地使用1（local1）18本地使用2（local2）19本地使用3（local3）20本地使用4（local4）21本地使用5（local5）22本地使用6（local6）23本地使用7（local7）
Table 1. Syslog Message Facilities
表1。系统日志消息设施
Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Severity values MUST be in the range of 0 to 7 inclusive.
每个消息优先级还具有十进制严重性级别指示器。下表中描述了这些参数及其数值。严重性值必须在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
0紧急情况：系统不可用1警报：必须立即采取措施2严重：严重情况3错误：错误情况4警告：警告条件5通知：正常但有效的条件6信息性：信息性消息7调试：调试级别消息
Table 2. Syslog Message Severities
表2。系统日志消息严重性
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" follows the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used.
优先级值的计算方法是首先将设施编号乘以8，然后将严重性的数值相加。例如，严重性为紧急（严重性为0）的内核消息（Facility=0）的优先级值为0。此外，具有通知严重性（严重性=5）的“本地使用4”消息（设施=20）的优先级值为165。在syslog消息的PRI中，这些值将分别放在尖括号<0>和<165>之间。“0”值紧跟“<”之后的唯一时间是优先级值“0”。否则，不得使用前导“0”。
The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of "1". The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in [RFC5226].
版本字段表示系统日志协议规范的版本。对于任何更改头格式任何部分的新syslog协议规范，版本号必须增加。更改包括添加或删除字段，或更改现有字段的语法或语义。本文档使用的版本值为“1”。版本值通过[RFC5226]中所述的标准操作方法进行IANA分配（第9.1节）。
The TIMESTAMP field is a formalized timestamp derived from [RFC3339].
时间戳字段是从[RFC3339]派生的形式化时间戳。
Whereas [RFC3339] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions:
鉴于[RFC3339]允许使用多个语法，本文件规定了进一步的限制。时间戳值必须遵循以下限制：
o The "T" and "Z" characters in this syntax MUST be upper case.
o 此语法中的“T”和“Z”字符必须是大写。
o Usage of the "T" character is REQUIRED.
o 需要使用“T”字符。
o Leap seconds MUST NOT be used.
o 不得使用闰秒。
The originator SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The "timeQuality" SD-ID described in Section 7.1 allows the originator to specify the accuracy and trustworthiness of the timestamp.
如果TIME-SECFRAC的时钟精度和性能允许，发起人应将其包括在内。第7.1节中描述的“时间质量”SD-ID允许发起者指定时间戳的准确性和可信度。
A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time.
如果系统日志应用程序无法获取系统时间，则系统日志应用程序必须使用NILVALUE作为时间戳。
Example 1
例1
1985-04-12T23:20:50.52Z
1985-04-12T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC.
这表示UTC 1985年4月12日23小时后20分50.52秒。
Example 2
例2
1985-04-12T19:20:50.52-04:00
1985-04-12T19:20:50.52-04:00
This represents the same time as in example 1, but expressed in US Eastern Standard Time (observing daylight savings time).
这表示与示例1中相同的时间，但表示为美国东部标准时间（遵守夏令时）。
Example 3
例3
2003-10-11T22:14:15.003Z
2003-10-11T22:14:15.003Z
This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into the next second. The timestamp is in UTC. The timestamp provides millisecond resolution. The creator may have actually had a better resolution, but providing just three digits for the fractional part of a second does not tell us.
这表示2003年10月11日晚上10:14:15，再过3毫秒。时间戳以UTC为单位。时间戳提供毫秒分辨率。创造者实际上可能有更好的分辨率，但只提供一秒钟小数部分的三位数并不能告诉我们。
Example 4
例4
2003-08-24T05:14:15.000003-07:00
2003-08-24T05:14:15.000003-07:00
This represents 24 August 2003 at 05:14:15am, 3 microseconds into the next second. The microsecond resolution is indicated by the additional digits in TIME-SECFRAC. The timestamp indicates that its local time is -7 hours from UTC. This timestamp might be created in the US Pacific time zone during daylight savings time.
这表示2003年8月24日上午5时14分15分，下一秒是3微秒。微秒分辨率由TIME-SECFRAC中的附加数字表示。时间戳表明其本地时间是UTC的-7小时。此时间戳可能在夏时制期间在美国太平洋时区创建。
Example 5 - An Invalid TIMESTAMP
示例5-无效的时间戳
2003-08-24T05:14:15.000000003-07:00
2003-08-24T05:14:15.000000003-07:00
This example is nearly the same as Example 4, but it is specifying TIME-SECFRAC in nanoseconds. This results in TIME-SECFRAC being longer than the allowed 6 digits, which invalidates it.
此示例与示例4几乎相同，但它以纳秒为单位指定TIME-SECFRAC。这会导致TIME-SECFRAC超过允许的6位数字，从而使其无效。
The HOSTNAME field identifies the machine that originally sent the syslog message.
主机名字段标识最初发送syslog消息的计算机。
The HOSTNAME field SHOULD contain the hostname and the domain name of the originator in the format specified in STD 13 [RFC1034]. This format is called a Fully Qualified Domain Name (FQDN) in this document.
主机名字段应包含发起人的主机名和域名，格式见STD 13[RFC1034]。此格式在此文档中称为完全限定域名（FQDN）。
In practice, not all syslog applications are able to provide an FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A syslog application SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows:
实际上，并非所有syslog应用程序都能够提供FQDN。因此，主机名中也可能存在其他值。本文件规定在此类情况下使用其他值。系统日志应用程序应首先提供最具体的可用值。主机名字段内容的优先顺序如下：
1. FQDN
1. FQDN
2. Static IP address
2. 静态IP地址
3. hostname
3. 主机名
4. Dynamic IP address
4. 动态IP地址
5. the NILVALUE
5. 零价值
If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [RFC1035]. If an IPv6 address is used, a valid textual representation as described in [RFC4291], Section 2.2, MUST be used.
如果使用IPv4地址，则该地址必须采用STD 13[RFC1035]中使用的点十进制表示法格式。如果使用IPv6地址，则必须使用[RFC4291]第2.2节中所述的有效文本表示。
Syslog applications SHOULD consistently use the same value in the HOSTNAME field for as long as possible.
系统日志应用程序应尽可能长时间地在主机名字段中使用相同的值。
The NILVALUE SHOULD only be used when the syslog application has no way to obtain its real hostname. This situation is considered highly unlikely.
只有当syslog应用程序无法获取其真实主机名时，才应使用NILVALUE。这种情况被认为是极不可能的。
The APP-NAME field SHOULD identify the device or application that originated the message. It is a string without further semantics. It is intended for filtering messages on a relay or collector.
APP-NAME字段应标识发出消息的设备或应用程序。它是一个没有进一步语义的字符串。它用于过滤中继或收集器上的消息。
The NILVALUE MAY be used when the syslog application has no idea of its APP-NAME or cannot provide that information. It may be that a device is unable to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device.
当syslog应用程序不知道其APP-NAME或无法提供该信息时，可以使用NILVALUE。可能是由于本地策略决定，或由于设备上的信息不可用或不适用，设备无法提供该信息。
This field MAY be operator-assigned.
此字段可以由操作员指定。
PROCID is a value that is included in the message, having no interoperable meaning, except that a change in the value indicates there has been a discontinuity in syslog reporting. The field does not have any specific syntax or semantics; the value is implementation-dependent and/or operator-assigned. The NILVALUE MAY be used when no value is provided.
PROCID是消息中包含的一个值，没有可互操作的含义，除非该值的更改表明syslog报告中存在不连续性。该字段没有任何特定的语法或语义；该值取决于实现和/或操作员指定。如果未提供任何值，则可以使用NILVALUE。
The PROCID field is often used to provide the process name or process ID associated with a syslog system. The NILVALUE might be used when a process ID is not available. On an embedded system without any operating system process ID, PROCID might be a reboot ID.
PROCID字段通常用于提供与系统日志系统关联的进程名称或进程ID。当进程ID不可用时，可以使用NILVALUE。在没有任何操作系统进程ID的嵌入式系统上，PROCID可能是重新启动ID。
PROCID can enable log analyzers to detect discontinuities in syslog reporting by detecting a change in the syslog process ID. However, PROCID is not a reliable identification of a restarted process since the restarted syslog process might be assigned the same process ID as the previous syslog process.
PROCID可使日志分析器通过检测syslog进程ID的变化来检测syslog报告中的不连续性。但是，PROCID不是重新启动进程的可靠标识，因为重新启动的syslog进程可能被分配与以前的syslog进程相同的进程ID。
PROCID can also be used to identify which messages belong to a group of messages. For example, an SMTP mail transfer agent might put its SMTP transaction ID into PROCID, which would allow the collector or relay to group messages based on the SMTP transaction.
PROCID还可用于标识哪些消息属于一组消息。例如，SMTP邮件传输代理可能将其SMTP事务ID放入PROCID中，这将允许收集器或中继根据SMTP事务对邮件进行分组。
The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector.
MSGID应该标识消息的类型。例如，防火墙可能会将MSGID“TCPIN”用于传入TCP流量，将MSGID“TCPOUT”用于传出TCP流量。具有相同MSGID的消息应反映具有相同语义的事件。MSGID本身是一个没有进一步语义的字符串。它用于过滤中继或收集器上的消息。
The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value.
当syslog应用程序不提供或不能提供任何值时，应使用NILVALUE。
This field MAY be operator-assigned.
此字段可以由操作员指定。
STRUCTURED-DATA provides a mechanism to express information in a well defined, easily parseable and interpretable data format. There are multiple usage scenarios. For example, it may express meta-information about the syslog message or application-specific information such as traffic counters or IP addresses.
结构化数据提供了一种以定义良好、易于解析和解释的数据格式表达信息的机制。有多种使用场景。例如，它可以表示有关syslog消息的元信息或特定于应用程序的信息，如流量计数器或IP地址。
STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document.
结构化数据可以包含零个、一个或多个结构化数据元素，在本文档中称为“SD元素”。
In case of zero structured data elements, the STRUCTURED-DATA field MUST contain the NILVALUE.
如果结构化数据元素为零，则结构化数据字段必须包含零值。
The character set used in STRUCTURED-DATA MUST be seven-bit ASCII in an eight-bit field as described in [RFC5234]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. An exception is the PARAM-VALUE field (see Section 6.3.3), in which UTF-8 encoding MUST be used.
结构化数据中使用的字符集必须是[RFC5234]中所述八位字段中的七位ASCII。这些是“美国信息交换标准代码”[ANSI.X3-4.1968]中定义的ASCII码。参数值字段是一个例外（见第6.3.3节），其中必须使用UTF-8编码。
A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration.
收集器可能会忽略格式错误的结构化数据元素。中继必须转发格式错误的结构化数据，而不进行任何更改。
An SD-ELEMENT consists of a name and parameter name-value pairs. The name is referred to as SD-ID. The name-value pairs are referred to as "SD-PARAM".
SD元素由名称和参数名称值对组成。名称称为SD-ID。名称-值对称为“SD-PARAM”。
SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a message.
SD ID区分大小写，唯一标识SD-ID元素的类型和用途。同一SD-ID在消息中不得存在多次。
There are two formats for SD-ID names:
SD-ID名称有两种格式：
o Names that do not contain an at-sign ("@", ABNF %d64) are reserved to be assigned by IETF Review as described in BCP26 [RFC5226]. Currently, these are the names defined in Section 7. Names of this format are only valid if they are first registered with the IANA. Registered names MUST NOT contain an at-sign ('@', ABNF
o 如BCP26[RFC5226]所述，不包含at符号（“@”，ABNF%d64）的名称保留由IETF评审分配。目前，这些是第7节中定义的名称。此格式的名称仅在首次向IANA注册时有效。注册名称不得包含at符号（'@'，ABNF
%d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters (ASCII code 127 and codes 32 or less).
%d64）、等号（'='，ABNF%d61）、右大括号（']'，ABNF%d93）、引号字符（''''，ABNF%d34）、空格或控制字符（ASCII代码127和代码32或更少）。
o Anyone can define additional SD-IDs using names in the format name@<private enterprise number>, e.g., "ourSDID@32473". The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain an at-sign ('@', ABNF %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters. The part following the at-sign MUST be a private enterprise number as specified in Section 7.2.2. Please note that throughout this document the value of 32473 is used for all private enterprise numbers. This value has been reserved by IANA to be used as an example number in documentation. Implementors will need to use their own private enterprise number for the enterpriseId parameter, and when creating locally extensible SD-ID names.
o 任何人都可以使用name@<private enterprise number>格式的名称定义其他SD ID，例如“ourSDID@32473". 未规定at标志前面部分的格式；但是，这些名称必须是可打印的US-ASCII字符串，并且不得包含at符号（'@'，ABNF%d64）、等号（'='，ABNF%d61）、右大括号（']'，ABNF%d93）、引号字符（''''，ABNF%d34），空白或控制字符。at符号后面的部分必须是第7.2.2节中规定的私有企业编号。请注意，在本文件中，32473的值用于所有私有企业编号。IANA已保留该值，作为文件中的示例编号。实施者需要在创建本地可扩展的SD-ID名称时，为enterpriseId参数使用他们自己的私有企业编号。
Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE.
每个SD-PARAM由一个名称（称为PARAM-name）和一个值（称为PARAM-value）组成。
PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, with the exception of those in SD-IDs whose names contain an at-sign. The PARAM-NAME scope is within a specific SD-ID. Thus, equally named PARAM-NAME values contained in two different SD-IDs are not the same.
PARAM-NAME区分大小写。IANA控制所有参数名，但SD ID中名称包含at符号的参数名除外。PARAM-NAME作用域位于特定的SD-ID内。因此，两个不同的SD-ID中包含的同名PARAM-NAME值并不相同。
To support international characters, the PARAM-VALUE field MUST be encoded using UTF-8. A syslog application MAY issue any valid UTF-8 sequence. A syslog application MUST accept any valid UTF-8 sequence in the "shortest form". It MUST NOT fail if control characters are present in PARAM-VALUE. The syslog application MAY modify messages containing control characters (e.g., by changing an octet with value 0 (USASCII NUL) to the four characters "#000"). For the reasons outlined in UNICODE TR36 [UNICODE-TR36], section 3.1, an originator MUST encode messages in the "shortest form" and a collector or relay MUST NOT interpret messages in the "non-shortest form".
要支持国际字符，必须使用UTF-8对参数值字段进行编码。系统日志应用程序可以发出任何有效的UTF-8序列。系统日志应用程序必须接受“最短形式”的任何有效UTF-8序列。如果PARAM-VALUE中存在控制字符，则它不得失败。syslog应用程序可以修改包含控制字符的消息（例如，通过将值为0的八位字节（USASCII NUL）更改为四个字符“#000”）。出于UNICODE TR36[UNICODE-TR36]第3.1节中概述的原因，发起者必须以“最短形式”对消息进行编码，收集器或中继不得以“非最短形式”解释消息。
Inside PARAM-VALUE, the characters '"' (ABNF %d34), '\' (ABNF %d92), and ']' (ABNF %d93) MUST be escaped. This is necessary to avoid parsing errors. Escaping ']' would not strictly be necessary but is REQUIRED by this specification to avoid syslog application implementation errors. Each of these three characters MUST be escaped as '\"', '\\', and '\]' respectively. The backslash is used
在PARAM-VALUE中，必须转义字符''（ABNF%d34）、'\'（ABNF%d92）和']'（ABNF%d93）。这是避免分析错误所必需的。转义']'严格来说不是必需的，但本规范要求它以避免系统日志应用程序实现错误。这三个字符中的每一个都必须转义为'\'、'\'，和“\]”。使用反斜杠
for control character escaping for consistency with its use for escaping in other parts of the syslog message as well as in traditional syslog.
用于控制字符转义，以与在syslog消息的其他部分以及在传统syslog中转义的使用保持一致。
A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. In this case, the backslash MUST be treated as a regular backslash and the following character as a regular character. Thus, the invalid sequence MUST not be altered.
后跟所述三个字符中的任何一个的反斜杠（“\”）都不被视为无效的转义序列。在这种情况下，反斜杠必须视为常规反斜杠，以下字符必须视为常规字符。因此，不能改变无效序列。
An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT.
SD-PARAM可在SD-ELEMENT内重复多次。
Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or PARAM-NAME MUST be created and the old one remain unchanged. OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID.
一旦定义了SD id和PARAM名称，就不能更改这些对象的语法和语义。如果需要更改现有对象，则必须创建新的SD-ID或PARAM-NAME，而旧的SD-ID或PARAM-NAME保持不变。可选参数名称可以添加到现有SD-ID中。
All examples in this section show only the structured data part of the message. Examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes. A description is given after each example.
本节中的所有示例仅显示消息的结构化数据部分。应将示例视为一行。为了便于阅读，它们在本文档中被包装在多行中。每个示例后都给出了说明。
Example 1 - Valid
示例1-有效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"]
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"]
This example is a structured data element with a non-IANA controlled SD-ID of type "exampleSDID@32473", which has three parameters.
此示例是一个结构化数据元素，其非IANA控制的SD-ID类型为“exampleSDID@32473，它有三个参数。
Example 2 - Valid
示例2-有效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
This is the same example as in 1, but with a second structured data element. Please note that the structured data element immediately follows the first one (there is no SP between them).
这与1中的示例相同，但使用了第二个结构化数据元素。请注意，结构化数据元素紧跟在第一个元素之后（它们之间没有SP）。
Example 3 - Invalid
示例3-无效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]
This is nearly the same example as 2, but it has a subtle error -- there is an SP character between the two structured data elements ("]SP["). This is invalid. It will cause the STRUCTURED-DATA field to end after the first element. The second element will be interpreted as part of the MSG field.
这与2的示例几乎相同，但有一个细微的错误——两个结构化数据元素（“]SP[”）之间有一个SP字符。这是无效的。它将导致structured-data字段在第一个元素之后结束。第二个元素将被解释为MSG字段的一部分。
Example 4 - Invalid
示例4-无效
[ exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
[ exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
This example is nearly the same as 2. It has another subtle error -- the SP character occurs after the initial bracket. A structured data element SD-ID MUST immediately follow the beginning bracket, so the SP character invalidates the STRUCTURED-DATA. A syslog application MAY discard this message.
此示例与第2个示例几乎相同。它还有一个细微的错误——SP字符出现在初始括号之后。结构化数据元素SD-ID必须紧跟在开始括号之后，因此SP字符使结构化数据无效。系统日志应用程序可能会丢弃此消息。
Example 5 - Valid
例5-有效
[sigSig ver="1" rsID="1234" ... signature="..."]
[sigSig ver="1" rsID="1234" ... signature="..."]
Example 5 is a valid example. It shows a hypothetical IANA-assigned SD-ID. The ellipses denote missing content, which has been left out of this example for brevity.
示例5是一个有效的示例。它显示了一个假设的IANA分配的SD-ID。省略号表示缺少的内容，为简洁起见，本例中省略了该内容。
The MSG part contains a free-form message that provides information about the event.
MSG部分包含一条自由格式的消息，提供有关事件的信息。
The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 as specified in [RFC3629]. If the syslog application cannot encode the MSG in Unicode, it MAY use any other encoding.
MSG中使用的字符集应为UNICODE，使用[RFC3629]中规定的UTF-8编码。如果syslog应用程序无法用Unicode编码MSG，则可以使用任何其他编码。
The syslog application SHOULD avoid octet values below 32 (the traditional US-ASCII control character range except DEL). These values are legal, but a syslog application MAY modify these characters upon reception. For example, it might change them into an escape sequence (e.g., value 0 may be changed to "\0"). A syslog application SHOULD NOT modify any other octet values.
syslog应用程序应避免八位字节值低于32（传统的US-ASCII控制字符范围，DEL除外）。这些值是合法的，但syslog应用程序可能会在接收时修改这些字符。例如，它可能将它们更改为转义序列（例如，值0可能更改为“\0”）。系统日志应用程序不应修改任何其他八位字节值。
If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence.
如果syslog应用程序以UTF-8编码MSG，则字符串必须以Unicode字节顺序掩码（BOM）开头，对于UTF-8，该掩码为ABNF%xEF.BB.BF。syslog应用程序必须以“最短形式”编码，并且可以使用任何有效的UTF-8序列。
If a syslog application is processing an MSG starting with a BOM and the MSG contains UTF-8 that is not shortest form, the MSG MUST NOT be interpreted as being encoded in UTF-8, for the reasons outlined in [UNICODE-TR36], Section 3.1. Guidance about this is given in Appendix A.8.
如果syslog应用程序正在处理以BOM开头的消息，且消息包含非最短形式的UTF-8，则不得将消息解释为以UTF-8编码，原因见[UNICODE-TR36]第3.1节。附录A.8中给出了相关指南。
Also, according to UNICODE TR36 [UNICODE-TR36], a syslog application MUST NOT interpret messages in the "non-shortest form". It MUST NOT interpret invalid UTF-8 sequences.
此外，根据UNICODE TR36[UNICODE-TR36]，系统日志应用程序不得以“非最短形式”解释消息。它不能解释无效的UTF-8序列。
The following are examples of valid syslog messages. A description of each example can be found below it. The examples are based on similar examples from [RFC3164] and may be familiar to readers. The otherwise-unprintable Unicode BOM is represented as "BOM" in the examples.
以下是有效系统日志消息的示例。下面可以找到每个示例的说明。这些示例基于[RFC3164]中的类似示例，读者可能熟悉这些示例。在示例中，否则无法打印的Unicode BOM表示为“BOM”。
Example 1 - with no STRUCTURED-DATA
示例1-没有结构化数据
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
- BOM'su root' failed for lonvick on /dev/pts/8
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
- BOM'su root' failed for lonvick on /dev/pts/8
In this example, the VERSION is 1 and the Facility has the value of 4. The Severity is 2. The message was created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the next second. The message originated from a host that identifies itself as "mymachine.example.com". The APP-NAME is "su" and the PROCID is unknown. The MSGID is "ID47". The MSG is "'su root' failed for lonvick...", encoded in UTF-8. The encoding is defined by the BOM. There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field.
在本例中，版本为1，设施的值为4。严重程度为2。该消息创建于2003年10月11日UTC时间晚上10:14:15，再过3毫秒。该消息来自一个将自身标识为“mymachine.example.com”的主机。APP-NAME为“su”，PROCID未知。MSGID是“ID47”。消息是“lonvick…的'su root'失败”，用UTF-8编码。编码由BOM表定义。消息中不存在结构化数据；这在结构化数据字段中用“-”表示。
Example 2 - with no STRUCTURED-DATA
示例2-没有结构化数据
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710---%%该做螺母了。
In this example, the VERSION is again 1. The Facility is 20, the Severity 5. The message was created on 24 August 2003 at 5:14:15am, with a -7 hour offset from UTC, 3 microseconds into the next second. The HOSTNAME is "192.0.2.1", so the syslog application did not know its FQDN and used one of its IPv4 addresses instead. The APP-NAME is "myproc" and the PROCID is "8710" (for example, this could be the UNIX PID). There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field. There is no specific MSGID and this is indicated by the "-" in the MSGID field.
在本例中，版本再次为1。该设施为20，严重程度为5。该消息创建于2003年8月24日上午5:14:15，与UTC的偏差为-7小时，下一秒为3微秒。主机名为“192.0.2.1”，因此syslog应用程序不知道其FQDN，而是使用其IPv4地址之一。APP-NAME是“myproc”，PROCID是“8710”（例如，这可能是UNIX PID）。消息中不存在结构化数据；这在结构化数据字段中用“-”表示。没有特定的MSGID，这由MSGID字段中的“-”表示。
The message is "%% It's time to make the do-nuts.". As the Unicode BOM is missing, the syslog application does not know the encoding of the MSG part.
消息是“%%该做些疯狂的事了。”。由于缺少Unicode BOM，syslog应用程序不知道MSG部分的编码。
Example 3 - with STRUCTURED-DATA
示例3-使用结构化数据
<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...
<165>12003-10-11T22:14:15.003Z mymachine.example.com evntslog-ID47[exampleSDID@32473iut=“3”eventSource=“Application”eventID=“1011”]BOMAn应用程序事件日志条目。。。
This example is modeled after Example 1. However, this time it contains STRUCTURED-DATA, a single element with the value "[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]". The MSG itself is "An application event log entry..." The BOM at the beginning of MSG indicates UTF-8 encoding.
此示例是根据示例1建模的。但是，这一次它包含结构化数据，一个值为“[exampleSDID@32473iut=“3”eventSource=“Application”eventID=“1011”]”。消息本身是“应用程序事件日志条目…”消息开头的BOM表示UTF-8编码。
Example 4 - STRUCTURED-DATA Only
示例4-仅结构化数据
<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"]
<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"]
This example shows a message with only STRUCTURED-DATA and no MSG part. This is a valid message.
此示例显示的消息仅包含结构化数据，没有消息部分。这是一条有效的消息。
This section defines the initial IANA-registered SD-IDs. See Section 6.3 for a definition of structured data elements. All SD-IDs defined here are OPTIONAL.
本节定义初始IANA注册的SD ID。结构化数据元素的定义见第6.3节。此处定义的所有SD ID都是可选的。
In some of the following, a maximum length is quantified for the parameter values. In each of those cases, the syslog application MUST be prepared to receive the number of defined characters in any valid UTF-8 code point. Since each character may be up to 6 octets, it is RECOMMENDED that each syslog application be prepared to receive up to 6 octets per character.
在以下某些情况下，将量化参数值的最大长度。在每种情况下，syslog应用程序都必须准备好接收任何有效UTF-8代码点中定义的字符数。由于每个字符最多可以有6个八位字节，因此建议每个syslog应用程序为每个字符最多接收6个八位字节做好准备。
The SD-ID "timeQuality" MAY be used by the originator to describe its notion of system time. This SD-ID SHOULD be written if the originator is not properly synchronized with a reliable external time source or if it does not know whether its time zone information is
发起者可使用SD-ID“时间质量”来描述其系统时间的概念。如果发端人未与可靠的外部时间源正确同步，或者不知道其时区信息是否正确，则应编写此SD-ID
correct. The main use of this structured data element is to provide some information on the level of trust it has in the TIMESTAMP described in Section 6.2.3. All parameters are OPTIONAL.
对的此结构化数据元素的主要用途是提供有关其在第6.2.3节所述时间戳中的信任级别的一些信息。所有参数都是可选的。
The "tzKnown" parameter indicates whether the originator knows its time zone. If it does, the value "1" MUST be used. If the time zone information is in doubt, the value "0" MUST be used. If the originator knows its time zone but decides to emit time in UTC, the value "1" MUST be used (because the time zone is known).
“tzKnown”参数表示发起者是否知道其时区。如果是，则必须使用值“1”。如果时区信息有疑问，则必须使用值“0”。如果发端人知道其时区，但决定以UTC发出时间，则必须使用值“1”（因为时区是已知的）。
The "isSynced" parameter indicates whether the originator is synchronized to a reliable external time source, e.g., via NTP. If the originator is time synchronized, the value "1" MUST be used. If not, the value "0" MUST be used.
“isSynced”参数表示发起者是否与可靠的外部时间源同步，例如通过NTP。如果发起人是时间同步的，则必须使用值“1”。如果不是，则必须使用值“0”。
The "syncAccuracy" parameter indicates how accurate the originator thinks its time synchronization is. It is an integer describing the maximum number of microseconds that its clock may be off between synchronization intervals.
“SyncAccurance”参数表示发起者认为其时间同步的准确性。它是一个整数，描述其时钟在同步间隔之间可能关闭的最大微秒数。
If the value "0" is used for "isSynced", this parameter MUST NOT be specified. If the value "1" is used for "isSynced" but the "syncAccuracy" parameter is absent, a collector or relay can assume that the time information provided is accurate enough to be considered correct. The "syncAccuracy" parameter MUST be written only if the originator actually has knowledge of the reliability of the external time source. In most cases, it will gain this in-depth knowledge through operator configuration.
如果值“0”用于“isSynced”，则不得指定此参数。如果值“1”用于“isSynced”，但“SyncAccurance”参数不存在，则采集器或继电器可以认为提供的时间信息足够准确，可以认为是正确的。仅当发端人实际了解外部时间源的可靠性时，才必须写入“SyncAccurance”参数。在大多数情况下，它将通过操作员配置获得这种深入的知识。
The following is an example of an originator that does not know its time zone or whether it is being synchronized:
以下是发端人不知道其时区或是否正在同步的示例：
[timeQuality tzKnown="0" isSynced="0"]
[timeQuality tzKnown=“0”isSynced=“0”]
With this information, the originator indicates that its time information is unreliable. This may be a hint for the collector or relay to use its local time instead of the message-provided TIMESTAMP for correlation of multiple messages from different originators.
根据此信息，发起者表示其时间信息不可靠。这可能提示收集器或中继使用其本地时间而不是消息提供的时间戳来关联来自不同发起者的多条消息。
The following is an example of an originator that knows its time zone and knows that it is properly synchronized to a reliable external source:
以下是一个发端人的示例，发端人知道自己的时区，并且知道自己与可靠的外部源正确同步：
[timeQuality tzKnown="1" isSynced="1"]
[timeQuality tzKnown=“1”isSynced=“1”]
The following is an example of an originator that knows both its time zone and that it is externally synchronized. It also knows the accuracy of the external synchronization:
以下是一个发端人的示例，该发端人既知道自己的时区，也知道自己是外部同步的。它还知道外部同步的准确性：
[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]
[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]
The difference between this and the previous example is that the originator expects that its clock will be kept within 60 seconds of the official time. Thus, if the originator reports it is 9:00:00, it is no earlier than 8:59:00 and no later then 9:01:00.
此示例与前一示例的区别在于，发起者希望其时钟保持在官方时间的60秒以内。因此，如果发起人报告时间为9:00:00，则不早于8:59:00，也不晚于9:01:00。
The SD-ID "origin" MAY be used to indicate the origin of a syslog message. The following parameters can be used. All parameters are OPTIONAL.
SD-ID“来源”可用于指示系统日志消息的来源。可以使用以下参数。所有参数都是可选的。
Specifying any of these parameters is primarily an aid to log analyzers and similar applications.
指定这些参数中的任何一个主要有助于日志分析器和类似应用程序。
The "ip" parameter denotes an IP address that the originator knows it had at the time of originating the message. It MUST contain the textual representation of an IP address as outlined in Section 6.2.4.
“ip”参数表示发端人在发送消息时知道自己拥有的ip地址。它必须包含第6.2.4节中概述的IP地址的文本表示。
This parameter can be used to provide identifying information in addition to what is present in the HOSTNAME field. It might be especially useful if the host's IP address is included in the message while the HOSTNAME field still contains the FQDN. It is also useful for describing all IP addresses of a multihomed host.
除了主机名字段中存在的信息外，此参数还可用于提供标识信息。如果主机的IP地址包含在消息中，而主机名字段仍然包含FQDN，则此选项可能特别有用。它对于描述多宿主机的所有IP地址也很有用。
If an originator has multiple IP addresses, it MAY either list one of its IP addresses in the "ip" parameter or it MAY include multiple "ip" parameters in a single "origin" structured data element.
如果发端人有多个IP地址，它可以在“IP”参数中列出其一个IP地址，也可以在单个“源”结构化数据元素中包含多个“IP”参数。
The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number that follows MUST be unique and MUST be registered with IANA as per
“enterpriseId”参数必须是“SMI网络管理私有企业代码”，由IANA维护，前缀为iso.org.dod.internet.Private.Enterprise（1.3.6.1.4.1）。以下编号必须是唯一的，并且必须按照
RFC 2578 [RFC2578]. An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree. In general, only the IANA-assigned private enterprise number is needed (a single number). An enterprise might decide to use sub-identifiers below its private enterprise number. If sub-identifiers are used, they MUST be separated by periods and be represented as decimal numbers. An example for that would be "32473.1.2". Please note that the ID "32473.1.2" is just an example and MUST NOT be used. The complete up-to-date list of Private Enterprise Numbers (PEN) is maintained by IANA.
RFC 2578[RFC2578]。企业仅被授权在IANA分配给该企业的iso.org.dod.internet.private.enterprise.<private enterprise number>子树中分配值。enterpriseId必须仅包含来自iso.org.dod.internet.private.enterprise.<private enterprise number>子树的值。通常，只需要IANA分配的私营企业编号（单个编号）。企业可能决定在其私有企业编号下使用子标识符。如果使用子标识符，则必须用句点分隔，并用十进制数表示。例如“32473.1.2”。请注意，ID“32473.1.2”只是一个示例，不得使用。IANA保存完整的最新私营企业编号列表（PEN）。
By specifying a private enterprise number, the vendor allows more specific processing of the message.
通过指定私有企业编号，供应商允许对消息进行更具体的处理。
The "software" parameter uniquely identifies the software that generated the message. If it is used, "enterpriseId" SHOULD also be specified, so that a specific vendor's software can be identified. The "software" parameter is not the same as the APP-NAME header field. It MUST always contain the name of the generating software, whereas APP-NAME can contain anything else, including an operator-configured value.
“软件”参数唯一标识生成消息的软件。如果使用“enterpriseId”，则还应指定，以便识别特定供应商的软件。“软件”参数与APP-NAME标题字段不同。它必须始终包含生成软件的名称，而APP-name可以包含任何其他内容，包括操作员配置的值。
The "software" parameter is a string. It MUST NOT be longer than 48 characters.
“软件”参数是一个字符串。长度不得超过48个字符。
The "swVersion" parameter uniquely identifies the version of the software that generated the message. If it is used, the "software" and "enterpriseId" parameters SHOULD be provided, too.
“swVersion”参数唯一标识生成消息的软件版本。如果使用，还应提供“软件”和“企业ID”参数。
The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters.
“swVersion”参数是一个字符串。长度不得超过32个字符。
The following is an example with multiple IP addresses:
以下是具有多个IP地址的示例：
[origin ip="192.0.2.1" ip="192.0.2.129"]
[origin ip=“192.0.2.1”ip=“192.0.2.129”]
In this example, the originator indicates that it has two IP addresses, one being 192.0.2.1 and the other one being 192.0.2.129.
在本例中，发起者表示它有两个IP地址，一个是192.0.2.1，另一个是192.0.2.129。
The SD-ID "meta" MAY be used to provide meta-information about the message. The following parameters can be used. All parameters are OPTIONAL. If the "meta" SD-ID is used, at least one parameter SHOULD be specified.
SD-ID“meta”可用于提供关于消息的meta信息。可以使用以下参数。所有参数都是可选的。如果使用“meta”SD-ID，则应至少指定一个参数。
The "sequenceId" parameter tracks the sequence in which the originator submits messages to the syslog transport for sending. It is an integer that MUST be set to 1 when the syslog function is started and MUST be increased with every message up to a maximum value of 2147483647. If that value is reached, the next message MUST be sent with a sequenceId of 1.
“sequenceId”参数跟踪发起者向syslog传输提交消息以进行发送的顺序。它是一个整数，在syslog函数启动时必须设置为1，并且必须随着每条消息的增加而增加，最大值为2147483647。如果达到该值，则必须发送sequenceId为1的下一条消息。
The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in [RFC3418].
“sysUpTime”参数可用于在消息中包含SNMP“sysUpTime”参数。其语法和语义如[RFC3418]所述。
As syslog does not support the SNMP "INTEGER" syntax directly, the value MUST be represented as a decimal integer (no decimal point) using only the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", and "9".
由于syslog不直接支持SNMP“整数”语法，因此该值必须仅使用字符“0”、“1”、“2”、“3”、“4”、“5”、“6”、“7”、“8”和“9”表示为十进制整数（无小数点）。
Note that the semantics in RFC 3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system.
请注意，RFC 3418中的语义是“自系统的网络管理部分上次重新初始化以来的时间（百分之一秒）。”这当然与系统的SNMP相关管理部分有关，这可能与系统的syslog相关管理部分不同。
The "language" parameter MAY be specified by the originator to convey information about the natural language used inside MSG. If it is specified, it MUST contain a language identifier as defined in BCP 47 [RFC4646].
“语言”参数可由发起者指定，以传达有关MSG中使用的自然语言的信息。如果指定，则必须包含BCP 47[RFC4646]中定义的语言标识符。
This document uses UTF-8 encoding for the PARAM-VALUE and MSG fields. There are a number of security issues with UNICODE. Any implementer and operator is advised to review UNICODE TR36 [UNICODE-TR36] (UTR36) to learn about these issues. This document guards against the
本文档对PARAM-VALUE和MSG字段使用UTF-8编码。UNICODE存在许多安全问题。建议任何实施者和操作员查看UNICODE TR36[UNICODE-TR36]（UTR36）以了解这些问题。这份文件是为了防止
technical issues outlined in UTR36 by REQUIRING "shortest form" encoding for syslog applications. However, the visual spoofing due to character confusion still persists. This document tries to minimize the effects of visual spoofing by allowing UNICODE only where local script is expected and needed. In all other fields, US-ASCII is REQUIRED. Also, the PARAM-VALUE and MSG fields should not be the primary source for identifying information, further reducing the risks associated with visual spoofing.
UTR36中概述了系统日志应用程序需要“最短形式”编码的技术问题。但是，由于字符混淆导致的视觉欺骗仍然存在。本文档试图通过仅在预期和需要本地脚本的情况下允许UNICODE来最小化视觉欺骗的影响。在所有其他字段中，US-ASCII是必需的。此外，PARAM-VALUE和MSG字段不应成为识别信息的主要来源，从而进一步降低与可视欺骗相关的风险。
This document does not impose any mandatory restrictions on the MSG or PARAM-VALUE content. As such, they MAY contain control characters, including the NUL character.
本文件不对MSG或PARAM-VALUE内容施加任何强制性限制。因此，它们可能包含控制字符，包括NUL字符。
In some programming languages (most notably C and C++), the NUL character (ABNF %d00) traditionally has a special significance as string terminator. Most implementations of these languages assume that a string will not extend beyond the first NUL character. This is primarily a restriction of the supporting run-time libraries. This restriction is often carried over to programs and script languages written in those languages. As such, NUL characters must be considered with great care and be properly handled. An attacker may deliberately include NUL characters to hide information after them. Incorrect handling of the NUL character may also invalidate cryptographic checksums that are transmitted inside the message.
在某些编程语言（最著名的是C和C++）中，NUL字符（ABNF%d00）通常作为字符串终止符具有特殊意义。这些语言的大多数实现都假定字符串不会超过第一个NUL字符。这主要是对支持运行时库的限制。这一限制通常适用于用这些语言编写的程序和脚本语言。因此，NUL字符必须仔细考虑并妥善处理。攻击者可能会故意包含NUL字符以隐藏后面的信息。对NUL字符的不正确处理也可能使消息内部传输的加密校验和无效。
Many popular text editors are also written in languages with this restriction. Encoding NUL characters when writing to text files is advisable. If they are stored without encoding, the file can become unreadable.
许多流行的文本编辑器也使用有此限制的语言编写。建议在写入文本文件时对NUL字符进行编码。如果存储时未编码，则文件可能无法读取。
Other control characters may also be problematic. For example, an attacker may deliberately include backspace characters to render parts of the log message unreadable. Similar issues exist for almost all control characters.
其他控制字符也可能有问题。例如，攻击者可能故意包含退格字符，以使部分日志消息无法读取。几乎所有控制字符都存在类似的问题。
Finally, invalid UTF-8 sequences may be used by an attacker to inject ASCII control characters.
最后，攻击者可能会使用无效的UTF-8序列来注入ASCII控制字符。
This specification permits a syslog application to reformat control characters received. Among others, the security risks associated with control characters were an important driving force behind this restriction. Originators are advised that if any encoding other than ASCII and UTF8 are used, the receiver may corrupt the message in an attempt to filter ASCII control characters.
此规范允许syslog应用程序重新格式化接收的控制字符。其中，与控制字符相关的安全风险是这一限制背后的一个重要驱动力。建议发起者，如果使用ASCII和UTF8以外的任何编码，接收者可能会在试图过滤ASCII控制字符时损坏消息。
Message truncation can be misused by an attacker to hide vital log information. Messages over the minimum supported size may be discarded or truncated by the transport receiver. As such, vital log information may be lost.
攻击者可能滥用消息截断来隐藏重要日志信息。超过支持的最小大小的消息可能会被传输接收器丢弃或截断。因此，重要日志信息可能会丢失。
In order to prevent information loss, messages should not be longer than the minimum maximum size required by Section 6.1. For best performance and reliability, messages should be as small as possible. Important information should be placed as early in the message as possible because information at the beginning of the message is less likely to be discarded by a size-limited transport receiver.
为防止信息丢失，信息长度不应超过第6.1节要求的最小最大尺寸。为了获得最佳性能和可靠性，消息应该尽可能小。重要信息应尽可能早地放在消息中，因为消息开头的信息不太可能被大小有限的传输接收器丢弃。
An originator should limit the size of any user-supplied data within a syslog message. If it does not, an attacker may provide large data in hopes of exploiting a potential weakness.
发起人应限制syslog消息中用户提供的任何数据的大小。否则，攻击者可能会提供大量数据，以期利用潜在的弱点。
There is no mechanism in the syslog protocol to detect message replay. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the relay or collector. Even with the TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.
syslog协议中没有检测消息重播的机制。攻击者可能会记录一组指示计算机正常活动的消息。稍后，该攻击者可能会将该计算机从网络中删除，并将系统日志消息重播到中继或收集器。即使报头部分有时间戳字段，攻击者也可以记录数据包，并可以在重新传输数据包之前简单地修改数据包以反映当前时间。管理员可能在收到的消息中没有发现任何异常，收到这些消息将错误地指示机器的正常活动。
Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.
对消息进行加密签名可以防止时间戳的更改，从而防止重播攻击。
Because there is no mechanism described within this document to ensure delivery, and the underlying transport may be unreliable (e.g., UDP), some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of dropping one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may not be noticed or may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
由于本文档中没有描述确保传递的机制，并且底层传输可能不可靠（例如UDP），因此可能会丢失一些消息。它们可能由于网络拥塞而被丢弃，也可能被恶意拦截并丢弃。无法确定删除一个或多个系统日志消息的后果。如果消息是简单的状态更新，那么它们的未接收可能不会被注意到，或者可能会给系统操作员带来麻烦。另一方面，如果消息更重要，则管理员可能没有意识到正在发展的潜在严重问题。作为隐藏未经授权活动的一种方式，攻击者还可能截获和丢弃消息。
It may also be desirable to include rate-limiting features in syslog originators and relays. This can reduce potential congestion problems when message bursts happen.
在系统日志发起者和中继中包括速率限制功能也是可取的。这可以减少消息突发时潜在的拥塞问题。
Reliable delivery may not always be desirable. Reliable delivery means that the syslog originator or relay must block when the relay or collector is not able to accept any more messages. In some operating systems, namely Unix/Linux, the syslog originator or relay runs inside a high-priority system process (syslogd). If that process blocks, the system at large comes to a stand-still. The same occurs if there is a deadlock situation between syslogd and e.g., the DNS server.
可靠的交付可能并不总是可取的。可靠传递意味着当中继或收集器无法接受更多消息时，系统日志发起者或中继必须阻止。在某些操作系统（即Unix/Linux）中，syslog发起人或中继在高优先级系统进程（syslogd）内运行。如果这一过程受阻，整个系统就会陷入停滞。如果syslogd和DNS服务器之间存在死锁情况，也会发生同样的情况。
To prevent these problems, reliable delivery can be implemented in a way that intentionally discards messages when the syslog application would otherwise block. The advantage of reliable delivery in this case is that the syslog originator or relay knowingly discards the message and is able to notify the relay or collector about that fact. So the relay or collector receives the information that something is lost. With unreliable delivery, the message would simply be lost without any indication that loss occurred.
为了防止这些问题，可以在syslog应用程序阻塞时以故意丢弃消息的方式实现可靠传递。在这种情况下，可靠传递的优点是syslog发起者或中继故意丢弃消息，并能够将该事实通知中继或收集器。因此，中继器或采集器接收到丢失的信息。如果传递不可靠，消息将丢失，而没有任何丢失的迹象。
Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [RFC2914]. This is why the syslog TLS transport is REQUIRED to implement and RECOMMENDED for general use.
由于syslog可以生成无限量的数据，因此通过UDP传输这些数据通常是有问题的，因为UDP缺乏拥塞控制机制。拥塞控制机制通过降低流量来应对拥塞，并在共享同一路径的流之间建立一定程度的公平性，这对于互联网的稳定运行至关重要[RFC2914]。这就是为什么需要实现syslog TLS传输，并推荐用于一般用途。
The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used.
syslog UDP传输可用作TLS传输的替代方案的唯一环境是托管网络，其中已通过流量工程机制（如速率限制或容量保留）为UDP syslog流量显式设置了网络路径。在所有其他环境中，应使用TLS传输。
In any implementation, the situation may arise in which an originator or relay would need to block sending messages. A common case is when an internal queue is full. This might happen due to rate-limiting or slow performance of the syslog application. In any event, it is highly RECOMMENDED that no messages be dropped but that they should be temporarily stored until they can be transmitted. However, if they must be dropped, it is RECOMMENDED that the originator or relay drop messages of lower severity in favor of higher severity messages.
在任何实现中，都可能出现发起者或中继需要阻止发送消息的情况。一种常见情况是内部队列已满。这可能是由于syslog应用程序的速率限制或性能缓慢造成的。在任何情况下，强烈建议不要丢弃任何消息，但应暂时存储这些消息，直到它们可以传输为止。但是，如果必须删除它们，建议发起者或中继较低严重性的删除消息，以支持较高严重性的消息。
Messages with a lower numerical SEVERITY value have a higher practical severity than those with a numerically higher value. In that situation, the messages that are to be dropped SHOULD simply be discarded. The syslog application may notify a collector or relay about the fact that it has dropped messages.
具有较低数值严重性值的消息比具有较高数值的消息具有更高的实际严重性。在这种情况下，应该丢弃要丢弃的消息。syslog应用程序可能会通知收集器或中继它已丢弃消息的事实。
Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In such cases, the original contents of the message will not be delivered to the collector or relay. Additionally, if an attacker is positioned between the transport sender and transport receiver of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities.
除了被丢弃之外，系统日志消息还可能在传输过程中受损，或者攻击者可能恶意修改它们。在这种情况下，消息的原始内容将不会传递给收集器或中继。此外，如果攻击者位于syslog消息的传输发送方和传输接收方之间，则他们可能能够在传输过程中拦截和修改这些消息，以隐藏未经授权的活动。
While there are no strict guidelines pertaining to the MSG format, most syslog messages are generated in human-readable form with the assumption that capable administrators should be able to read them and understand their meaning. The syslog protocol does not have mechanisms to provide confidentiality for the messages in transit. In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage.
虽然没有关于MSG格式的严格指导原则，但大多数系统日志消息都是以人类可读的形式生成的，并且假设有能力的管理员应该能够阅读它们并理解它们的含义。syslog协议没有为传输中的消息提供机密性的机制。在大多数情况下，如果操作人员正在嗅探来自电线的数据包，那么传递明文信息对他们来说是一种好处。操作人员可能能够读取消息，并将其与通过电线的其他数据包中看到的其他事件相关联，以跟踪和纠正问题。不幸的是，攻击者也可能能够观察到系统日志消息的可读内容。然后，攻击者可能会利用从这些消息中获得的知识危害机器或造成其他损害。
Operators are advised to use a secure transport mapping to avoid this problem.
建议运营商使用安全的传输映射来避免此问题。
Because there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipients. Cases have been noted where syslog applications were inadvertently configured to send syslog messages to the wrong relays or collectors. In many cases, the inadvertent relays or collectors may not be configured to receive syslog messages and will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient. If messages are not going to the intended recipient, then they cannot be reviewed or processed.
由于没有关于任何消息或配置的控制信息，因此网络管理员完全有责任确保消息实际发送给预期的收件人。已经注意到，系统日志应用程序无意中被配置为向错误的继电器或收集器发送系统日志消息。在许多情况下，意外继电器或收集器可能未配置为接收系统日志消息，并且可能会丢弃它们。在某些其他情况下，已知接收系统日志消息会给非预期收件人造成问题。如果邮件没有发送给预期的收件人，则无法对其进行审阅或处理。
Using a reliable transport mapping can help identify some of these problems. For example, it can identify a problem where a message is being sent to a system that is not configured to receive messages. It cannot identify sending messages to a wrong machine that is accepting messages.
使用可靠的传输映射可以帮助识别其中一些问题。例如，它可以识别将消息发送到未配置为接收消息的系统的问题。它无法识别将消息发送到接收消息的错误机器。
As shown in Diagram 2, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain SEVERITY values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care not to cause such a death spiral.
如图2所示，可以将机器配置为在到达收集器之前将syslog消息中继到后续的继电器。在一个特定的案例中，管理员发现他错误地配置了两个中继，将具有特定严重性值的消息转发给彼此。当这些机器中的任何一台收到或生成该类型的消息时，它会将其转发给另一个中继。接力器会反过来将其转发回去。这一周期确实导致介入网络以及两台设备上的处理可用性降级。网络管理员必须注意不要造成这样的死亡螺旋。
Network administrators must take the time to estimate the appropriate capacity of the syslog collector. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a transport receiver must have a network interface capable of receiving the messages sent to it.
网络管理员必须花时间估计syslog收集器的适当容量。攻击者可以通过在收集器的磁盘中填充虚假消息来执行拒绝服务攻击。将记录放在循环文件中可能会缓解这一问题，但其后果是无法确保管理员将来能够查看记录。沿着这条线路，传输接收器必须具有能够接收发送给它的消息的网络接口。
Administrators and network planners must also critically review the network paths between the originators, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links.
管理员和网络规划人员还必须严格审查发起者、中继和收集器之间的网络路径。生成的系统日志消息不应覆盖任何网络链接。
In order to reduce the impact of this issue, using transports with guaranteed delivery is recommended.
为了减少此问题的影响，建议使用保证交付的传输。
As with any system, an attacker may just overwhelm a transport receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementers should attempt to provide features that minimize this threat, such as only accepting syslog messages from known IP addresses.
与任何系统一样，攻击者可能会通过向传输接收器发送超过基础设施或设备本身所能处理的消息来压倒它。实现者应该尝试提供最小化这种威胁的功能，例如只接受来自已知IP地址的系统日志消息。
IANA has created a registry entitled "syslog Version Values" of VERSION values as described in Section 6.2.2. Version numbers MUST be incremented for any new syslog protocol specification that changes any part of the HEADER. Changes include addition or removal of fields or a change of syntax or semantics of existing fields.
IANA已经创建了一个名为“syslog Version Values”的注册表，其版本值如第6.2.2节所述。对于任何更改标头任何部分的新syslog协议规范，版本号必须递增。更改包括添加或删除字段，或更改现有字段的语法或语义。
VERSION numbers must be registered via the Standards Action method as described in [RFC5226]. IANA has registered the VERSIONs shown in Table 3 below.
版本号必须通过[RFC5226]中所述的标准操作方法进行注册。IANA已注册了下表3所示的版本。
VERSION FORMAT 1 Defined in [RFC5424]
[RFC5424]中定义的版本格式1
Table 3. IANA-Registered VERSIONs
表3。IANA注册版本
IANA has created a registry entitled "syslog Structured Data ID Values" of Structured Data ID (SD-ID) values together with their associated PARAM-NAME values as described in Section 7.
IANA创建了一个名为“syslog Structured Data ID Values”的注册表，该注册表包含结构化数据ID（SD-ID）值及其相关的参数名称值，如第7节所述。
New SD-ID and new PARAM-NAME values must be registered through the IETF Review method as described in [RFC5226].
新SD-ID和新PARAM-NAME值必须通过[RFC5226]中所述的IETF审查方法进行注册。
Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or SD-PARAM MUST be created and the old one remain unchanged.
一旦定义了SD ID和SD参数，就不能更改这些对象的语法和语义。如果需要更改现有对象，则必须创建新的SD-ID或SD-PARAM，并且旧的SD-ID或SD-PARAM保持不变。
A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign (ABNF %d64) in them.
这里规定了本地可扩展名称。IANA不会注册，也不会控制带有at符号（ABNF%d64）的名称。
IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below.
IANA已注册了表4所示的SD ID和参数名称。
SD-ID PARAM-NAME timeQuality OPTIONAL tzKnown OPTIONAL isSynced OPTIONAL syncAccuracy OPTIONAL
SD-ID参数名称时间质量可选tzKnown可选isSynced可选同步精度可选
origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL
源站可选ip可选企业ID可选软件可选swVersion可选
meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL
元可选sequenceId可选sysUpTime可选语言可选
Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs
表4。IANA注册的SD ID及其参数名
The working group can be contacted via the mailing list:
可通过邮件列表联系工作组：
syslog@ietf.org
syslog@ietf.org
The current Chairs of the Working Group may be contacted at:
可通过以下方式联系工作组现任主席：
Chris Lonvick Cisco Systems EMail: clonvick@cisco.com
Chris Lonvick Cisco Systems电子邮件：clonvick@cisco.com
David Harrington Huawei Technologies USA EMail: dbharrington@comcast.net
David Harrington华为技术美国公司电子邮件：dbharrington@comcast.net
The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso, and all the other people who commented on various versions of this proposal.
作者希望感谢克里斯·朗维克、乔恩·卡拉斯、安德鲁·罗斯、阿尔伯特·米特斯、安东·奥克米安斯基、蒂娜·伯德、德文·科瓦奇、大卫·哈灵顿、莎伦·奇肖姆、理查德·格拉维曼、汤姆·佩奇、达多·科鲁西、克莱门特·马修、迪迪埃·达尔马索以及所有其他对本提案的不同版本发表评论的人。
[ANSI.X3-4.1968] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.
[ANSI.X3-4.1968]美国国家标准协会，“美国信息交换代码”，ANSI X3.41968。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne，G.，Ed.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年7月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 46462006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425]Fuyou，M.，Yuzhi，M.，和J.Salowey，“系统日志的TLS传输映射”，RFC 54252009年3月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426]Okmianski，A.，“通过UDP传输系统日志消息”，RFC 5426，2009年3月。
[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security Considerations", July 2005.
[UNICODE-TR36]Davis，M.和M.Suignard，“UNICODE安全考虑”，2005年7月。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164]Lonvick，C.，“BSD系统日志协议”，RFC31642001年8月。
Information in this section is given as an aid to implementers. While this information is considered to be helpful, it is not normative. As such, an implementation is NOT REQUIRED to follow it in order to claim compliance to this specification.
本节中的信息是为实施者提供的帮助。虽然这些信息被认为是有帮助的，但并不规范。因此，实现不需要遵循它来声明符合本规范。
While BSD syslog is in widespread use, its format has never been formally standardized. [RFC3164] describes observed formats. It is an Informational RFC, and practice shows that there are many different implementations. Research during creation of this document showed that there is very little in common between different syslog implementations on different platforms. The only thing that all of them agree upon is that messages start with "<" PRIVAL ">". Other than that, legacy syslog messages are not formatted in a consistent way. Consequently, RFC 3164 describes no specific elements inside a syslog message. It states that any message destined to the syslog UDP port must be treated as a syslog message, no matter what its format or content is.
虽然BSD系统日志被广泛使用，但其格式从未被正式标准化。[RFC3164]描述了观察到的格式。这是一个信息RFC，实践表明有许多不同的实现。本文档创建期间的研究表明，不同平台上的不同syslog实现之间几乎没有共同之处。所有人都同意的唯一一点是，消息以“<”PRIVAL“>”开头。除此之外，遗留系统日志消息的格式不一致。因此，RFC3164在syslog消息中没有描述任何特定元素。它指出，任何发送到syslog UDP端口的消息都必须被视为syslog消息，无论其格式或内容如何。
This document retains the PRI value syntax and semantics. This will allow legacy syslog implementations to put messages generated by syslog applications compliant to this specification into the right bins.
本文档保留PRI值语法和语义。这将允许遗留系统日志实现将符合此规范的系统日志应用程序生成的消息放入正确的容器中。
Most existing implementations support UDP as the transport protocol for syslog. This specification supports UDP transport, but does not recommend it. Deployment of the required TLS support is recommended. Additional transport protocols may be used.
大多数现有实现都支持UDP作为syslog的传输协议。此规范支持UDP传输，但不推荐使用。建议部署所需的TLS支持。可以使用附加的传输协议。
RFC 3164 describes relay behavior. This document does not specify relay behavior. This might be done in a separate document.
RFC3164描述了继电器的行为。本文档未指定中继行为。这可以在单独的文档中完成。
The TIMESTAMP described in RFC 3164 offers less precision than the timestamp specified in this document. It also lacks the year and time zone information. If a message formatted according to this document needs to be reformatted to be in RFC 3164 format, it is suggested that the originator's local time zone be used, and the time zone information and the year be dropped. If an RFC 3164 formatted message is received and must be transformed to be compliant to this document, the current year should be added and the time zone of the relay or collector MAY be used.
RFC 3164中描述的时间戳提供的精度低于本文档中指定的时间戳。它还缺少年份和时区信息。如果根据本文件格式化的消息需要重新格式化为RFC 3164格式，建议使用发起者的本地时区，并删除时区信息和年份。如果收到RFC 3164格式的消息，并且必须进行转换以符合本文件的要求，则应添加当前年份，并可使用继电器或采集器的时区。
The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations.
RFC 3164中的主机名没有那么具体，但本文档仍然支持此格式作为备用主机名表示形式之一。
The MSG part of the message is described as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into APP-NAME, PROCID, and MSGID. This does not totally resemble the usage of TAG, but provides the same functionality for most of the cases.
消息的MSG部分在RFC 3164中描述为标记和内容。在本文档中，MSG是RFC3164中所称的内容。标记现在是标题的一部分，但不是单个字段。标记已拆分为APP-NAME、PROCID和MSGID。这并不完全类似于标签的用法，但为大多数情况提供了相同的功能。
In RFC 3164, STRUCTURED-DATA was not described. If a message compliant with this document contains STRUCTURED-DATA and must be reformatted according to RFC 3164, the STRUCTURED-DATA simply becomes part of the RFC 3164 CONTENT free-form text.
在RFC 3164中，未描述结构化数据。如果符合本文档的消息包含结构化数据，并且必须根据RFC 3164重新格式化，则结构化数据将成为RFC 3164内容自由格式文本的一部分。
In general, this document tries to provide an easily parseable header with clear field separations, whereas traditional BSD syslog suffers from some historically developed, hard to parse field separation rules.
一般来说，本文档试图提供一个易于解析的标题，其中包含清晰的字段分隔，而传统的BSD系统日志存在一些历史上开发的、难以解析的字段分隔规则。
Implementers should note the message size limitations outlined in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length). This ensures the data will be seen by the collector or relay even if a transport receiver at a relay on the message path truncates the message.
实施者应注意第6.1节中概述的消息大小限制，并尝试在消息的早期保留最重要的数据（在最小保证长度内）。这确保了即使消息路径上的中继器处的传输接收器截断消息，收集器或中继器也能看到数据。
The reason syslog transport receivers need only support receiving up to and including 480 octets has, among other things, to do with difficult delivery problems in a broken network. Syslog messages may use a UDP transport mapping with this 480 octet restriction to avoid session overhead and message fragmentation. In a network with problems, the likelihood of getting one single-packet message delivered successfully is higher than getting two message fragments delivered successfully. Therefore, using a larger size may prevent the operator from getting some critical information about the problem, whereas using small messages might get that information to the operator. It is recommended that messages intended for troubleshooting purposes should not be larger than 480 octets. To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more than 480 octets. This behavior is very rare and may no longer be an issue.
syslog传输接收器只需要支持接收多达480个八位字节（包括480个八位字节）的原因，除其他外，与在断开的网络中难以解决的交付问题有关。Syslog消息可以使用具有此480八位字节限制的UDP传输映射，以避免会话开销和消息碎片。在有问题的网络中，成功交付一个数据包消息的可能性高于成功交付两个消息片段的可能性。因此，使用较大的大小可能会阻止操作员获取有关问题的一些关键信息，而使用较小的消息可能会将这些信息发送给操作员。建议用于故障排除的消息不应大于480个八位字节。为了进一步加强这一点，还观察到一些UDP实现通常不支持超过480个八位字节的消息大小。这种行为非常罕见，可能不再是问题。
There are other use cases where syslog messages are used to transmit inherently lengthy information, e.g., audit data. By not enforcing any upper limit on the message size, syslog applications can be implemented with any size needed and still be compliant with this document. In such cases, it is the operator's responsibility to
还有一些其他用例使用syslog消息来传输固有的冗长信息，例如审计数据。通过不对消息大小施加任何上限，syslog应用程序可以使用所需的任何大小来实现，并且仍然符合本文档的要求。在这种情况下，运营商有责任
ensure that all components in a syslog infrastructure support the required message sizes. Transport mappings may recommend specific message size limits that must be implemented to be compliant.
确保syslog基础结构中的所有组件都支持所需的消息大小。传输映射可能会建议必须实现的特定消息大小限制，以符合要求。
Implementers are reminded that the message length is specified in octets. There is a potentially large difference between the length in characters and the length in octets for UTF-8 strings.
提醒实现者消息长度是以八位字节为单位指定的。UTF-8字符串的字符长度和八位字节长度之间可能存在较大差异。
It must be noted that the IPv6 MTU is about 2.5 times 480. An implementation targeted towards an IPv6-only environment might thus assume this as a larger minimum size.
必须注意的是，IPv6 MTU约为480的2.5倍。因此，针对纯IPv6环境的实现可能会假定这是一个更大的最小大小。
This section describes guidelines for using Severity as outlined in Section 6.2.1.
本节描述了使用第6.2.1节中概述的严重性的指南。
All implementations should try to assign the most appropriate severity to their message. Most importantly, messages designed to enable debugging or testing of software should be assigned Severity 7. Severity 0 should be reserved for messages of very high importance (like serious hardware failures or imminent power failure). An implementation may use Severities 0 and 7 for other purposes if this is configured by the administrator.
所有实现都应尝试为其消息分配最适当的严重性。最重要的是，设计用于调试或测试软件的消息应被指定为严重级别7。严重性0应保留给非常重要的消息（如严重硬件故障或即将发生的电源故障）。如果由管理员配置，则实现可能会将严重性0和7用于其他目的。
Because severities are very subjective, a relay or collector should not assume that all originators have the same definition of severity.
由于严重性是非常主观的，中继或收集器不应假定所有发端具有相同的严重性定义。
The TIMESTAMP described in Section 6.2.3 supports fractional seconds. This provides grounds for a very common coding error, where leading zeros are removed from the fractional seconds. For example, the TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as "2003-10-11T22:13:14.3". This would indicate 300 milliseconds instead of the 3 milliseconds actually meant.
第6.2.3节中描述的时间戳支持分数秒。这为一个非常常见的编码错误提供了依据，其中前导零从小数秒中删除。例如，时间戳“2003-10-11T22:13:14.003”可能被错误地写为“2003-10-11T22:13:14.3”。这将指示300毫秒，而不是实际指的3毫秒。
Names are used at various places in this document, for example for SD-IDs and PARAM-NAMEs. This document uses "lower camel case" consistently. With that, each name begins with a lower case letter and each new embedded word starts with an upper case letter, with no hyphen or other delimiter. An example of this is "timeQuality".
在本文档的不同位置使用名称，例如SD ID和PARAM名称。本文档始终使用“小写”。这样，每个名称都以小写字母开头，每个新嵌入的单词都以大写字母开头，没有连字符或其他分隔符。这方面的一个例子是“时间质量”。
While an implementation is free to use any other case convention for experimental names, it is suggested that the case convention outlined above is followed.
虽然一个实现可以自由地对实验名称使用任何其他case约定，但建议遵循上面概述的case约定。
In Section 6.2.3, the NILVALUE has been allowed for usage by originators without knowledge of time. This is done to support a special case when a syslog application is not aware of time at all. It can be argued whether such a syslog application can actually be found in today's IT infrastructure. However, discussion has indicated that those things may exist in practice and as such there should be a guideline established for this case.
在第6.2.3节中，允许发起人在不知道时间的情况下使用NILVALUE。这样做是为了支持syslog应用程序根本不知道时间的特殊情况。在今天的It基础设施中是否真的可以找到这样一个系统日志应用程序，这是有争议的。然而，讨论表明，这些事情在实践中可能存在，因此，应该为这种情况制定一项准则。
However, an implementation SHOULD emit a valid TIMESTAMP if the underlying operating system, programming system, and hardware supports a clock function. A proper TIMESTAMP should be emitted even if it is difficult to obtain the system time. The NILVALUE should only be used when it is actually impossible to obtain time information. This rule should not be used as an excuse for lazy implementations.
但是，如果底层操作系统、编程系统和硬件支持时钟功能，则实现应该发出有效的时间戳。即使难以获得系统时间，也应发出适当的时间戳。只有在实际无法获取时间信息时，才应使用NILVALUE。此规则不应被用作懒惰实现的借口。
It is recommended that the value of "0" be the default for the "tzKnown" (Section 7.1.1) parameter. It should only be changed to "1" after the administrator has specifically configured the time zone. The value "1" may be used as the default if the underlying operating system provides accurate time zone information. It is still advised that the administrator consider the correctness of the time zone information.
建议“tzKnown”（第7.1.1节）参数的默认值为“0”。只有在管理员专门配置时区后，才能将其更改为“1”。如果基础操作系统提供准确的时区信息，则可以使用值“1”作为默认值。仍然建议管理员考虑时区信息的正确性。
It is important not to create a false impression of accuracy with the timeQuality SD-ID (Section 7.1). An originator should only indicate a given accuracy if it actually knows it is within these bounds. It is generally assumed that the originator gains this in-depth knowledge through operator configuration. By default, an accuracy should not be provided.
重要的是不要对timeQuality SD-ID（第7.1节）的准确性产生错误印象。如果发起者确实知道某个给定的准确度在这些范围内，则发起者只应指出该准确度。一般认为，发起人通过操作员配置获得这一深入知识。默认情况下，不应提供精度。
This document specifies that SD-PARAMS must always be encoded in UTF-8. Other encodings of the message in the MSG portion, including ASCIIPRINT, are not permitted by a device conforming to this specification. There are two cases that need to be addressed here. First, a syslog application conforming to this specification may not be able to ascertain that the information given to it from an originator is encoded in UTF-8. If it cannot determine that with certainty, the syslog application may choose to not incorporate the BOM in the MSG. If the syslog application has a good indication that the content of the message is encoded in UTF-8, then it should include the BOM. In the second case, a syslog relay may be
本文件规定SD-PARAMS必须始终以UTF-8编码。符合本规范的设备不允许MSG部分中消息的其他编码，包括ASCIIPRINT。这里有两个案例需要解决。首先，符合本规范的系统日志应用程序可能无法确定发起者提供给它的信息是否以UTF-8编码。如果无法确定，syslog应用程序可以选择不将BOM合并到MSG中。如果syslog应用程序很好地指示消息的内容是以UTF-8编码的，那么它应该包括BOM。在第二种情况下，可能需要一个syslog中继
forwarding a message from a device that does not conform to this specification. In that case, the device would likely not include the BOM unless it has ascertained that the received message was encoded in UTF-8.
从不符合此规范的设备转发消息。在这种情况下，设备很可能不包括BOM，除非它已经确定接收到的消息是用UTF-8编码的。
Author's Address
作者地址
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld，BW 97950德国
EMail: rgerhards@adiscon.com
EMail: rgerhards@adiscon.com