6. Syslog Message Format (Format de message Syslog)
Le message syslog a la définition ABNF [RFC5234] suivante:
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 (Longueur du message)
Les limites de taille des messages syslog sont dictées par le mappage de transport syslog utilisé. Il n'y a pas de limite supérieure en soi. Chaque mappage de transport définit la prise en charge minimale de la longueur maximale de message requise, et le maximum minimal DOIT être d'au moins 480 octets de longueur.
Tout transport receiver DOIT pouvoir accepter des messages d'une longueur allant jusqu'à 480 octets inclus. Toutes les implémentations de transport receiver DEVRAIENT pouvoir accepter des messages d'une longueur allant jusqu'à 2048 octets inclus. Les transport receivers PEUVENT recevoir des messages d'une longueur supérieure à 2048 octets. Si un transport receiver reçoit un message d'une longueur supérieure à celle qu'il prend en charge, le transport receiver DEVRAIT tronquer la charge utile. Alternativement, il PEUT rejeter le message.
Si un transport receiver tronque les messages, la troncature DOIT se produire à la fin du message. Après troncature, le message PEUT contenir un encodage UTF-8 invalide ou des STRUCTURED-DATA invalides. Le transport receiver PEUT rejeter le message ou PEUT essayer de traiter autant que possible dans ce cas.
6.2. HEADER (En-tête)
Le jeu de caractères utilisé dans le HEADER DOIT être ASCII sept bits dans un champ huit bits tel que décrit dans [RFC5234]. Ce sont les codes ASCII tels que définis dans "USA Standard Code for Information Interchange" [ANSI.X3-4.1968].
Le format d'en-tête est conçu pour fournir une certaine interopérabilité avec le syslog basé sur BSD plus ancien. Pour plus de détails à ce sujet, voir l'annexe A.1.
6.2.1. PRI (Priorité)
La partie PRI DOIT avoir trois, quatre ou cinq caractères et sera délimitée par des crochets angulaires comme premiers et derniers caractères. La partie PRI commence par un "<" de tête (caractère 'less-than', %d60), suivi d'un nombre, qui est suivi d'un ">" (caractère 'greater-than', %d62). Le nombre contenu dans ces crochets angulaires est connu comme la valeur de Priority (PRIVAL) et représente à la fois la Facility et la Severity. La valeur Priority se compose d'un, deux ou trois entiers décimaux (ABNF DIGITS) utilisant des valeurs de %d48 (pour "0") à %d57 (pour "9").
Les valeurs de Facility et Severity ne sont pas normatives mais souvent utilisées. Elles sont décrites dans les tableaux suivants à des fins purement informatives. Les valeurs de Facility DOIVENT être dans la plage de 0 à 23 inclus.
| Code numérique | Facility |
|---|---|
| 0 | messages du noyau |
| 1 | messages de niveau utilisateur |
| 2 | système de messagerie |
| 3 | démons système |
| 4 | messages de sécurité/autorisation |
| 5 | messages générés en interne par syslogd |
| 6 | sous-système d'imprimante ligne |
| 7 | sous-système de nouvelles réseau |
| 8 | sous-système UUCP |
| 9 | démon d'horloge |
| 10 | messages de sécurité/autorisation |
| 11 | démon FTP |
| 12 | sous-système NTP |
| 13 | audit de journal |
| 14 | alerte de journal |
| 15 | démon d'horloge (note 2) |
| 16 | utilisation locale 0 (local0) |
| 17 | utilisation locale 1 (local1) |
| 18 | utilisation locale 2 (local2) |
| 19 | utilisation locale 3 (local3) |
| 20 | utilisation locale 4 (local4) |
| 21 | utilisation locale 5 (local5) |
| 22 | utilisation locale 6 (local6) |
| 23 | utilisation locale 7 (local7) |
Tableau 1. Facilities des messages Syslog
Chaque Priority de message a également un indicateur de niveau de Severity décimal. Ceux-ci sont décrits dans le tableau suivant avec leurs valeurs numériques. Les valeurs de Severity DOIVENT être dans la plage de 0 à 7 inclus.
| Code numérique | Severity |
|---|---|
| 0 | Emergency: le système est inutilisable |
| 1 | Alert: une action doit être prise immédiatement |
| 2 | Critical: conditions critiques |
| 3 | Error: conditions d'erreur |
| 4 | Warning: conditions d'avertissement |
| 5 | Notice: condition normale mais significative |
| 6 | Informational: messages informatifs |
| 7 | Debug: messages de niveau débogage |
Tableau 2. Severities des messages Syslog
La valeur Priority est calculée en multipliant d'abord le numéro de Facility par 8, puis en ajoutant la valeur numérique de la Severity. Par exemple, un message du noyau (Facility=0) avec une Severity d'Emergency (Severity=0) aurait une valeur Priority de 0. De même, un message "local use 4" (Facility=20) avec une Severity de Notice (Severity=5) aurait une valeur Priority de 165. Dans le PRI d'un message syslog, ces valeurs seraient placées entre les crochets angulaires comme <0> et <165> respectivement. La seule fois où une valeur de "0" suit le "<" est pour la valeur Priority de "0". Sinon, les "0" de tête NE DOIVENT PAS être utilisés.
6.2.2. VERSION
Le champ VERSION indique la version de la spécification du protocole syslog. Le numéro de version DOIT être incrémenté pour toute nouvelle spécification du protocole syslog qui modifie une partie quelconque du format HEADER. Les modifications incluent l'ajout ou la suppression de champs, ou une modification de la syntaxe ou de la sémantique des champs existants. Ce document utilise une valeur VERSION de "1". Les valeurs VERSION sont attribuées par l'IANA (section 9.1) via la méthode Standards Action telle que décrite dans [RFC5226].
6.2.3. TIMESTAMP (Horodatage)
Le champ TIMESTAMP est un horodatage formalisé dérivé de [RFC3339]. Alors que [RFC3339] autorise plusieurs syntaxes, ce document impose des restrictions supplémentaires. La valeur TIMESTAMP DOIT respecter ces restrictions:
- Les caractères "T" et "Z" dans cette syntaxe DOIVENT être en majuscules.
- L'utilisation du caractère "T" est REQUISE.
- Les secondes intercalaires NE DOIVENT PAS être utilisées.
L'originator DEVRAIT inclure TIME-SECFRAC si la précision et les performances de son horloge le permettent. Le SD-ID "timeQuality" décrit dans la section 7.1 permet à l'originator de spécifier la précision et la fiabilité de l'horodatage.
Une application syslog DOIT utiliser la NILVALUE comme TIMESTAMP si l'application syslog est incapable d'obtenir l'heure système.
6.2.3.1. Examples (Exemples)
Exemple 1
1985-04-12T23:20:50.52Z
Cela représente 20 minutes et 50,52 secondes après la 23e heure du 12 avril 1985 en UTC.
Exemple 2
1985-04-12T19:20:50.52-04:00
Cela représente le même instant que dans l'exemple 1, mais exprimé en heure standard de l'Est des États-Unis (observant l'heure d'été).
Exemple 3
2003-10-11T22:14:15.003Z
Cela représente le 11 octobre 2003 à 22h14:15, 3 millisecondes dans la seconde suivante. L'horodatage est en UTC. L'horodatage fournit une résolution de milliseconde. Le créateur peut avoir eu une meilleure résolution, mais fournir seulement trois chiffres pour la partie fractionnaire d'une seconde ne nous le dit pas.
Exemple 4
2003-08-24T05:14:15.000003-07:00
Cela représente le 24 août 2003 à 05h14:15, 3 microsecondes dans la seconde suivante. La résolution de la microseconde est indiquée par les chiffres supplémentaires dans TIME-SECFRAC. L'horodatage indique que son heure locale est de -7 heures par rapport à UTC. Cet horodatage pourrait être créé dans le fuseau horaire du Pacifique américain pendant l'heure d'été.
Exemple 5 - Un TIMESTAMP invalide
2003-08-24T05:14:15.000000003-07:00
Cet exemple est presque identique à l'exemple 4, mais il spécifie TIME-SECFRAC en nanosecondes. Cela entraîne que TIME-SECFRAC soit plus long que les 6 chiffres autorisés, ce qui l'invalide.
6.2.4. HOSTNAME (Nom d'hôte)
Le champ HOSTNAME identifie la machine qui a initialement envoyé le message syslog.
Le champ HOSTNAME DEVRAIT contenir le nom d'hôte et le nom de domaine de l'originator au format spécifié dans STD 13 [RFC1034]. Ce format est appelé Fully Qualified Domain Name (FQDN) dans ce document.
En pratique, toutes les applications syslog ne peuvent pas fournir un FQDN. En tant que tel, d'autres valeurs PEUVENT également être présentes dans HOSTNAME. Ce document prévoit l'utilisation d'autres valeurs dans de telles situations. Une application syslog DEVRAIT fournir la valeur disponible la plus spécifique en premier. L'ordre de préférence pour le contenu du champ HOSTNAME est le suivant:
- FQDN
- Adresse IP statique
- nom d'hôte
- Adresse IP dynamique
- la NILVALUE
Si une adresse IPv4 est utilisée, elle DOIT être au format de la notation décimale pointée utilisée dans STD 13 [RFC1035]. Si une adresse IPv6 est utilisée, une représentation textuelle valide telle que décrite dans [RFC4291], section 2.2, DOIT être utilisée.
Les applications syslog DEVRAIENT utiliser de manière cohérente la même valeur dans le champ HOSTNAME aussi longtemps que possible.
La NILVALUE DEVRAIT être utilisée uniquement lorsque l'application syslog n'a aucun moyen d'obtenir son véritable nom d'hôte. Cette situation est considérée comme très peu probable.
6.2.5. APP-NAME (Nom d'application)
Le champ APP-NAME DEVRAIT identifier le périphérique ou l'application qui a généré le message. C'est une chaîne sans autre sémantique. Il est destiné au filtrage des messages sur un relay ou un collector.
La NILVALUE PEUT être utilisée lorsque l'application syslog n'a aucune idée de son APP-NAME ou ne peut pas fournir cette information. Il se peut qu'un périphérique soit incapable de fournir cette information soit en raison d'une décision de politique locale, soit parce que l'information n'est pas disponible ou non applicable sur le périphérique.
Ce champ PEUT être assigné par l'opérateur.
6.2.6. PROCID (ID de processus)
PROCID est une valeur qui est incluse dans le message, n'ayant pas de signification interopérable, sauf qu'un changement de valeur indique qu'il y a eu une discontinuité dans les rapports syslog. Le champ n'a pas de syntaxe ou de sémantique spécifique; la valeur est dépendante de l'implémentation et/ou assignée par l'opérateur. La NILVALUE PEUT être utilisée lorsqu'aucune valeur n'est fournie.
Le champ PROCID est souvent utilisé pour fournir le nom de processus ou l'ID de processus associé à un système syslog. La NILVALUE peut être utilisée lorsqu'un ID de processus n'est pas disponible. Sur un système embarqué sans ID de processus de système d'exploitation, PROCID pourrait être un ID de redémarrage.
PROCID peut permettre aux analyseurs de journaux de détecter des discontinuités dans les rapports syslog en détectant un changement dans l'ID de processus syslog. Cependant, PROCID n'est pas une identification fiable d'un processus redémarré car le processus syslog redémarré pourrait se voir attribuer le même ID de processus que le processus syslog précédent.
PROCID peut également être utilisé pour identifier quels messages appartiennent à un groupe de messages. Par exemple, un agent de transfert de courrier SMTP pourrait mettre son ID de transaction SMTP dans PROCID, ce qui permettrait au collector ou au relay de regrouper les messages en fonction de la transaction SMTP.
6.2.7. MSGID (ID de message)
Le MSGID DEVRAIT identifier le type de message. Par exemple, un pare-feu pourrait utiliser le MSGID "TCPIN" pour le trafic TCP entrant et le MSGID "TCPOUT" pour le trafic TCP sortant. Les messages avec le même MSGID devraient refléter des événements de la même sémantique. Le MSGID lui-même est une chaîne sans autre sémantique. Il est destiné au filtrage des messages sur un relay ou un collector.
La NILVALUE DEVRAIT être utilisée lorsque l'application syslog ne fournit pas ou ne peut pas fournir de valeur.
Ce champ PEUT être assigné par l'opérateur.
6.3. STRUCTURED-DATA (Données structurées)
STRUCTURED-DATA fournit un mécanisme pour exprimer des informations dans un format de données bien défini, facilement analysable et interprétable. Il existe plusieurs scénarios d'utilisation. Par exemple, il peut exprimer des méta-informations sur le message syslog ou des informations spécifiques à l'application telles que des compteurs de trafic ou des adresses IP.
STRUCTURED-DATA peut contenir zéro, un ou plusieurs éléments de données structurées, qui sont appelés "SD-ELEMENT" dans ce document.
En cas de zéro élément de données structurées, le champ STRUCTURED-DATA DOIT contenir la NILVALUE.
Le jeu de caractères utilisé dans STRUCTURED-DATA DOIT être ASCII sept bits dans un champ huit bits tel que décrit dans [RFC5234]. Ce sont les codes ASCII tels que définis dans "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. Une exception est le champ PARAM-VALUE (voir section 6.3.3), dans lequel l'encodage UTF-8 DOIT être utilisé.
Un collector PEUT ignorer les éléments STRUCTURED-DATA mal formés. Un relay DOIT transmettre les STRUCTURED-DATA mal formés sans aucune altération.
6.3.1. SD-ELEMENT
Un SD-ELEMENT se compose d'un nom et de paires nom-valeur de paramètres. Le nom est appelé SD-ID. Les paires nom-valeur sont appelées "SD-PARAM".
6.3.2. SD-ID
Les SD-ID sont sensibles à la casse et identifient de manière unique le type et le but du SD-ELEMENT. Le même SD-ID NE DOIT PAS exister plus d'une fois dans un message.
Il existe deux formats pour les noms SD-ID:
-
Les noms qui ne contiennent pas de signe arobase ("@", ABNF %d64) sont réservés pour être attribués par IETF Review tel que décrit dans BCP26 [RFC5226]. Actuellement, ce sont les noms définis dans la section 7. Les noms de ce format ne sont valides que s'ils sont d'abord enregistrés auprès de l'IANA. Les noms enregistrés NE DOIVENT PAS contenir de signe arobase ('@', ABNF %d64), de signe égal ('=', ABNF %d61), de crochet fermant (']', ABNF %d93), de guillemet ('"', ABNF %d34), d'espace blanc ou de caractères de contrôle (code ASCII 127 et codes 32 ou moins).
-
Tout le monde peut définir des SD-ID supplémentaires en utilisant des noms au format
name@<private enterprise number>, par exemple,"ourSDID@32473". Le format de la partie précédant le signe arobase n'est pas spécifié; cependant, ces noms DOIVENT être des chaînes US-ASCII imprimables, et NE DOIVENT PAS contenir de signe arobase ('@', ABNF %d64), de signe égal ('=', ABNF %d61), de crochet fermant (']', ABNF %d93), de guillemet ('"', ABNF %d34), d'espace blanc ou de caractères de contrôle. La partie suivant le signe arobase DOIT être un numéro d'entreprise privé tel que spécifié dans la section 7.2.2. Veuillez noter que dans l'ensemble de ce document, la valeur 32473 est utilisée pour tous les numéros d'entreprise privés. Cette valeur a été réservée par l'IANA pour être utilisée comme numéro d'exemple dans la documentation. Les implémenteurs devront utiliser leur propre numéro d'entreprise privé pour le paramètre enterpriseId, et lors de la création de noms SD-ID extensibles localement.
6.3.3. SD-PARAM (Paramètre de données structurées)
Chaque SD-PARAM se compose d'un nom, appelé PARAM-NAME, et d'une valeur, appelée PARAM-VALUE.
PARAM-NAME est sensible à la casse. L'IANA contrôle tous les PARAM-NAME, à l'exception de ceux dans les SD-ID dont les noms contiennent un signe arobase. La portée de PARAM-NAME est dans un SD-ID spécifique. Ainsi, des valeurs PARAM-NAME portant le même nom contenues dans deux SD-ID différents ne sont pas les mêmes.
Pour prendre en charge les caractères internationaux, le champ PARAM-VALUE DOIT être encodé en UTF-8. Une application syslog PEUT émettre n'importe quelle séquence UTF-8 valide. Une application syslog DOIT accepter n'importe quelle séquence UTF-8 valide sous la "forme la plus courte". Elle NE DOIT PAS échouer si des caractères de contrôle sont présents dans PARAM-VALUE. L'application syslog PEUT modifier les messages contenant des caractères de contrôle (par exemple, en changeant un octet de valeur 0 (USASCII NUL) en les quatre caractères "#000"). Pour les raisons exposées dans UNICODE TR36 [UNICODE-TR36], section 3.1, un originator DOIT encoder les messages sous la "forme la plus courte" et un collector ou relay NE DOIT PAS interpréter les messages sous la "forme non la plus courte".
À l'intérieur de PARAM-VALUE, les caractères '"' (ABNF %d34), '\' (ABNF %d92) et ']' (ABNF %d93) DOIVENT être échappés. Cela est nécessaire pour éviter les erreurs d'analyse. L'échappement de ']' ne serait pas strictement nécessaire mais est REQUIS par cette spécification pour éviter les erreurs d'implémentation d'application syslog. Chacun de ces trois caractères DOIT être échappé comme \\", \\\\ et \\] respectivement. La barre oblique inverse est utilisée pour l'échappement des caractères de contrôle pour la cohérence avec son utilisation pour l'échappement dans d'autres parties du message syslog ainsi que dans le syslog traditionnel.
Une barre oblique inverse ('\') suivie d'aucun des trois caractères décrits est considérée comme une séquence d'échappement invalide. Dans ce cas, la barre oblique inverse DOIT être traitée comme une barre oblique inverse normale et le caractère suivant comme un caractère normal. Ainsi, la séquence invalide NE DOIT PAS être modifiée.
Un SD-PARAM PEUT être répété plusieurs fois à l'intérieur d'un SD-ELEMENT.
6.3.4. Change Control (Contrôle des modifications)
Une fois que les SD-ID et PARAM-NAME sont définis, la syntaxe et la sémantique de ces objets NE DOIVENT PAS être modifiées. Si une modification d'un SD-ID ou PARAM-NAME existant est souhaitée, le SD-ID et PARAM-NAME déjà définis DOIVENT rester inchangés et un nouveau DOIT être créé.
6.3.5. Examples (Exemples)
Exemple 1 - STRUCTURED-DATA valide
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]
Dans cet exemple, "exampleSDID@32473" est le SD-ID; "iut", "eventSource" et "eventID" sont des noms SD-PARAM.
Exemple 2 - Deux éléments de données structurées
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
6.4. MSG (Message)
La partie MSG contient un message en forme libre qui fournit des informations sur l'événement. Le jeu de caractères utilisé dans MSG DEVRAIT être UNICODE, encodé en UTF-8 tel que spécifié dans [RFC3629]. Si l'application syslog ne peut pas encoder le MSG en Unicode, elle PEUT utiliser tout autre encodage.
Les applications syslog DEVRAIENT éviter l'utilisation de caractères de contrôle (codes USASCII 127 et codes 32 ou moins) dans MSG. Si une application syslog utilise des caractères de contrôle, il pourrait ne pas être possible d'interpréter le message sur le collector ou le relay.
L'encodage de la partie MSG est déterminé par le premier octet. Si le premier octet est la valeur ABNF %xEF.BB.BF, c'est la marque d'ordre d'octet Unicode (BOM) pour UTF-8. Dans ce cas, le MSG DOIT être encodé en UTF-8 et NE DOIT PAS contenir de BOM ailleurs. Si le premier octet n'est pas le BOM, l'encodage n'est pas spécifié.
Les applications syslog traditionnelles n'utilisaient que des caractères USASCII imprimables dans MSG. Cette spécification permet l'utilisation de caractères de contrôle et d'autres valeurs de code dans MSG. Cependant, comme cela pourrait entraîner des problèmes d'affichage et de traitement général des messages, il est RECOMMANDÉ que les applications syslog utilisent la même stratégie d'encodage que les applications syslog traditionnelles.
6.5. Examples (Exemples)
Exemple 1 - avec BOM, UTF-8 multi-octets et 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...
Dans cet exemple, les caractères UTF-8 multi-octets sont présents uniquement dans le MSG, et le "BOM" ici marque le début de la partie MSG. L'encodage de ce message syslog est tel qu'il sera lisible si la partie MSG est interprétée comme ISO 8859-1. Cependant, cela ne serait pas approprié dans ce cas, car ce message commence par un BOM. Compte tenu de cela, le destinataire DEVRAIT interpréter le MSG comme du texte encodé en UTF-8.
Exemple 2 - pas de 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.
Cet exemple montre un message sans STRUCTURED-DATA. La NILVALUE "-" est utilisée dans les champs MSGID et STRUCTURED-DATA. Le MSG lui-même est du texte en forme libre.
Exemple 3 - avec 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"]
Cet exemple montre un message avec deux SD-ELEMENT et pas de partie MSG.