6. Syslog Message Format (Syslog 消息格式)
Syslog 消息具有以下 ABNF [RFC5234] 定义:
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; range 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; not starting with BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; UTF-8 string as specified
; in RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
6.1. Message Length (消息长度)
Syslog 消息大小限制由使用的 Syslog 传输映射决定。本身没有上限。每个传输映射定义所需的最小最大消息长度支持，并且最小最大值必须 (MUST) 至少为 480 个八位字节长度。
任何传输接收器必须 (MUST) 能够接受长度不超过 480 个八位字节的消息。所有传输接收器实现应该 (SHOULD) 能够接受长度不超过 2048 个八位字节的消息。传输接收器可以 (MAY) 接收长度大于 2048 个八位字节的消息。如果传输接收器接收到长度大于其支持的消息，传输接收器应该 (SHOULD) 截断有效负载 (Payload)。或者，它可以 (MAY) 丢弃该消息。
如果传输接收器截断消息，截断必须 (MUST) 发生在消息的末尾。截断后，消息可能 (MAY) 包含无效的 UTF-8 编码或无效的 STRUCTURED-DATA。在这种情况下，传输接收器可以 (MAY) 丢弃该消息或可以 (MAY) 尝试尽可能多地处理。
6.2. HEADER (报文头)
HEADER 中使用的字符集必须 (MUST) 是 [RFC5234] 中描述的八位字段中的七位 ASCII。这些是 "USA Standard Code for Information Interchange" [ANSI.X3-4.1968] 中定义的 ASCII 代码。
报文头格式旨在提供与旧的基于 BSD 的 Syslog 的一些互操作性。有关详细信息，请参见附录 A.1。
6.2.1. PRI (优先级)
PRI 部分必须 (MUST) 有三个、四个或五个字符，并将用尖括号作为第一个和最后个字符进行绑定。PRI 部分以前导 "<" ("less-than" 字符，%d60) 开始，后跟一个数字，后跟 ">" ("greater-than" 字符，%d62)。这些尖括号中包含的数字称为优先级值 (Priority value, PRIVAL)，表示 Facility (设施) 和 Severity (严重性)。优先级值由一个、两个或三个十进制整数 (ABNF DIGITS) 组成，使用 %d48 (表示 "0") 到 %d57 (表示 "9") 的值。
Facility 和 Severity 值不是规范性的，但经常使用。它们在以下表格中描述，仅供参考。Facility 值必须 (MUST) 在 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)
表 1. Syslog 消息设施 (Syslog Message Facilities)
每个消息优先级还有一个十进制严重性级别指示符 (Severity Level Indicator)。这些在以下表格中与它们的数值一起描述。严重性值必须 (MUST) 在 0 到 7 的范围内（包括 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
表 2. Syslog 消息严重性 (Syslog Message Severities)
优先级值的计算方法是首先将 Facility 编号乘以 8，然后加上 Severity 的数值。例如，具有 Emergency (Severity=0) 的内核消息 (Facility=0) 的优先级值为 0。同样，具有 Notice (Severity=5) 的 "local use 4" 消息 (Facility=20) 的优先级值为 165。在 Syslog 消息的 PRI 中，这些值将分别放置在尖括号之间，即 <0> 和 <165>。只有当优先级值为 "0" 时，值 "0" 才跟在 "<" 后面。否则，前导 "0" 禁止 (MUST NOT) 使用。
6.2.2. VERSION (版本)
VERSION 字段表示 Syslog 协议规范的版本。对于更改 HEADER 格式任何部分的任何新 Syslog 协议规范，版本号必须 (MUST) 递增。更改包括添加或删除字段，或更改现有字段的语法或语义。本文档使用的 VERSION 值为 "1"。VERSION 值由 IANA 分配 (第 9.1 节)，通过 [RFC5226] 中描述的标准行动方法 (Standards Action Method)。
6.2.3. TIMESTAMP (时间戳)
TIMESTAMP 字段是源自 [RFC3339] 的形式化时间戳 (Formalized Timestamp)。
虽然 [RFC3339] 允许多种语法，但本文档施加了进一步的限制。TIMESTAMP 值必须 (MUST) 遵循以下限制:
-
此语法中的 "T" 和 "Z" 字符必须 (MUST) 是大写。
-
必须 (REQUIRED) 使用 "T" 字符。
-
禁止 (MUST NOT) 使用闰秒 (Leap Seconds)。
如果发起者的时钟精度和性能允许，发起者应该 (SHOULD) 包括 TIME-SECFRAC。第 7.1 节中描述的 "timeQuality" SD-ID 允许发起者指定时间戳的准确性和可信度。
如果 Syslog 应用程序无法获取系统时间，则 Syslog 应用程序必须 (MUST) 使用 NILVALUE 作为 TIMESTAMP。
6.2.3.1. Examples (示例)
示例 1
1985-04-12T23:20:50.52Z
这表示 1985 年 4 月 12 日 UTC 时间 23 小时后 20 分 50.52 秒。
示例 2
1985-04-12T19:20:50.52-04:00
这表示与示例 1 相同的时间，但以美国东部标准时间 (US Eastern Standard Time) 表示（遵守夏令时 (Daylight Savings Time)）。
示例 3
2003-10-11T22:14:15.003Z
这表示 2003 年 10 月 11 日晚上 10:14:15，下一秒的 3 毫秒。时间戳采用 UTC。时间戳提供毫秒分辨率 (Millisecond Resolution)。创建者实际上可能具有更好的分辨率，但仅为秒的小数部分提供三位数字并不能告诉我们。
示例 4
2003-08-24T05:14:15.000003-07:00
这表示 2003 年 8 月 24 日上午 05:14:15，下一秒的 3 微秒。微秒分辨率 (Microsecond Resolution) 由 TIME-SECFRAC 中的额外数字表示。时间戳指示其本地时间比 UTC 晚 -7 小时。此时间戳可能是在夏令时期间在美国太平洋时区创建的。
示例 5 - 无效的 TIMESTAMP
2003-08-24T05:14:15.000000003-07:00
此示例几乎与示例 4 相同，但它以纳秒为单位指定 TIME-SECFRAC。这导致 TIME-SECFRAC 长度超过允许的 6 位数字，从而使其无效。
6.2.4. HOSTNAME (主机名)
HOSTNAME 字段标识最初发送 Syslog 消息的机器。
HOSTNAME 字段应该 (SHOULD) 包含发起者的主机名和域名，格式如 STD 13 [RFC1034] 中指定的。此格式在本文档中称为完全限定域名 (Fully Qualified Domain Name, FQDN)。
实际上，并非所有 Syslog 应用程序都能够提供 FQDN。因此，HOSTNAME 中也可以 (MAY) 存在其他值。本文档为在这种情况下使用其他值提供了规定。Syslog 应用程序应该 (SHOULD) 首先提供最具体的可用值。HOSTNAME 字段内容的优先顺序如下:
-
FQDN
-
静态 IP 地址 (Static IP address)
-
主机名 (hostname)
-
动态 IP 地址 (Dynamic IP address)
-
NILVALUE
如果使用 IPv4 地址，它必须 (MUST) 采用 STD 13 [RFC1035] 中使用的点分十进制表示法 (Dotted Decimal Notation) 的格式。如果使用 IPv6 地址，必须 (MUST) 使用 [RFC4291] 第 2.2 节中描述的有效文本表示 (Valid Textual Representation)。
Syslog 应用程序应该 (SHOULD) 在 HOSTNAME 字段中始终如一地使用相同的值，时间越长越好。
只有当 Syslog 应用程序无法获取其真实主机名时，才应该 (SHOULD) 使用 NILVALUE。这种情况被认为是极不可能的。
6.2.5. APP-NAME (应用名称)
APP-NAME 字段应该 (SHOULD) 标识发起消息的设备或应用程序。它是一个没有进一步语义的字符串。它旨在用于在中继或收集器上过滤消息。
当 Syslog 应用程序不知道其 APP-NAME 或无法提供该信息时，可以 (MAY) 使用 NILVALUE。可能是设备由于本地策略决定 (Local Policy Decision) 而无法提供该信息，或者因为该信息在设备上不可用或不适用。
此字段可以 (MAY) 由操作员分配 (Operator-Assigned)。
6.2.6. PROCID (进程ID)
PROCID 是包含在消息中的值，除了值的更改表示 Syslog 报告中出现了不连续性 (Discontinuity) 之外，没有可互操作的含义。该字段没有任何特定的语法或语义；该值取决于实现和/或由操作员分配 (Implementation-Dependent and/or Operator-Assigned)。当没有提供值时，可以 (MAY) 使用 NILVALUE。
PROCID 字段通常用于提供与 Syslog 系统相关联的进程名称 (Process Name) 或进程 ID (Process ID)。当进程 ID 不可用时，可能会使用 NILVALUE。在没有任何操作系统进程 ID 的嵌入式系统上，PROCID 可能是重启 ID (Reboot ID)。
PROCID 可以使日志分析器 (Log Analyzers) 通过检测 Syslog 进程 ID 的更改来检测 Syslog 报告中的不连续性。但是，PROCID 不是重新启动的进程的可靠标识，因为重新启动的 Syslog 进程可能被分配与先前 Syslog 进程相同的进程 ID。
PROCID 也可用于标识哪些消息属于一组消息。例如，SMTP 邮件传输代理可能将其 SMTP 事务 ID 放入 PROCID 中，这将允许收集器或中继根据 SMTP 事务对消息进行分组。
6.2.7. MSGID (消息ID)
MSGID 应该 (SHOULD) 标识消息的类型 (Type of Message)。例如，防火墙可能对传入 TCP 流量使用 MSGID "TCPIN"，对传出 TCP 流量使用 MSGID "TCPOUT"。具有相同 MSGID 的消息应该反映相同语义的事件。MSGID 本身是一个没有进一步语义的字符串。它旨在用于在中继或收集器上过滤消息。
当 Syslog 应用程序不提供或无法提供任何值时，应该 (SHOULD) 使用 NILVALUE。
此字段可以 (MAY) 由操作员分配。
6.3. STRUCTURED-DATA (结构化数据)
STRUCTURED-DATA 提供了一种以定义良好、易于解析和可解释的数据格式表达信息的机制。有多种使用场景。例如，它可以表达关于 Syslog 消息的元信息 (Meta-Information) 或应用程序特定的信息，例如流量计数器或 IP 地址。
STRUCTURED-DATA 可以包含零个、一个或多个结构化数据元素 (Structured Data Elements)，在本文档中称为 "SD-ELEMENT"。
在零个结构化数据元素的情况下，STRUCTURED-DATA 字段必须 (MUST) 包含 NILVALUE。
STRUCTURED-DATA 中使用的字符集必须 (MUST) 是 [RFC5234] 中描述的八位字段中的七位 ASCII。这些是 "USA Standard Code for Information Interchange" [ANSI.X3-4.1968] 中定义的 ASCII 代码。例外是 PARAM-VALUE 字段（参见第 6.3.3 节），其中必须 (MUST) 使用 UTF-8 编码。
收集器可以 (MAY) 忽略格式错误的 STRUCTURED-DATA 元素。中继必须 (MUST) 转发格式错误的 STRUCTURED-DATA，不做任何更改。
6.3.1. SD-ELEMENT (结构化数据元素)
SD-ELEMENT 由名称和参数名称-值对 (Parameter Name-Value Pairs) 组成。该名称称为 SD-ID。名称-值对称为 "SD-PARAM"。
6.3.2. SD-ID (结构化数据标识符)
SD-ID 区分大小写，唯一标识 SD-ELEMENT 的类型和目的。同一个 SD-ID 禁止 (MUST NOT) 在消息中存在多次。
SD-ID 名称有两种格式:
-
不包含 at 符号 ("@", ABNF %d64) 的名称保留由 IETF Review 分配，如 BCP26 [RFC5226] 中所述。目前，这些是第 7 节中定义的名称。只有在首先向 IANA 注册后，此格式的名称才有效。注册的名称禁止 (MUST NOT) 包含 at 符号 ('@', ABNF %d64)、等号 ('=', ABNF %d61)、右括号 (']', ABNF %d93)、引号字符 ('"', ABNF %d34)、空格或控制字符 (ASCII 代码 127 以及代码 32 或更小)。
-
任何人都可以使用格式
name@<private enterprise number>的名称定义其他 SD-ID，例如 "ourSDID@32473"。at 符号之前的部分的格式未指定；但是，这些名称必须 (MUST) 是可打印的 US-ASCII 字符串，并且禁止 (MUST NOT) 包含 at 符号 ('@', ABNF %d64)、等号 ('=', ABNF %d61)、右括号 (']', ABNF %d93)、引号字符 ('"', ABNF %d34)、空格或控制字符。at 符号后面的部分必须 (MUST) 是第 7.2.2 节中指定的私有企业编号 (Private Enterprise Number)。请注意，在整个文档中，值 32473 用于所有私有企业编号。IANA 已保留此值作为文档中使用的示例编号。实施者需要使用自己的私有企业编号作为 enterpriseId 参数，以及在创建本地可扩展的 SD-ID 名称时。
6.3.3. SD-PARAM (结构化数据参数)
每个 SD-PARAM 由名称（称为 PARAM-NAME）和值（称为 PARAM-VALUE）组成。
PARAM-NAME 区分大小写。IANA 控制所有 PARAM-NAME，但名称包含 at 符号的 SD-ID 中的 PARAM-NAME 除外。PARAM-NAME 范围在特定 SD-ID 内。因此，包含在两个不同 SD-ID 中的同名 PARAM-NAME 值不相同。
为了支持国际字符 (International Characters)，PARAM-VALUE 字段必须 (MUST) 使用 UTF-8 编码。Syslog 应用程序可以 (MAY) 发出任何有效的 UTF-8 序列。Syslog 应用程序必须 (MUST) 接受 "最短形式 (Shortest Form)" 的任何有效 UTF-8 序列。如果 PARAM-VALUE 中存在控制字符，它禁止 (MUST NOT) 失败。Syslog 应用程序可以 (MAY) 修改包含控制字符的消息（例如，通过将值为 0 (USASCII NUL) 的八位字节更改为四个字符 "#000"）。出于 UNICODE TR36 [UNICODE-TR36] 第 3.1 节中概述的原因，发起者必须 (MUST) 以 "最短形式" 编码消息，收集器或中继禁止 (MUST NOT) 解释 "非最短形式 (Non-Shortest Form)" 的消息。
在 PARAM-VALUE 内部，字符 '"' (ABNF %d34)、'\' (ABNF %d92) 和 ']' (ABNF %d93) 必须 (MUST) 被转义。这是避免解析错误所必需的。转义 ']' 并非严格必要，但本规范要求 (REQUIRED) 这样做以避免 Syslog 应用程序实现错误。这三个字符中的每一个必须 (MUST) 分别转义为 '\"'、'\\'、'\]'。反斜杠用于控制字符转义，与其在 Syslog 消息其他部分以及传统 Syslog 中用于转义的用法保持一致。
反斜杠 ('\') 后面没有跟随所述三个字符中的任何一个，被认为是无效的转义序列 (Invalid Escape Sequence)。在这种情况下，反斜杠必须 (MUST) 被视为常规反斜杠，后面的字符被视为常规字符。因此，无效序列禁止 (MUST NOT) 被更改。
SD-PARAM 可以 (MAY) 在 SD-ELEMENT 内部重复多次。
6.3.4. Change Control (变更控制)
一旦定义了 SD-ID 和 PARAM-NAME，这些对象的语法和语义禁止 (MUST NOT) 被更改。如果希望更改现有对象，必须 (MUST) 创建新的 SD-ID 或 PARAM-NAME，并且旧的保持不变。可以 (MAY) 将可选的 (OPTIONAL) PARAM-NAME 添加到现有 SD-ID。
6.3.5. Examples (示例)
本节中的所有示例仅显示消息的结构化数据部分。示例应被视为在一行上。为了可读性，它们在本文档中被包装在多行上。每个示例后面都给出了描述。
示例 1 - 有效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"]
此示例是一个结构化数据元素，具有类型为 "exampleSDID@32473" 的非 IANA 控制的 SD-ID，它有三个参数。
示例 2 - 有效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
这与示例 1 相同，但有第二个结构化数据元素。请注意，结构化数据元素紧跟在第一个元素之后（它们之间没有 SP）。
示例 3 - 无效
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]
这几乎与示例 2 相同，但它有一个微妙的错误——两个结构化数据元素之间有一个 SP 字符 ("]SP[")。这是无效的。它将导致 STRUCTURED-DATA 字段在第一个元素后结束。第二个元素将被解释为 MSG 字段的一部分。
示例 4 - 无效
[ exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
此示例几乎与示例 2 相同。它有另一个微妙的错误——SP 字符出现在初始括号之后。结构化数据元素 SD-ID 必须紧跟在起始括号之后，因此 SP 字符使 STRUCTURED-DATA 无效。Syslog 应用程序可以 (MAY) 丢弃此消息。
示例 5 - 有效
[sigSig ver="1" rsID="1234" ... signature="..."]
示例 5 是一个有效示例。它显示了一个假设的 IANA 分配的 SD-ID。省略号表示缺失的内容，为简洁起见，该示例中已省略该内容。
6.4. MSG (消息体)
MSG 部分包含提供有关事件信息的自由格式消息 (Free-Form Message)。
MSG 中使用的字符集应该 (SHOULD) 是 UNICODE，使用 [RFC3629] 中指定的 UTF-8 编码。如果 Syslog 应用程序无法以 Unicode 编码 MSG，它可以 (MAY) 使用任何其他编码。
Syslog 应用程序应该 (SHOULD) 避免低于 32 的八位字节值（传统的 US-ASCII 控制字符范围，DEL 除外）。这些值是合法的，但 Syslog 应用程序可以 (MAY) 在接收时修改这些字符。例如，它可能将它们更改为转义序列（例如，值 0 可能更改为 "\0"）。Syslog 应用程序不应该 (SHOULD NOT) 修改任何其他八位字节值。
如果 Syslog 应用程序以 UTF-8 编码 MSG，则字符串必须 (MUST) 以 Unicode 字节顺序掩码 (Byte Order Mask, BOM) 开始，对于 UTF-8，BOM 是 ABNF %xEF.BB.BF。Syslog 应用程序必须 (MUST) 以 "最短形式" 编码，并且可以 (MAY) 使用任何有效的 UTF-8 序列。
如果 Syslog 应用程序正在处理以 BOM 开头的 MSG，并且 MSG 包含非最短形式的 UTF-8，则出于 [UNICODE-TR36] 第 3.1 节中概述的原因，MSG 禁止 (MUST NOT) 被解释为以 UTF-8 编码。关于此的指导在附录 A.8 中给出。
此外，根据 UNICODE TR36 [UNICODE-TR36]，Syslog 应用程序禁止 (MUST NOT) 解释 "非最短形式" 的消息。它禁止 (MUST NOT) 解释无效的 UTF-8 序列。
6.5. Examples (示例)
以下是有效 Syslog 消息的示例。每个示例的描述可以在其下方找到。这些示例基于 [RFC3164] 中的类似示例，读者可能会熟悉。否则无法打印的 Unicode BOM 在示例中表示为 "BOM"。
示例 1 - 没有 STRUCTURED-DATA
`<34>`1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
- BOM'su root' failed for lonvick on /dev/pts/8
在此示例中，VERSION 为 1，Facility 的值为 4。Severity 为 2。消息是在 2003 年 10 月 11 日晚上 10:14:15 UTC，下一秒的 3 毫秒创建的。消息源自一台标识自己为 "mymachine.example.com" 的主机。APP-NAME 是 "su"，PROCID 未知。MSGID 是 "ID47"。MSG 是 "'su root' failed for lonvick..."，以 UTF-8 编码。编码由 BOM 定义。消息中没有 STRUCTURED-DATA；这由 STRUCTURED-DATA 字段中的 "-" 指示。
示例 2 - 没有 STRUCTURED-DATA
``<165>``1 2003-08-24T05:14:15.000003-07:00 192.0.2.1
myproc 8710 - - %% It's time to make the do-nuts.
在此示例中，VERSION 再次为 1。Facility 为 20，Severity 为 5。消息是在 2003 年 8 月 24 日上午 5:14:15，UTC 偏移 -7 小时，下一秒的 3 微秒创建的。HOSTNAME 是 "192.0.2.1"，因此 Syslog 应用程序不知道其 FQDN，而是使用其 IPv4 地址之一。APP-NAME 是 "myproc"，PROCID 是 "8710"（例如，这可能是 UNIX PID）。消息中没有 STRUCTURED-DATA；这由 STRUCTURED-DATA 字段中的 "-" 指示。没有特定的 MSGID，这由 MSGID 字段中的 "-" 指示。消息是 "%% It's time to make the do-nuts."。由于缺少 Unicode BOM，Syslog 应用程序不知道 MSG 部分的编码。
示例 3 - 包含 STRUCTURED-DATA
``<165>``1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
此示例是在示例 1 之后建模的。但是，这次它包含 STRUCTURED-DATA，一个值为 "[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]" 的单个元素。MSG 本身是 "An application event log entry..."。MSG 开头的 BOM 表示 UTF-8 编码。
示例 4 - 仅 STRUCTURED-DATA
``<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"]
此示例显示仅包含 STRUCTURED-DATA 而没有 MSG 部分的消息。这是一条有效的消息。