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.

Copyright(c)2009 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

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 ( Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびこのドキュメントの公開日(に発効するIETFドキュメントに関連するIETFトラストの法的規定の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

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標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。



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.


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.


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
      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
1. Introduction
1. はじめに

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.


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.


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.


This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field.

このドキュメントはRFC 3164を廃止します。RFC3164は、フィールドで見つかったいくつかの実装を説明する情報ドキュメントです。

2. Conventions Used in This Document
2. このドキュメントで使用される規則

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Definitions
3. 定義

Syslog utilizes three layers:


o "syslog content" is the management information contained in a syslog message.

o 「syslogコンテンツ」は、syslogメッセージに含まれる管理情報です。

o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.

o 「syslogアプリケーション」層は、syslogメッセージの生成、解釈、ルーティング、および格納を処理します。

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 「発信元」は、メッセージで伝達されるsyslogコンテンツを生成します。

o A "collector" gathers syslog content for further analysis.

o 「コレクター」は、さらに分析するためにsyslogコンテンツを収集します。

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 「トランスポート送信者」は、syslogメッセージを特定のトランスポートプロトコルに渡します。

o A "transport receiver" takes syslog messages from a specific transport protocol.

o 「トランスポートレシーバー」は、特定のトランスポートプロトコルからsyslogメッセージを受け取ります。

Diagram 1 shows the different entities separated by layer.


 +---------------------+    +---------------------+
 |  content            |    |  content            |
 |---------------------|    |---------------------|
 |  syslog application |    |  syslog application | (originator,
 |                     |    |                     |  collector, relay)
 |---------------------|    |---------------------|
 |  syslog transport   |    |  syslog transport   | (transport sender,
 |                     |    |                     | (transport receiver)
 +---------------------+    +---------------------+
           ^                          ^
           |                          |

Diagram 1. Syslog Layers

図1. Syslogレイヤー

4. Basic Principles
4. 基本理念

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 オリジネーター、リレー、コレクターの機能は、同じシステムに常駐できます。

4.1. Example Deployment Scenarios
4.1. 導入シナリオの例

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.


            +----------+         +---------+
            +----------+         +---------+
            +----------+         +-----+         +---------+
            +----------+         +-----+         +---------+
            +----------+     +-----+            +-----+     +---------+
            +----------+     +-----+            +-----+     +---------+
            +----------+         +-----+         +---------+
            |          |-+       +-----+         +---------+
            +----------+  \
                           \     +-----+         +---------+
                                 +-----+         +---------+
            +----------+         +---------+
            |          |-+       +---------+
            +----------+  \
                           \     +-----+         +---------+
                                 +-----+         +---------+
            +----------+         +-----+            +---------+
            |          |-+       +-----+        +---|         |
            +----------+  \                    /    +---------+
                           \     +-----+      /
            +----------+         +-----+                   +---------+
            |          |-+       +-----+                +--|         |
            +----------+  \                            /   +---------+
                           \     +------------+       /
                            \    |+----------+|      /
                             +->-||Relay     ||->---/
                                 |+----------||    /

Diagram 2. Some Possible Syslog Deployment Scenarios


5. Transport Layer Protocol
5. トランスポート層プロトコル

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メッセージのフォーマットを記述します。 Syslogトランスポートは他のドキュメントで定義されています。そのようなトランスポートの1つは[RFC5426]で定義されており、従来のUDPトランスポートと一致しています。 UDPトランスポートはこれまでsyslogメッセージの送信に使用されてきたため、このトランスポートは相互運用性を維持するために必要です。

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.


5.1. Minimum Required Transport Mapping
5.1. 最小限必要なトランスポートマッピング

All implementations of this specification MUST support a TLS-based transport as described in [RFC5425].


All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426].


It is RECOMMENDED that deployments of this specification use the TLS-based transport.


6. Syslog Message Format
6. Syslogメッセージ形式

The syslog message has the following ABNF [RFC5234] definition:

syslogメッセージには、次のABNF [RFC5234]定義があります。



                        SP APP-NAME SP PROCID SP MSGID
      PRI             = "<" PRIVAL ">"
      PRIVAL          = 1*3DIGIT ; range 0 .. 191
      PROCID          = NILVALUE / 1*128PRINTUSASCII
      MSGID           = NILVALUE / 1*32PRINTUSASCII
      DATE-MONTH      = 2DIGIT  ; 01-12
      DATE-MDAY       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                                ; month/year
      TIME-HOUR       = 2DIGIT  ; 00-23
      TIME-MINUTE     = 2DIGIT  ; 00-59
      TIME-SECOND     = 2DIGIT  ; 00-59
      TIME-SECFRAC    = "." 1*6DIGIT
      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
6.1. メッセージの長さ

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.


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.


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.


6.2. ヘッダ

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].


The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1.


6.2.1. PRI
6.2.1. PRI

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' 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").

PRI部分は3、4、または5文字である必要があり、最初と最後の文字として山括弧で囲まれます。 PRIの部分は、先頭が「<」(「より小」の文字、%d60)で始まり、その後に数字が続き、その後に「>」(「より大」の文字、%d62)が続きます。これらの山括弧内に含まれる数値は優先度値(PRIVAL)と呼ばれ、ファシリティと重大度の両方を表します。優先度の値は、%d48( "0"の場合)から%d57( "9"の場合)までの値を使用した1、2、または3つの10進整数(ABNF DIGITS)で構成されます。

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.


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. Syslogメッセージ機能

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.


Numerical Severity Code


0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages


Table 2. Syslog Message Severities

表2. Syslogメッセージの重大度

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を掛けてから、重大度の数値を加算して計算されます。たとえば、緊急度(Severity = 0)のカーネルメッセージ(Facility = 0)の優先度の値は0になります。また、通知の重要度(Severity)の「local use 4」メッセージ(Facility = 20)もあります。 = 5)の優先度値は165です。syslogメッセージのPRIでは、これらの値は山括弧の間にそれぞれ<0>および<165>として配置されます。 「<」の後に「0」の値が続くのは、「0」の優先順位値の場合のみです。それ以外の場合は、先頭の「0」を使用してはなりません。

