廣為使用的
syslog 來自 BSD，訊息格式並沒有標準化，共通點只有都是以「<數字>」開始。
RFC 3164 只是說明觀察到的格式，認定送到 syslog UDP port (514) 的封包都是 syslog 訊息。
RFC 5424 用
ANBF 定義了格式：
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = "<" PRIVAL ">" VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
STRUCTURED-DATA = "-" / 1*SD-ELEMENT
SD-ELEMENT = "[" ID *(SP NAME "=" %d34 VALUE %d34) "]"
依序包括下列以空白區隔的欄位：
- <PRIVAL>VERSION：PRIVAL 是優先值數字 = facility * 8 + severity。facility 值和 severity 值的表見下面。VERSION 是格式的版本，目前 = 1。
- TIMESTAMP：格式「為西元年-月-日T時:分:秒.fraction時區」，小數點後可有 6 位精度達微秒，可有時區。如不知道時間填「-」。RFC 3164 的時間精度較差、沒「年」和「時區」。
- HOSTNAME：可以是 FQDN、IP、主機名稱。在 RFC 3164 沒明確說明。
- APP-NAME：應用程式名稱。RFC 3164 的 TAG 大致分成 APP-NAME、PROCID、和 MSGID。
- PROCID：
- MSGID：
- STRUCTURED-DATA：可以是「-」或一個以上連續 [SD-ELEMENT] (之間沒空白)。RFC 3164 沒有這部份。
- MSG：之後可選擇性加空白後放任意資訊 (MSG)。相當於 RFC 3164 的 CONTENT。
例如：
<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...
可看到：
- PRIVAL 165 = 20 * 8 + 5，所以 facility 值 = 20，severity 值 = 5。
- VERSION = 1。
- TIMESTAMP 小數點後有 3 位，精度毫秒。Z 代表？？？。
- HOSTNAME 為 FQDN。
- APP-NAME 為 evntslog。
- PROCID 為 -
- MSGID 為 ID47
- 一個 SD-ELEMENT 由 [] 框起來，有一個 ID 和多個空白隔開的 NAME="VALUE" 參數。
- ID 和 NAME 是 1 ~ 32 字元 PRINTUSASCII，不含 '=', SP, ']', '"'。
- VALUE 是 utf-8 資料，但 '"', '\' 和 ']' 分別 escape 為 '\"', '\\', and '\]'。 Escape ']' 是為了避免 syslog 實作錯誤。'\' 之後不是這三個字元視為一般的 '\'。
- 可有多個 SD-ELEMENT，但 ID 不能重複。ID 有兩類：
- 不含「@」的 ID 要跟 IANA 註冊，目前有的見 Section 7。
- 可自行定義的格式是 name@<private enterprise number>, e.g., "ourSDID@32473"。private enterprise number 見 Section 7.2.2。
- MSG 任意訊息，開頭 BOM (實際上傳的是 utf-8 的 BOM 0xEF 0xBB 0xBF) 代表傳的是 utf-8 資料。如果不是 BOM 開頭則是其它編碼。小於 32 的字元是合法的，但可能被改變 (例如 0 可能被改為 "\0")，所以應該要避免。
| 數值 | Facility |
|---|
| 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) |
| 數值 | Severity |
|---|
| 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 |
sect6.1 訊息長度 sect6.1
...
A.2. Message Length
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.
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.
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
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.
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.
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.
參考
RFC 5424: The Syslog Protocl §6, Appendix A
延伸閱讀
- RFC 3164 有描述 relay 行為，RFC5424 沒有 (可能會放在不同文件)
