rfc3164.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,358 行 · 第 1/5 页

         any other machines will be called a "collector".  This has been
         commonly known as a "syslog server".

         Any device or relay will be known as the "sender" when it sends
         a message.




Lonvick                      Informational                      [Page 5]

RFC 3164                The BSD syslog Protocol              August 2001


         Any relay or collector will be known as the "receiver" when it
         receives the message.

   The architecture of the devices may be summarized as follows:

         Senders send messages to relays or collectors with no knowledge
         of whether it is a collector or relay.

         Senders may be configured to send the same message to multiple
         receivers.

         Relays may send all or some of the messages that they receive
         to a subsequent relay or collector.  In the case where they do
         not forward all of their messages, they are acting as both a
         collector and a relay.  In the following diagram, these devices
         will be designated as relays.

         Relays may also generate their own messages and send them on to
         subsequent relays or collectors.  In that case it is acting as
         a device.  These devices will also be designated as a relay in
         the following diagram.

   The following architectures shown in Diagram 1 are valid while the
   first one has been known to be the most prevalent.  Other
   arrangements of these examples are also acceptable.  As noted above,
   in the following diagram relays may pass along all or some of the
   messages that they receive along with passing along messages that
   they internally generate.























Lonvick                      Informational                      [Page 6]

RFC 3164                The BSD syslog Protocol              August 2001


         +------+         +---------+
         |Device|---->----|Collector|
         +------+         +---------+

         +------+         +-----+         +---------+
         |Device|---->----|Relay|---->----|Collector|
         +------+         +-----+         +---------+

         +------+     +-----+            +-----+     +---------+
         |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
         +------+     +-----+            +-----+     +---------+

         +------+         +-----+         +---------+
         |Device|---->----|Relay|---->----|Collector|
         |      |-\       +-----+         +---------+
         +------+  \
                    \      +-----+         +---------+
                     \-->--|Relay|---->----|Collector|
                           +-----+         +---------+

         +------+         +---------+
         |Device|---->----|Collector|
         |      |-\       +---------+
         +------+  \
                    \      +-----+         +---------+
                     \-->--|Relay|---->----|Collector|
                           +-----+         +---------+

         +------+         +-----+            +---------+
         |Device|---->----|Relay|---->-------|Collector|
         |      |-\       +-----+         /--|         |
         +------+  \                     /   +---------+
                    \      +-----+      /
                     \-->--|Relay|-->--/
                           +-----+

           Diagram 1.  Some Possible syslog Architectures

4. Packet Format and Contents

   The payload of any IP packet that has a UDP destination port of 514
   MUST be treated as a syslog message.  There MAY be differences
   between the format of an originally transmitted syslog message and
   the format of a relayed message.  In essence, it is RECOMMENDED to
   transmit a syslog message in the format specified in this document,
   but it is not required.  If a relay is able to recognize the message
   as adhering to that format then it MUST retransmit the message
   without making any changes to it.  However, if a relay receives a



Lonvick                      Informational                      [Page 7]

RFC 3164                The BSD syslog Protocol              August 2001


   message but cannot discern the proper implementation of the format,
   it is REQUIRED to modify the message so that it conforms to that
   format before it retransmits it.  Section 4.1 will describe the
   RECOMMENDED format for syslog messages.  Section 4.2 will describe
   the requirements for originally transmitted messages and Section 4.3
   will describe the requirements for relayed messages.

4.1 syslog Message Parts

   The full format of a syslog message seen on the wire has three
   discernable parts.  The first part is called the PRI, the second part
   is the HEADER, and the third part is the MSG.  The total length of
   the packet MUST be 1024 bytes or less.  There is no minimum length of
   the syslog message although sending a syslog packet with no contents
   is worthless and SHOULD NOT be transmitted.

4.1.1 PRI Part

   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), followed by a
   number, which is followed by a ">" ('greater-than' character). The
   code set used in this part MUST be seven-bit ASCII in an eight-bit
   field as described in RFC 2234 [2].  These are the ASCII codes as
   defined in "USA Standard Code for Information Interchange" [3].  In
   this, the "<" character is defined as the Augmented Backus-Naur Form
   (ABNF) %d60, and the ">" character has ABNF value %d62.  The number
   contained within these angle brackets is known as the Priority value
   and represents both the Facility and Severity as described below.
   The Priority value consists of one, two, or three decimal integers
   (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").

   The Facilities and Severities of the messages are numerically coded
   with decimal values.  Some of the operating system daemons and
   processes have been assigned Facility values.  Processes and daemons
   that have not been explicitly assigned a Facility may use any of the
   "local use" facilities or they may use the "user-level" Facility.
   Those Facilities that have been designated are shown in the following
   table along with their numerical code values.

       Numerical             Facility
          Code

           0             kernel messages
           1             user-level messages
           2             mail system
           3             system daemons
           4             security/authorization messages (note 1)



Lonvick                      Informational                      [Page 8]

RFC 3164                The BSD syslog Protocol              August 2001


           5             messages generated internally by syslogd
           6             line printer subsystem
           7             network news subsystem
           8             UUCP subsystem
           9             clock daemon (note 2)
          10             security/authorization messages (note 1)
          11             FTP daemon
          12             NTP subsystem
          13             log audit (note 1)
          14             log alert (note 1)
          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)

           Table 1.  syslog Message Facilities

        Note 1 - Various operating systems have been found to utilize
           Facilities 4, 10, 13 and 14 for security/authorization,
           audit, and alert messages which seem to be similar.
        Note 2 - Various operating systems have been found to utilize
           both Facilities 9 and 15 for clock (cron/at) messages.

   Each message Priority also has a decimal Severity level indicator.
   These are described in the following table along with their numerical
   values.

        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






Lonvick                      Informational                      [Page 9]

RFC 3164                The BSD syslog Protocol              August 2001


   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 part 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" will follow the "<"
   is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be
   used.

4.1.2 HEADER Part of a syslog Packet

   The HEADER part contains a timestamp and an indication of the
   hostname or IP address of the device.  The HEADER part of the syslog
   packet MUST contain visible (printing) characters.  The code set used
   MUST also be seven-bit ASCII in an eight-bit field like that used in
   the PRI part.  In this code set, the only allowable characters are
   the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).

   The HEADER contains two fields called the TIMESTAMP and the HOSTNAME.
   The TIMESTAMP will immediately follow the trailing ">" from the PRI
   part and single space characters MUST follow each of the TIMESTAMP
   and HOSTNAME fields.  HOSTNAME will contain the hostname, as it knows
   itself.  If it does not have a hostname, then it will contain its own
   IP address.  If a device has multiple IP addresses, it has usually
   been seen to use the IP address from which the message is
   transmitted.  An alternative to this behavior has also been seen.  In
   that case, a device may be configured to send all messages using a
   single source IP address regardless of the interface from which the
   message is sent.  This will provide a single consistent HOSTNAME for
   all messages sent from a device.

   The TIMESTAMP field is the local time and is in the format of "Mmm dd