6.2.2. VERSION
6.2.2. バージョン

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].

VERSIONフィールドは、syslogプロトコル仕様のバージョンを示します。 HEADER形式の一部を変更する新しいsyslogプロトコル仕様では、バージョン番号をインクリメントする必要があります。変更には、フィールドの追加または削除、または既存のフィールドの構文またはセマンティクスの変更が含まれます。このドキュメントでは、VERSION値に「1」を使用しています。 [RFC5226]で説明されているように、VERSION値は標準アクションメソッドを介してIANAによって割り当てられます(セクション9.1)。

6.2.3. タイムスタンプ

The TIMESTAMP field is a formalized timestamp derived from [RFC3339].


Whereas [RFC3339] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions:

[RFC3339]は複数の構文を考慮していますが、このドキュメントではさらに制限があります。 TIMESTAMP値は、次の制限に従う必要があります。

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.


A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time.

syslogアプリケーションがシステム時間を取得できない場合、syslogアプリケーションはNILVALUEをTIMESTAMPとして使用する必要があります。 Examples 例

Example 1




This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC.


Example 2



This represents the same time as in example 1, but expressed in US Eastern Standard Time (observing daylight savings time).


Example 3



2003/10/11:14:15.003 g

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.


Example 4



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.


Example 5 - An Invalid TIMESTAMP



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.


6.2.4. ホスト名

The HOSTNAME field identifies the machine that originally sent the syslog message.


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.

HOSTNAMEフィールドには、発信者のホスト名とドメイン名がSTD 13 [RFC1034]で指定された形式で含まれる必要があります(SHOULD)。この形式は、このドキュメントでは完全修飾ドメイン名(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を提供できるわけではありません。そのため、他の値もHOSTNAMEに存在する場合があります。このドキュメントでは、このような状況で他の値を使用するための規定を作成します。 Syslogアプリケーションは、最も具体的な利用可能な値を最初に提供する必要があります(SHOULD)。 HOSTNAMEフィールドの内容の優先順位は次のとおりです。



2. Static IP address

2. 静的IPアドレス

3. hostname

3. ホスト名

4. Dynamic IP address

4. 動的IPアドレス


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]で使用されているドット付き10進表記の形式にする必要があります。 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.

NILVALUE SHOULDは、syslogアプリケーションに実際のホスト名を取得する方法がない場合にのみ使用してください。この状況はほとんどあり得ないと考えられています。

6.2.5. APP-NAME
6.2.5. アプリ名

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.


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.


This field MAY be operator-assigned.


6.2.6. PROCID
6.2.6. 酸

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フィールドは、syslogシステムに関連付けられたプロセス名またはプロセスIDを提供するためによく使用されます。 NILVALUEは、プロセスIDが使用できない場合に使用される可能性があります。オペレーティングシステムプロセス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 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.


6.2.7. MSGID
6.2.7. MSGID

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はメッセージのタイプを識別する必要があります(SHOULD)。たとえば、ファイアウォールは、着信TCPトラフィックにMSGID "TCPIN"を使用し、発信TCPトラフィックにMSGID "TCPOUT"を使用する場合があります。同じMSGIDのメッセージは、同じセマンティクスのイベントを反映する必要があります。 MSGID自体は、それ以上のセマンティクスのない文字列です。これは、リレーまたはコレクターでメッセージをフィルタリングするためのものです。

