6. Syslog Message Format (Syslog-Nachrichtenformat)
Die syslog-Nachricht hat die folgende ABNF [RFC5234] Definition:
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; range 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; not starting with BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; UTF-8 string as specified
; in RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
6.1. Message Length (Nachrichtenlänge)
Die Größenbeschränkungen für syslog-Nachrichten werden durch das verwendete syslog-Transport-Mapping bestimmt. Es gibt keine Obergrenze per se. Jedes Transport-Mapping definiert die minimal erforderliche maximale Nachrichtenlängenunterstützung, und das Mindestmaximum MUSS mindestens 480 Oktette lang sein.
Jeder Transport Receiver MUSS in der Lage sein, Nachrichten bis zu einer Länge von 480 Oktetten einschließlich zu akzeptieren. Alle Transport Receiver-Implementierungen SOLLTEN in der Lage sein, Nachrichten bis zu einer Länge von 2048 Oktetten einschließlich zu akzeptieren. Transport Receiver KÖNNEN Nachrichten empfangen, die länger als 2048 Oktette sind. Wenn ein Transport Receiver eine Nachricht mit einer Länge empfängt, die größer ist als er unterstützt, SOLLTE der Transport Receiver die Nutzlast abschneiden. Alternativ KANN er die Nachricht verwerfen.
Wenn ein Transport Receiver Nachrichten abschneidet, MUSS das Abschneiden am Ende der Nachricht erfolgen. Nach dem Abschneiden KANN die Nachricht ungültige UTF-8-Kodierung oder ungültige STRUCTURED-DATA enthalten. Der Transport Receiver KANN die Nachricht verwerfen oder KANN in diesem Fall versuchen, so viel wie möglich zu verarbeiten.
6.2. HEADER
Der im HEADER verwendete Zeichensatz MUSS Sieben-Bit-ASCII in einem Acht-Bit-Feld sein, wie in [RFC5234] beschrieben. Dies sind die ASCII-Codes, wie sie in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968] definiert sind.
Das Header-Format ist so konzipiert, dass es eine gewisse Interoperabilität mit älterem BSD-basiertem syslog bietet. Einzelheiten dazu finden Sie in Anhang A.1.
6.2.1. PRI (Priorität)
Der PRI-Teil MUSS drei, vier oder fünf Zeichen haben und wird mit spitzen Klammern (Angle Brackets) als erstes und letztes Zeichen begrenzt. Der PRI-Teil beginnt mit einem führenden "<" ('less-than'-Zeichen, %d60), gefolgt von einer Zahl, gefolgt von einem ">" ('greater-than'-Zeichen, %d62). Die in diesen spitzen Klammern (Angle Brackets) enthaltene Zahl wird als Priority-Wert (PRIVAL) bezeichnet und repräsentiert sowohl die Facility als auch die Severity. Der Priority-Wert besteht aus einer, zwei oder drei Dezimalzahlen (ABNF DIGITS) mit Werten von %d48 (für "0") bis %d57 (für "9").
Facility- und Severity-Werte sind nicht normativ, werden aber häufig verwendet. Sie werden in den folgenden Tabellen zu rein informativen Zwecken beschrieben. Facility-Werte MÜSSEN im Bereich von 0 bis 23 einschließlich liegen.
| Numerischer Code | Facility |
|---|---|
| 0 | Kernel-Nachrichten |
| 1 | Nachrichten auf Benutzerebene |
| 2 | Mail-System |
| 3 | System-Daemons |
| 4 | Sicherheits-/Autorisierungsnachrichten |
| 5 | Intern von syslogd generierte Nachrichten |
| 6 | Zeilendrucker-Subsystem |
| 7 | Netzwerk-News-Subsystem |
| 8 | UUCP-Subsystem |
| 9 | Uhr-Daemon |
| 10 | Sicherheits-/Autorisierungsnachrichten |
| 11 | FTP-Daemon |
| 12 | NTP-Subsystem |
| 13 | Log-Audit |
| 14 | Log-Alarm |
| 15 | Uhr-Daemon (Anmerkung 2) |
| 16 | Lokale Verwendung 0 (local0) |
| 17 | Lokale Verwendung 1 (local1) |
| 18 | Lokale Verwendung 2 (local2) |
| 19 | Lokale Verwendung 3 (local3) |
| 20 | Lokale Verwendung 4 (local4) |
| 21 | Lokale Verwendung 5 (local5) |
| 22 | Lokale Verwendung 6 (local6) |
| 23 | Lokale Verwendung 7 (local7) |
Tabelle 1. Syslog-Nachrichten-Facilities
Jede Nachrichten-Priority hat auch einen dezimalen Severity-Level-Indikator. Diese werden in der folgenden Tabelle zusammen mit ihren numerischen Werten beschrieben. Severity-Werte MÜSSEN im Bereich von 0 bis 7 einschließlich liegen.
| Numerischer Code | Severity |
|---|---|
| 0 | Emergency: System ist unbenutzbar |
| 1 | Alert: Sofortiges Handeln erforderlich |
| 2 | Critical: Kritische Bedingungen |
| 3 | Error: Fehlerbedingungen |
| 4 | Warning: Warnbedingungen |
| 5 | Notice: Normale, aber signifikante Bedingung |
| 6 | Informational: Informationsnachrichten |
| 7 | Debug: Debug-Level-Nachrichten |
Tabelle 2. Syslog-Nachrichten-Severities
Der Priority-Wert wird berechnet, indem zuerst die Facility-Nummer mit 8 multipliziert und dann der numerische Wert der Severity addiert wird. Zum Beispiel würde eine Kernel-Nachricht (Facility=0) mit einer Severity von Emergency (Severity=0) einen Priority-Wert von 0 haben. Ebenso würde eine "local use 4"-Nachricht (Facility=20) mit einer Severity von Notice (Severity=5) einen Priority-Wert von 165 haben. Im PRI einer syslog-Nachricht würden diese Werte zwischen den spitzen Klammern als <0> bzw. <165> platziert. Die einzige Zeit, in der ein Wert von "0"` ... `"<" folgt, ist für den Priority-Wert von "0". Andernfalls DÜRFEN führende "0"en NICHT verwendet werden.
6.2.2. VERSION
Das VERSION-Feld gibt die Version der syslog-Protokollspezifikation an. Die Versionsnummer MUSS für jede neue syslog-Protokollspezifikation erhöht werden, die irgendeinen Teil des HEADER-Formats ändert. Änderungen umfassen das Hinzufügen oder Entfernen von Feldern oder eine Änderung der Syntax oder Semantik bestehender Felder. Dieses Dokument verwendet einen VERSION-Wert von "1". Die VERSION-Werte werden von der IANA zugewiesen (Abschnitt 9.1) über die Standards Action-Methode, wie in [RFC5226] beschrieben.
6.2.3. TIMESTAMP (Zeitstempel)
Das TIMESTAMP-Feld ist ein formalisierter Zeitstempel, der von [RFC3339] abgeleitet ist. Während [RFC3339] mehrere Syntaxen zulässt, erlegt dieses Dokument weitere Einschränkungen auf. Der TIMESTAMP-Wert MUSS diese Einschränkungen befolgen:
- Die Zeichen "T" und "Z" in dieser Syntax MÜSSEN Großbuchstaben sein.
- Die Verwendung des "T"-Zeichens ist ERFORDERLICH.
- Schaltsekunden DÜRFEN NICHT verwendet werden.
Der Originator SOLLTE TIME-SECFRAC einschließen, wenn seine Uhrgenauigkeit und -leistung dies erlauben. Die in Abschnitt 7.1 beschriebene "timeQuality"-SD-ID ermöglicht es dem Originator, die Genauigkeit und Vertrauenswürdigkeit des Zeitstempels anzugeben.
Eine syslog-Anwendung MUSS den NILVALUE als TIMESTAMP verwenden, wenn die syslog-Anwendung nicht in der Lage ist, die Systemzeit zu erhalten.
6.2.3.1. Examples (Beispiele)
Beispiel 1
1985-04-12T23:20:50.52Z
Dies repräsentiert 20 Minuten und 50,52 Sekunden nach der 23. Stunde des 12. April 1985 in UTC.
Beispiel 2
1985-04-12T19:20:50.52-04:00
Dies repräsentiert dieselbe Zeit wie in Beispiel 1, aber ausgedrückt in US Eastern Standard Time (Sommerzeit beachtend).
Beispiel 3
2003-10-11T22:14:15.003Z
Dies repräsentiert den 11. Oktober 2003 um 22:14:15 Uhr, 3 Millisekunden in die nächste Sekunde. Der Zeitstempel ist in UTC. Der Zeitstempel bietet Millisekundenauflösung. Der Ersteller hat möglicherweise tatsächlich eine bessere Auflösung gehabt, aber die Bereitstellung von nur drei Ziffern für den Bruchteil einer Sekunde sagt uns das nicht.
Beispiel 4
2003-08-24T05:14:15.000003-07:00
Dies repräsentiert den 24. August 2003 um 05:14:15 Uhr, 3 Mikrosekunden in die nächste Sekunde. Die Mikrosekundenauflösung wird durch die zusätzlichen Ziffern in TIME-SECFRAC angezeigt. Der Zeitstempel zeigt an, dass seine lokale Zeit -7 Stunden von UTC beträgt. Dieser Zeitstempel könnte in der US-pazifischen Zeitzone während der Sommerzeit erstellt worden sein.
Beispiel 5 - Ein ungültiger TIMESTAMP
2003-08-24T05:14:15.000000003-07:00
Dieses Beispiel ist fast identisch mit Beispiel 4, gibt aber TIME-SECFRAC in Nanosekunden an. Dies führt dazu, dass TIME-SECFRAC länger als die erlaubten 6 Ziffern ist, was es ungültig macht.
6.2.4. HOSTNAME
Das HOSTNAME-Feld identifiziert die Maschine, die die syslog-Nachricht ursprünglich gesendet hat.
Das HOSTNAME-Feld SOLLTE den Hostnamen und den Domänennamen des Originators im in STD 13 [RFC1034] spezifizierten Format enthalten. Dieses Format wird in diesem Dokument als Fully Qualified Domain Name (FQDN) bezeichnet.
In der Praxis können nicht alle syslog-Anwendungen einen FQDN bereitstellen. Als solches KÖNNEN auch andere Werte in HOSTNAME vorhanden sein. Dieses Dokument sieht die Verwendung anderer Werte in solchen Situationen vor. Eine syslog-Anwendung SOLLTE zuerst den spezifischsten verfügbaren Wert bereitstellen. Die Präferenzreihenfolge für den Inhalt des HOSTNAME-Feldes ist wie folgt:
- FQDN
- Statische IP-Adresse
- Hostname
- Dynamische IP-Adresse
- der NILVALUE
Wenn eine IPv4-Adresse verwendet wird, MUSS sie im Format der gepunkteten Dezimalnotation sein, wie in STD 13 [RFC1035] verwendet. Wenn eine IPv6-Adresse verwendet wird, MUSS eine gültige Textdarstellung verwendet werden, wie in [RFC4291], Abschnitt 2.2, beschrieben.
Syslog-Anwendungen SOLLTEN konsistent denselben Wert im HOSTNAME-Feld so lange wie möglich verwenden.
Der NILVALUE SOLLTE nur verwendet werden, wenn die syslog-Anwendung keine Möglichkeit hat, ihren echten Hostnamen zu erhalten. Diese Situation wird als höchst unwahrscheinlich angesehen.
6.2.5. APP-NAME (Anwendungsname)
Das APP-NAME-Feld SOLLTE das Gerät oder die Anwendung identifizieren, die die Nachricht erzeugt hat. Es ist eine Zeichenkette ohne weitere Semantik. Es ist für das Filtern von Nachrichten auf einem Relay oder Collector gedacht.
Der NILVALUE KANN verwendet werden, wenn die syslog-Anwendung keine Ahnung von ihrem APP-NAME hat oder diese Information nicht bereitstellen kann. Es kann sein, dass ein Gerät diese Information entweder aufgrund einer lokalen Richtlinienentscheidung oder weil die Information nicht verfügbar oder nicht anwendbar auf dem Gerät ist, nicht bereitstellen kann.
Dieses Feld KANN vom Operator zugewiesen werden.
6.2.6. PROCID (Prozess-ID)
PROCID ist ein Wert, der in der Nachricht enthalten ist und keine interoperable Bedeutung hat, außer dass eine Änderung des Wertes anzeigt, dass es eine Diskontinuität in der syslog-Berichterstattung gegeben hat. Das Feld hat keine spezifische Syntax oder Semantik; der Wert ist implementierungsabhängig und/oder vom Operator zugewiesen. Der NILVALUE KANN verwendet werden, wenn kein Wert bereitgestellt wird.
Das PROCID-Feld wird oft verwendet, um den Prozessnamen oder die Prozess-ID bereitzustellen, die mit einem syslog-System verbunden ist. Der NILVALUE könnte verwendet werden, wenn keine Prozess-ID verfügbar ist. Auf einem eingebetteten System ohne Betriebssystem-Prozess-ID könnte PROCID eine Neustart-ID sein.
PROCID kann es Log-Analyzern ermöglichen, Diskontinuitäten in der syslog-Berichterstattung zu erkennen, indem sie eine Änderung in der syslog-Prozess-ID erkennen. PROCID ist jedoch keine zuverlässige Identifikation eines neu gestarteten Prozesses, da dem neu gestarteten syslog-Prozess möglicherweise dieselbe Prozess-ID wie dem vorherigen syslog-Prozess zugewiesen wird.
PROCID kann auch verwendet werden, um zu identifizieren, welche Nachrichten zu einer Gruppe von Nachrichten gehören. Zum Beispiel könnte ein SMTP-Mail-Transfer-Agent seine SMTP-Transaktions-ID in PROCID eingeben, was es dem Collector oder Relay ermöglichen würde, Nachrichten basierend auf der SMTP-Transaktion zu gruppieren.
6.2.7. MSGID (Nachrichten-ID)
Die MSGID SOLLTE den Typ der Nachricht identifizieren. Zum Beispiel könnte eine Firewall die MSGID "TCPIN" für eingehenden TCP-Verkehr und die MSGID "TCPOUT" für ausgehenden TCP-Verkehr verwenden. Nachrichten mit derselben MSGID sollten Ereignisse derselben Semantik widerspiegeln. Die MSGID selbst ist eine Zeichenkette ohne weitere Semantik. Sie ist für das Filtern von Nachrichten auf einem Relay oder Collector gedacht.
Der NILVALUE SOLLTE verwendet werden, wenn die syslog-Anwendung keinen Wert bereitstellt oder bereitstellen kann.
Dieses Feld KANN vom Operator zugewiesen werden.
6.3. STRUCTURED-DATA (Strukturierte Daten)
STRUCTURED-DATA bietet einen Mechanismus, um Informationen in einem klar definierten, leicht analysierbaren und interpretierbaren Datenformat auszudrücken. Es gibt mehrere Nutzungsszenarien. Es kann beispielsweise Meta-Informationen über die syslog-Nachricht oder anwendungsspezifische Informationen wie Verkehrszähler oder IP-Adressen ausdrücken.
STRUCTURED-DATA kann null, ein oder mehrere strukturierte Datenelemente enthalten, die in diesem Dokument als "SD-ELEMENT" bezeichnet werden.
Im Fall von null strukturierten Datenelementen MUSS das STRUCTURED-DATA-Feld den NILVALUE enthalten.
Der in STRUCTURED-DATA verwendete Zeichensatz MUSS Sieben-Bit-ASCII in einem Acht-Bit-Feld sein, wie in [RFC5234] beschrieben. Dies sind die ASCII-Codes, wie sie in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968] definiert sind. Eine Ausnahme ist das PARAM-VALUE-Feld (siehe Abschnitt 6.3.3), in dem UTF-8-Kodierung verwendet werden MUSS.
Ein Collector KANN fehlerhafte STRUCTURED-DATA-Elemente ignorieren. Ein Relay MUSS fehlerhafte STRUCTURED-DATA ohne jegliche Änderung weiterleiten.
6.3.1. SD-ELEMENT
Ein SD-ELEMENT besteht aus einem Namen und Parameter-Name-Wert-Paaren. Der Name wird als SD-ID bezeichnet. Die Name-Wert-Paare werden als "SD-PARAM" bezeichnet.
6.3.2. SD-ID
SD-IDs sind groß-/kleinschreibungssensitiv und identifizieren eindeutig den Typ und Zweck des SD-ELEMENT. Dieselbe SD-ID DARF NICHT mehr als einmal in einer Nachricht vorkommen.
Es gibt zwei Formate für SD-ID-Namen:
-
Namen, die kein At-Zeichen ("@", ABNF %d64) enthalten, sind reserviert, um durch IETF Review zugewiesen zu werden, wie in BCP26 [RFC5226] beschrieben. Derzeit sind dies die in Abschnitt 7 definierten Namen. Namen dieses Formats sind nur gültig, wenn sie zuerst bei der IANA registriert wurden. Registrierte Namen DÜRFEN NICHT ein At-Zeichen ('@', ABNF %d64), ein Gleichheitszeichen ('=', ABNF %d61), eine schließende Klammer (']', ABNF %d93), ein Anführungszeichen ('"', ABNF %d34), Leerzeichen oder Steuerzeichen (ASCII-Code 127 und Codes 32 oder weniger) enthalten.
-
Jeder kann zusätzliche SD-IDs mit Namen im Format
name@<private enterprise number>definieren, z.B."ourSDID@32473". Das Format des Teils vor dem At-Zeichen ist nicht spezifiziert; diese Namen MÜSSEN jedoch druckbare US-ASCII-Zeichenketten sein und DÜRFEN NICHT ein At-Zeichen ('@', ABNF %d64), ein Gleichheitszeichen ('=', ABNF %d61), eine schließende Klammer (']', ABNF %d93), ein Anführungszeichen ('"', ABNF %d34), Leerzeichen oder Steuerzeichen enthalten. Der Teil nach dem At-Zeichen MUSS eine private Unternehmensnummer sein, wie in Abschnitt 7.2.2 spezifiziert. Bitte beachten Sie, dass in diesem gesamten Dokument der Wert 32473 für alle privaten Unternehmensnummern verwendet wird. Dieser Wert wurde von der IANA reserviert, um als Beispielnummer in der Dokumentation verwendet zu werden. Implementierer müssen ihre eigene private Unternehmensnummer für den enterpriseId-Parameter verwenden und bei der Erstellung lokal erweiterbarer SD-ID-Namen.
6.3.3. SD-PARAM (Strukturierter Datenparameter)
Jeder SD-PARAM besteht aus einem Namen, der als PARAM-NAME bezeichnet wird, und einem Wert, der als PARAM-VALUE bezeichnet wird.
PARAM-NAME ist groß-/kleinschreibungssensitiv. IANA kontrolliert alle PARAM-NAMEs, mit Ausnahme derjenigen in SD-IDs, deren Namen ein At-Zeichen enthalten. Der PARAM-NAME-Bereich liegt innerhalb einer spezifischen SD-ID. Daher sind gleich benannte PARAM-NAME-Werte, die in zwei verschiedenen SD-IDs enthalten sind, nicht dieselben.
Um internationale Zeichen zu unterstützen, MUSS das PARAM-VALUE-Feld mit UTF-8 kodiert werden. Eine syslog-Anwendung KANN jede gültige UTF-8-Sequenz ausgeben. Eine syslog-Anwendung MUSS jede gültige UTF-8-Sequenz in der "kürzesten Form" akzeptieren. Sie DARF NICHT fehlschlagen, wenn Steuerzeichen in PARAM-VALUE vorhanden sind. Die syslog-Anwendung KANN Nachrichten ändern, die Steuerzeichen enthalten (z.B. durch Ändern eines Oktetts mit dem Wert 0 (USASCII NUL) in die vier Zeichen "#000"). Aus den in UNICODE TR36 [UNICODE-TR36], Abschnitt 3.1, dargelegten Gründen MUSS ein Originator Nachrichten in der "kürzesten Form" kodieren, und ein Collector oder Relay DARF Nachrichten NICHT in der "nicht kürzesten Form" interpretieren.
Innerhalb von PARAM-VALUE MÜSSEN die Zeichen '"' (ABNF %d34), '\' (ABNF %d92) und ']' (ABNF %d93) escaped werden. Dies ist notwendig, um Parsing-Fehler zu vermeiden. Das Escapen von ']' wäre nicht strikt notwendig, wird aber von dieser Spezifikation GEFORDERT, um Implementierungsfehler bei syslog-Anwendungen zu vermeiden. Jedes dieser drei Zeichen MUSS als \\", \\\\ bzw. \\] escaped werden. Der Backslash wird für das Escapen von Steuerzeichen verwendet, um konsistent mit seiner Verwendung zum Escapen in anderen Teilen der syslog-Nachricht sowie im traditionellen syslog zu sein.
Ein Backslash ('\'), dem keines der drei beschriebenen Zeichen folgt, wird als ungültige Escape-Sequenz betrachtet. In diesem Fall MUSS der Backslash als normaler Backslash und das folgende Zeichen als normales Zeichen behandelt werden. Die ungültige Sequenz DARF also NICHT geändert werden.
Ein SD-PARAM KANN mehrfach innerhalb eines SD-ELEMENT wiederholt werden.
6.3.4. Change Control (Änderungskontrolle)
Sobald SD-IDs und PARAM-NAMEs definiert sind, DÜRFEN Syntax und Semantik dieser Objekte NICHT geändert werden. Sollte eine Änderung an einer bestehenden SD-ID oder PARAM-NAME gewünscht werden, MÜSSEN die bereits definierten SD-ID und PARAM-NAME unverändert bleiben, und es MUSS eine neue erstellt werden.
6.3.5. Examples (Beispiele)
Beispiel 1 - Gültige STRUCTURED-DATA
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]
In diesem Beispiel ist "exampleSDID@32473" die SD-ID; "iut", "eventSource" und "eventID" sind SD-PARAM-Namen.
Beispiel 2 - Zwei strukturierte Datenelemente
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
6.4. MSG (Nachricht)
Der MSG-Teil enthält eine Freitextnachricht, die Informationen über das Ereignis liefert. Der in MSG verwendete Zeichensatz SOLLTE UNICODE sein, kodiert mit UTF-8 wie in [RFC3629] spezifiziert. Wenn die syslog-Anwendung die MSG nicht in Unicode kodieren kann, KANN sie jede andere Kodierung verwenden.
Syslog-Anwendungen SOLLTEN die Verwendung von Steuerzeichen (USASCII-Codes 127 und Codes 32 oder weniger) in MSG vermeiden. Wenn eine syslog-Anwendung Steuerzeichen verwendet, ist es möglicherweise nicht möglich, die Nachricht auf dem Collector oder Relay zu interpretieren.
Die Kodierung des MSG-Teils wird durch das erste Oktett bestimmt. Wenn das erste Oktett der ABNF-Wert %xEF.BB.BF ist, ist dies die Unicode Byte Order Mark (BOM) für UTF-8. In diesem Fall MUSS die MSG in UTF-8 kodiert sein und DARF NICHT anderswo eine BOM enthalten. Wenn das erste Oktett nicht die BOM ist, ist die Kodierung nicht spezifiziert.
Traditionelle syslog-Anwendungen verwendeten nur druckbare USASCII-Zeichen in MSG. Diese Spezifikation erlaubt die Verwendung von Steuerzeichen und anderen Code-Werten in MSG. Da dies jedoch zu Problemen bei der Anzeige und allgemeinen Nachrichtenverarbeitung führen kann, wird EMPFOHLEN, dass syslog-Anwendungen dieselbe Kodierungsstrategie wie traditionelle syslog-Anwendungen verwenden.
6.5. Examples (Beispiele)
Beispiel 1 - mit BOM, Mehrbyte-UTF-8 und STRUCTURED-DATA
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMAn application event log entry...
In diesem Beispiel sind die Mehrbyte-UTF-8-Zeichen nur in der MSG vorhanden, und die "BOM" markiert hier den Beginn des MSG-Teils. Die Kodierung dieser syslog-Nachricht ist so, dass sie lesbar ist, wenn der MSG-Teil als ISO 8859-1 interpretiert wird. Dies wäre jedoch in diesem Fall nicht angemessen, da diese Nachricht mit einer BOM beginnt. Angesichts dessen SOLLTE der Empfänger die MSG als UTF-8-kodierten Text interpretieren.
Beispiel 2 - keine BOM, STRUCTURED-DATA
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.
Dieses Beispiel zeigt eine Nachricht ohne STRUCTURED-DATA. Der NILVALUE "-" wird sowohl in den Feldern MSGID als auch STRUCTURED-DATA verwendet. Die MSG selbst ist Freitext.
Beispiel 3 - mit STRUCTURED-DATA
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
Dieses Beispiel zeigt eine Nachricht mit zwei SD-ELEMENTs und keinem MSG-Teil.