星期六, 12月 29, 2018

RFC 5424 Syslog Message Format

廣為使用的 syslog 來自 BSD,訊息格式並沒有標準化,共通點只有都是以「<數字>」開始。RFC 3164 只是說明觀察到的格式,認定送到 syslog UDP port (514) 的封包都是 syslog 訊息。

RFC 5424ANBF 定義了格式:
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>VERSIONPRIVAL 是優先值數字 = 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
0kernel messages
1user-level messages
2mail system
3system daemons
4security/authorization messages
5messages generated internally by syslogd
6line printer subsystem
7network news subsystem
8UUCP subsystem
9clock daemon
10security/authorization messages
11FTP daemon
12NTP subsystem
13log audit
14log alert
15clock daemon (note 2)
16local use 0 (local0)
17local use 1 (local1)
18local use 2 (local2)
19local use 3 (local3)
20local use 4 (local4)
21local use 5 (local5)
22local use 6 (local6)
23local use 7 (local7)
數值Severity
0Emergency: system is unusable
1Alert: action must be taken immediately
2Critical: critical conditions
3Error: error conditions
4Warning: warning conditions
5Notice: normal but significant condition
6Informational: informational messages
7Debug: 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 沒有 (可能會放在不同文件)

沒有留言:

張貼留言