The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value.

NILVALUE SHOULDは、syslogアプリケーションが値を提供しない場合、または提供できない場合に使用してください。

This field MAY be operator-assigned.


6.3. 構造化データ

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.


STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document.


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.


A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration.


6.3.1. SD要素

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".


6.3.2. SD-ID
6.3.2. SD-ID

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.


There are two formats for SD-ID names:


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 アットマーク( "@"、ABNF%d64)を含まない名前は、BCP26 [RFC5226]で説明されているように、IETFレビューによって割り当てられるように予約されています。現在、これらはセクション7で定義されている名前です。この形式の名前は、IANAに最初に登録された場合にのみ有効です。登録名には、アットマーク( '@'、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 「ourSDID @ 32473」のように、name @ <private enterprise number>という形式の名前を使用して、誰でも追加のSD-IDを定義できます。アットマークの前の部分の形式は指定されていません。ただし、これらの名前は印刷可能なUS-ASCII文字列である必要があり、アットマーク( '@'、ABNF%d64)、等号( '='、ABNF%d61)、右中かっこ( ']を含めることはできません'、ABNF%d93)、引用文字(' "'、ABNF%d34)、空白、または制御文字。アットマークに続く部分は、セクション7.2.2で指定されているように、民間の企業番号である必要があります。このドキュメント全体で、32473の値はすべてのプライベートエンタープライズ番号に使用されます。この値は、ドキュメントでサンプル番号として使用するためにIANAによって予約されています。実装者は、enterpriseIdパラメータに独自のプライベートエンタープライズ番号を使用する必要があります。ローカルで拡張可能なSD-ID名を作成する。

6.3.3. SD-PARAM
6.3.3. SD-PARAM

Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a value, referred to as 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は、すべてのPARAM-NAMEを制御しますが、名前にアットマークが含まれているSD-ID内のものは例外です。 PARAM-NAMEスコープは特定のSD-ID内にあります。したがって、2つの異なる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".

国際文字をサポートするには、PARA-VALUEフィールドをUTF-8を使用してエンコードする必要があります。 syslogアプリケーションは、有効なUTF-8シーケンスを発行してもよい(MAY)。 syslogアプリケーションは、「最短形式」の有効なUTF-8シーケンスを受け入れなければなりません(MUST)。制御文字がPARAM-VALUEに存在する場合、失敗してはなりません。 Syslogアプリケーションは、制御文字を含むメッセージを変更する場合があります(たとえば、値が0のオクテット(USASCII NUL)を4文字の「#000」に変更します)。 UNICODE TR36 [UNICODE-TR36]のセクション3.1で概説されている理由により、発信者はメッセージを「最短形式」でエンコードする必要があり、コレクタまたはリレーは「非最短形式」でメッセージを解釈してはなりません(MUST NOT)。

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 for control character escaping for consistency with its use for escaping in other parts of the syslog message as well as in traditional 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.

円記号( '\')の後に3つの記述された文字のいずれも続かない場合、無効なエスケープシーケンスと見なされます。この場合、バックスラッシュは通常のバックスラッシュとして扱われ、次の文字は通常の文字として扱われる必要があります。したがって、無効なシーケンスを変更してはなりません(MUST)。

An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT.


6.3.4. Change Control
6.3.4. 変更管理

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-NAMEを定義したら、これらのオブジェクトの構文とセマンティクスを変更してはなりません(MUST NOT)。既存のオブジェクトへの変更が必要な場合は、新しいSD-IDまたはPARAM-NAMEを作成する必要があり、古いものは変更されないままにする必要があります。オプションのPARAM-NAMEは、既存のSD-IDに追加される場合があります。

6.3.5. Examples
6.3.5. 例

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


           [exampleSDID@32473 iut="3" eventSource="Application"

This example is a structured data element with a non-IANA controlled SD-ID of type "exampleSDID@32473", which has three parameters.

この例は、IANAで制御されていないタイプ「exampleSDID @ 32473」のSD-IDを持つ構造化データ要素で、3つのパラメーターがあります。

Example 2 - Valid


           [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).


Example 3 - Invalid


           [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とほぼ同じ例ですが、わずかなエラーがあります-2つの構造化データ要素( "] SP [")の間にSP文字があります。これは無効です。これにより、STRUCTURED-DATAフィールドが最初の要素の後に終了します。 2番目の要素は、MSGフィールドの一部として解釈されます。

Example 4 - Invalid


           [ 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文字はSTRUCTURED-DATAを無効にします。 syslogアプリケーションは、このメッセージを破棄してもよい(MAY)。

Example 5 - Valid


           [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.


6.4. MSG
6.4. MSG

The MSG part contains a free-form message that provides information about the event.


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で使用される文字セットは、[RFC3629]で指定されているように、UTF-8を使用してエンコードされたUNICODEである必要があります(SHOULD)。 syslogアプリケーションがMSGをUnicodeでエンコードできない場合、他のエンコードを使用できます(MAY)。

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(DELを除く従来のUS-ASCII制御文字範囲)未満のオクテット値を回避する必要があります(SHOULD)。これらの値は有効ですが、syslogアプリケーションは受信時にこれらの文字を変更する場合があります。たとえば、それらをエスケープシーケンスに変更する場合があります(たとえば、値0が「\ 0」に変更される場合があります)。 syslogアプリケーションは、他のオクテット値を変更してはなりません(SHOULD NOT)。

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アプリケーションがMSGをUTF-8でエンコードする場合、文字列はUnicodeバイトオーダーマスク(BOM)で開始する必要があります。これはUTF-8の場合、ABNF%xEF.BB.BFです。 syslogアプリケーションは「最短形式」でエンコードする必要があり、有効なUTF-8シーケンスを使用することができます(MAY)。

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で始まるMSGを処理していて、MSGに最短形式ではないUTF-8が含まれている場合、[UNICODE-TR36]で概説されている理由により、MSGはUTF-8でエンコードされていると解釈してはなりません(MUST NOT)。セクション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]によれば、syslogアプリケーションは「非最短形式」のメッセージを解釈してはなりません(MUST NOT)。無効なUTF-8シーケンスを解釈してはならない(MUST NOT)。

6.5. Examples
6.5. 例

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.

次に、有効なsyslogメッセージの例を示します。各例の説明は、その下にあります。例は[RFC3164]の類似の例に基づいており、読者にはおなじみかもしれません。他の方法では印刷できないUnicode BOMは、例では「BOM」として表されます。

Example 1 - with no STRUCTURED-DATA


        <34>1 2003-10-11T22:14:15.003Z 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 "". 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.

この例では、VERSIONは1で、Facilityの値は4です。Severityは2です。メッセージは2003年10月11日10:14:15 pm UTC、3ミリ秒後に作成されました。メッセージは、「」として自身を識別するホストから発信されました。 APP-NAMEは "su"で、PROCIDは不明です。 MSGIDは「ID47」です。 MSGはUTF-8でエンコードされた「lonvickで「su root」が失敗しました...」です。エンコーディングはBOMによって定義されます。メッセージにSTRUCTURED-DATAがありません。これは、STRUCTURED-DATAフィールドの「-」で示されます。

Example 2 - with no STRUCTURED-DATA


<165>1 2003-08-24T05:14:15.000003-07:00 myproc 8710 - - %% It's time to make the do-nuts.

<165> 1 2003-08-24T05:14:15.000003-07:00 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 "", 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.

この例では、VERSIONは1に戻ります。Facilityは20、重大度は5です。メッセージは2003年8月24日5:14:15 amに作成され、UTCからの-7時間のオフセット、次の秒に3マイクロ秒あります。 HOSTNAMEは「」であるため、syslogアプリケーションはFQDNを認識せず、代わりにIPv4アドレスの1つを使用しました。 APP-NAMEは「myproc」で、PROCIDは「8710」です(たとえば、これはUNIX PIDの場合があります)。メッセージにSTRUCTURED-DATAがありません。これは、STRUCTURED-DATAフィールドの「-」で示されます。特定の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


<165>1 2003-10-11T22:14:15.003Z evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"] BOMAn application event log entry...

<165> 1 2003-10-11T22:14:15.003Z evntslog-ID47 [exampleSDID @ 32473 iut = "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 @ 32473 iut = "3" eventSource = "Application" eventID = "1011"] "の単一の要素であるSTRUCTURED-DATAが含まれています。 MSG自体は「アプリケーションイベントログエントリ...」です。MSGの最初のBOMはUTF-8エンコーディングを示します。

Example 4 - STRUCTURED-DATA Only


           <165>1 2003-10-11T22:14:15.003Z
           evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
           "Application" eventID="1011"][examplePriority@32473

This example shows a message with only STRUCTURED-DATA and no MSG part. This is a valid message.


7. Structured Data IDs
7. 構造化データID

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.


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.


7.1. timeQuality
7.1. timeQuality

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 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.


7.1.1. tzKnown
7.1.1. tzKnown

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).


7.1.2. isSynced
7.1.2. isSynced

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.


7.1.3. syncAccuracy
7.1.3. syncAccuracy

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.


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.

「isSynced」に値「0」を使用する場合、このパラメーターを指定してはなりません(MUST NOT)。 「isSynced」に値「1」が使用されているが、「syncAccuracy」パラメーターが存在しない場合、コレクターまたはリレーは、提供された時刻情報が正確であると見なされるのに十分正確であると想定できます。 「syncAccuracy」パラメータは、発信者が実際に外部のタイムソースの信頼性を知っている場合にのみ記述する必要があります。ほとんどの場合、オペレーターの構成により、この詳細な知識が得られます。

7.1.4. Examples
7.1.4. 例

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"]

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.


7.2. origin
7.2. 原点

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.


Specifying any of these parameters is primarily an aid to log analyzers and similar applications.


7.2.1. ip
7.2.1. ip

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.


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.

このパラメーターを使用して、HOSTNAMEフィールドの内容に加えて、識別情報を提供できます。 HOSTNAMEフィールドにFQDNがまだ含まれているときに、ホストのIPアドレスがメッセージに含まれている場合に特に役立ちます。また、マルチホームホストのすべての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.


7.2.2. enterpriseId
7.2.2. enterpriseId

The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is ( The number that follows MUST be unique and MUST be registered with IANA as per RFC 2578 [RFC2578]. An enterprise is only authorized to assign values within the<private enterprise number> subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the<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.

「enterpriseId」パラメータは、IANAによって維持される「SMIネットワーク管理プライベートエンタープライズコード」である必要があり、そのプレフィックスはです。続く番号は一意でなければならず、RFC 2578 [RFC2578]に従ってIANAに登録する必要があります。企業は、IANAによってその企業に割り当てられた。<private enterprise number>サブツリー内の値を割り当てることのみが許可されています。 enterpriseIdには、。<private enterprise number>サブツリーからの値のみを含める必要があります。一般に、IANAによって割り当てられたプライベートエンタープライズ番号(単一の番号)のみが必要です。企業は、その企業番号よりも小さいサブ識別子を使用することを決定する場合があります。サブ識別子を使用する場合は、それらをピリオドで区切り、10進数として表す必要があります。その例は「32473.1.2」です。 ID「32473.1.2」は単なる例であり、使用してはならないことに注意してください。 Private Enterprise Numbers(PEN)の完全な最新リストは、IANAによって管理されています。

By specifying a private enterprise number, the vendor allows more specific processing of the message.


7.2.3. software
7.2.3. ソフトウェア

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」も指定する必要があります(SHOULD)。 「ソフトウェア」パラメーターは、APP-NAMEヘッダーフィールドと同じではありません。常に生成ソフトウェアの名前を含める必要がありますが、APP-NAMEには、オペレーターが構成した値を含め、他のものを含めることができます。

The "software" parameter is a string. It MUST NOT be longer than 48 characters.

「ソフトウェア」パラメータは文字列です。 48文字を超えてはなりません。

7.2.4. swVersion
7.2.4. swVersion

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.


The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters.

「swVersion」パラメータは文字列です。 32文字を超えてはなりません。

7.2.5. Example
7.2.5. 例

The following is an example with multiple IP addresses:


[origin ip="" ip=""]

[origin ip = "" ip = ""]

In this example, the originator indicates that it has two IP addresses, one being and the other one being


7.3. meta
7.3. メタ

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「メタ」は、メッセージに関するメタ情報を提供するために使用される場合があります。以下のパラメーターを使用できます。すべてのパラメーターはオプションです。 「メタ」SD-IDを使用する場合、少なくとも1つのパラメーターを指定する必要があります(SHOULD)。

7.3.1. sequenceId
7.3.1. sequenceId

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.


7.3.2. sysUpTime
7.3.2. sysUpTime

The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in [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 "INTEGER"構文を直接サポートしないため、値は文字 "0"、 "1"、 "2"、 "3"、 "4"のみを使用して10進整数(小数点なし)として表す必要があります、「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のセマンティクスは「システムのネットワーク管理部分が最後に再初期化されてからの時間(100分の1秒単位)」であることに注意してください。もちろん、これはシステムのSNMP関連の管理部分に関連しており、システムのsyslog関連の管理部分とは異なる場合があります。

7.3.3. language
7.3.3. 言語

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]で定義されている言語識別子が含まれている必要があります。

8. Security Considerations
8. セキュリティに関する考慮事項

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 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.

このドキュメントでは、PARA-VALUEおよびMSGフィールドにUTF-8エンコーディングを使用しています。 UNICODEには多くのセキュリティ問題があります。実装者およびオペレーターは、これらの問題について学ぶためにUNICODE TR36 [UNICODE-TR36](UTR36)を確認することをお勧めします。このドキュメントは、syslogアプリケーションに「最短形式」のエンコーディングを要求することにより、UTR36で概説されている技術的な問題から保護します。ただし、キャラクターの混乱による視覚的ななりすましは引き続き発生します。このドキュメントでは、ローカルスクリプトが予想され、必要な場所でのみUNICODEを許可することにより、視覚的ななりすましの影響を最小限に抑えようとしています。他のすべてのフィールドでは、US-ASCIIが必要です。また、PARA-VALUEおよびMSGフィールドは、情報を特定するための主要な情報源であってはならず、視覚的ななりすましに関連するリスクがさらに低減されます。

8.2. Control Characters
8.2. 制御文字

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.


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.


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.


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.


8.3. Message Truncation
8.3. メッセージの切り捨て

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.


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.


8.4. Replay
8.4. リプレイ

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プロトコルには、メッセージの再生を検出するメカニズムはありません。攻撃者は、マシンの通常のアクティビティを示す一連のメッセージを記録する可能性があります。後で、その攻撃者はそのマシンをネットワークから削除し、syslogメッセージをリレーまたはコレクターに再生する可能性があります。 HEADER部分にTIMESTAMPフィールドがあっても、攻撃者はパケットを記録し、パケットを再送信する前に現在の時刻を反映するように変更するだけです。管理者は、受信したメッセージに異常なものを何も見つけない場合があり、それらの受信は、マシンの通常のアクティビティを誤って示します。

Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.


8.5. Reliable Delivery
8.5. 信頼できる配達

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など)、一部のメッセージが失われる可能性があります。それらは、ネットワークの輻輳によってドロップされるか、悪意を持って傍受されて破棄される可能性があります。 1つ以上のsyslogメッセージをドロップした結果は判別できません。メッセージが単純なステータスの更新である場合、メッセージが受信されないことが通知されないか、システムオペレーターに不快感を与える可能性があります。一方、メッセージがより重要である場合、管理者は開発中の潜在的に深刻な問題に気付かない可能性があります。不正な活動を隠す方法として、攻撃者がメッセージを傍受して破棄することもあります。

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.

信頼できる配信が常に望ましいとは限りません。信頼性の高い配信とは、リレーまたはコレクターがこれ以上メッセージを受け入れることができない場合、syslogの発信元またはリレーがブロックする必要があることを意味します。一部のオペレーティングシステム、つまり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.


8.6. Congestion Control
8.6. 輻輳制御

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トランスポートを使用する必要があります(SHOULD)。

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.


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.

SEVERITYの数値が小さいメッセージは、数値が大きいメッセージよりも実用的な重大度が高くなります。その状況では、ドロップされるメッセージは単に破棄されるべきです(SHOULD)。 syslogアプリケーションは、メッセージをドロップしたことをコレクターまたはリレーに通知する場合があります。

8.7. Message Integrity
8.7. メッセージの整合性

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.


8.8. Message Observation
8.8. メッセージの観察

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メッセージは、有能な管理者がメッセージを読んでその意味を理解できるはずであるという前提で、人間が読める形式で生成されます。 syslogプロトコルには、送信中のメッセージに機密性を提供するメカニズムがありません。ほとんどの場合、クリアテキストメッセージを渡すことは、ネットワークからパケットを傍受する場合に運用スタッフにメリットがあります。運用スタッフは、メッセージを読み取り、ワイヤーを通過する他のパケットから見られる他のイベントにメッセージを関連付けて、問題を追跡および修正できる場合があります。残念ながら、攻撃者は人間が読めるsyslogメッセージの内容を観察することもできます。その後、攻撃者はそれらのメッセージから得られた知識を使用して、マシンを危険にさらしたり、その他の損害を与えたりする可能性があります。

Operators are advised to use a secure transport mapping to avoid this problem.


8.9. Inappropriate Configuration
8.9. 不適切な構成

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.

メッセージや設定に関する制御情報は配布されないため、メッセージが実際に目的の受信者に送信されるようにするのは、ネットワーク管理者の責任です。 syslogアプリケーションが誤ってsyslogメッセージを誤ったリレーまたはコレクターに送信するように設定されているケースが指摘されています。多くの場合、不注意なリレーまたはコレクターは、syslogメッセージを受信するように構成されておらず、おそらくそれらを破棄します。その他の特定のケースでは、syslogメッセージを受信すると、意図しない受信者に問題が発生することがわかっています。メッセージが目的の受信者に送信されない場合、メッセージを確認または処理できません。

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.


8.10. Forwarding Loop
8.10. 転送ループ

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.


8.11. Load Considerations
8.11. 負荷に関する考慮事項

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.


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.


8.12. Denial of Service
8.12. サービス拒否

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.


9. IANA Considerations
9. IANAに関する考慮事項
9.1. バージョン

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.

セクション6.2.2で説明されているように、IANAはVERSION値の「syslogバージョン値」という名前のレジストリを作成しました。 HEADERの任意の部分を変更する新しい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]で説明されているように、VERSION番号は標準アクション方式で登録する必要があります。 IANAは、以下の表3に示すバージョンを登録しています。

VERSION FORMAT 1 Defined in [RFC5424]


Table 3. IANA-Registered VERSIONs

表3. IANAに登録されたバージョン

9.2. SD-IDs
9.2. SD-ID

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.


New SD-ID and new PARAM-NAME values must be registered through the IETF Review method as described in [RFC5226].


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-PARAMを定義したら、これらのオブジェクトの構文とセマンティクスを変更してはなりません(MUST NOT)。既存のオブジェクトへの変更が必要な場合は、新しい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は登録せず、アットマーク(ABNF%d64)を含む名前を制御しません。

IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below.




origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL

origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL

meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL

meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL

Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs


10. Working Group
10. ワーキンググループ

The working group can be contacted via the mailing list:



The current Chairs of the Working Group may be contacted at:


Chris Lonvick Cisco Systems EMail:

Chris Lonvick Cisco Systems

David Harrington Huawei Technologies USA EMail:

David Harrington Huawei Technologies USA

11. Acknowledgments
11. 謝辞

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.

著者は、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、その他すべてに感謝しますこの提案のさまざまなバージョンについてコメントした他の人々。

12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

[ANSI.X3-4.1968] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.

[ANSI.X3-4.1968] American National Standards Institute、「USA Code for Information Interchange」、ANSI X3.4、1968。

[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。、and J. Schoenwaelder、Ed。、 "Structure of Management Information Version 2(SMIv2)"、STD 58、RFC 2578、April 1999。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]フロイド、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]クライン、G、エド。 C.ニューマン、「インターネット上の日付と時刻:タイムスタンプ」、RFC 3339、2002年7月。

[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.

[RFC3418] Presuhn、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 4291、2006年2月。

[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.

[RFC4646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 4646、2006年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、「RFCで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、「SyslogのTLSトランスポートマッピング」、RFC 5425、2009年3月。

[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.

[RFC5426] Okmianski、A。、「UDPを介したSyslogメッセージの送信」、RFC 5426、2009年3月。

[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security Considerations", July 2005.

[UNICODE-TR36] Davis、M.およびM. Suignard、「UNICODE Security Considerations」、2005年7月。

12.2. Informative References
12.2. 参考引用

[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.

[RFC3164] Lonvick、C。、「The BSD Syslog Protocol」、RFC 3164、2001年8月。

Appendix A. Implementer Guidelines

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.


A.1. Relationship with BSD Syslog
A.1. BSD Syslogとの関係

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 syslogは広く使用されていますが、その形式は正式に標準化されたことはありません。 [RFC3164]は観測されたフォーマットを説明しています。これは情報RFCであり、実際には多くの異なる実装があることが示されています。このドキュメントの作成中の調査によると、異なるプラットフォームでの異なるsyslog実装間での共通点はほとんどありません。彼ら全員が同意する唯一のことは、メッセージが「<」PRIVAL ">」で始まるということです。それ以外の場合、レガシーSyslogメッセージは一貫した方法でフォーマットされません。したがって、RFC 3164には、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.


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.


RFC 3164 describes relay behavior. This document does not specify relay behavior. This might be done in a separate document.

RFC 3164は、リレーの動作について説明しています。このドキュメントでは、リレーの動作を指定していません。これは別のドキュメントで行われる場合があります。

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で説明されているTIMESTAMPは、このドキュメントで指定されているタイムスタンプよりも精度が低くなります。また、年と時間帯の情報もありません。このドキュメントに従ってフォーマットされたメッセージを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のHOSTNAMEはそれほど限定的ではありませんが、この形式はこのドキュメントでは代替HOSTNAME表現の1つとしてサポートされています。

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でTAGおよびCONTENTとして説明されています。このドキュメントでは、MSGはRFC 3164でCONTENTと呼ばれていたものです。TAGは現在、ヘッダーの一部ですが、単一のフィールドではありません。タグはAPP-NAME、PROCID、MSGIDに分割されています。これはTAGの使用法に完全に似ているわけではありませんが、ほとんどの場合に同じ機能を提供します。

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では、STRUCTURED-DATAは記述されていませんでした。このドキュメントに準拠するメッセージにSTRUCTURED-DATAが含まれていて、RFC 3164に従って再フォーマットする必要がある場合、STRUCTURED-DATAは単にRFC 3164 CONTENT自由形式テキストの一部になります。

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 syslogは、歴史的に開発され、解析が難しいフィールド分離ルールに悩まされています。

A.2. Message Length
A.2. メッセージの長さ

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.

Syslogトランスポートレシーバーが最大480オクテットまでの受信のみをサポートする必要がある理由は、とりわけ、壊れたネットワークでの配信の困難な問題に関係しています。 Syslogメッセージでは、この480オクテットの制限を持つUDPトランスポートマッピングを使用して、セッションのオーバーヘッドとメッセージの断片化を回避できます。問題のあるネットワークでは、1つの単一パケットメッセージが正常に配信される可能性は、2つのメッセージフラグメントが正常に配信される可能性よりも高くなります。したがって、大きいサイズを使用すると、オペレーターが問題に関するいくつかの重要な情報を取得できなくなる可能性があります。一方、小さいメッセージを使用すると、オペレーターにその情報が取得される可能性があります。トラブルシューティングを目的としたメッセージは、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 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.

実装者は、メッセージの長さがオクテットで指定されていることに注意してください。 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のみの環境を対象とした実装では、これをより大きな最小サイズと見なす場合があります。

A.3. Severity Values
A.3. 重大度の値

This section describes guidelines for using Severity as outlined in Section 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.


Because severities are very subjective, a relay or collector should not assume that all originators have the same definition of severity.


A.4. TIME-SECFRAC Precision
A.4. 時間-SECFRAC精度

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で説明されているTIMESTAMPは、小数秒をサポートしています。これは、先行ゼロが小数秒から削除される非常に一般的なコーディングエラーの根拠を提供します。たとえば、TIMESTAMP "2003-10-11T22:13:14.003"は、誤って "2003-10-11T22:13:14.3"と記述される場合があります。これは、実際に意味される3ミリ秒ではなく、300ミリ秒を示します。

A.5. Case Convention for Names
A.5. 名前の大文字と小文字の区別

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".


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.


A.6. Syslog Applications Without Knowledge of Time
A.6. 時間の知識がないSyslogアプリケーション

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.


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.

ただし、基盤となるオペレーティングシステム、プログラミングシステム、およびハードウェアが時計機能をサポートしている場合、実装は有効なTIMESTAMPを発行する必要があります(SHOULD)。システム時刻を取得することが困難な場合でも、適切なTIMESTAMPが発行されます。 NILVALUEは、時間情報を取得することが実際には不可能である場合にのみ使用してください。このルールは、遅延実装の言い訳として使用しないでください。

A.7. Notes on the timeQuality SD-ID
A.7. timeQuality SD-IDに関する注意

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.

「0」の値を「tzKnown」(セクション7.1.1)パラメータのデフォルトにすることをお勧めします。これは、管理者がタイムゾーンを明確に構成した後でのみ "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)を使用して、正確な誤った印象を作成しないことが重要です。発信者は、これらの境界内にあることが実際にわかっている場合にのみ、特定の精度を示す必要があります。通常、発信者は、オペレーターの構成を通じてこの詳細な知識を得ると想定されています。デフォルトでは、精度は提供されません。

A.8. UTF-8 Encoding and the BOM
A.8. UTF-8エンコーディングとBOM

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 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.

このドキュメントでは、SD-PARAMSは常にUTF-8でエンコードする必要があると規定しています。 ASCIIPRINTを含む、MSG部分のメッセージの他のエンコーディングは、この仕様に準拠するデバイスでは許可されていません。ここで対処する必要がある2つのケースがあります。まず、この仕様に準拠したsyslogアプリケーションは、発信者から提供された情報がUTF-8でエンコードされていることを確認できない場合があります。それを確実に判断できない場合、syslogアプリケーションはBOMをMSGに組み込まないことを選択できます。 syslogアプリケーションに、メッセージのコンテンツがUTF-8でエンコードされていることが適切に示されている場合は、BOMを含める必要があります。 2番目のケースでは、syslogリレーが、この仕様に準拠していないデバイスからのメッセージを転送している可能性があります。その場合、受信したメッセージがUTF-8でエンコードされていることが確認されない限り、デバイスにBOMが含まれない可能性があります。

Author's Address


Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany

Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld、BW 97950 Germany