Aller au contenu principal

6. Format des messages syslog

Le message syslog est défini par l'ABNF 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
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
SD-NAME         = 1*32PRINTUSASCII

MSG             = MSG-ANY / MSG-UTF8
MSG-ANY         = *OCTET
MSG-UTF8        = BOM UTF-8-STRING
BOM             = %xEF.BB.BF
UTF-8-STRING    = *OCTET

OCTET           = %d00-255
SP              = %d32
PRINTUSASCII    = %d33-126
NONZERO-DIGIT   = %d49-57
DIGIT           = %d48 / NONZERO-DIGIT
NILVALUE        = "-"

Le message se compose de :

  • HEADER : contient les métadonnées du message (priorité, version, horodatage, informations de source).
  • STRUCTURED-DATA : informations structurées optionnelles, sous forme de paires nom-valeur.
  • MSG : contenu de message libre, optionnel.

6.1. Longueur du message​

Les messages syslog NE DOIVENT PAS dépasser 480 octets pour un transport UDP. Cela garantit la compatibilité avec les implémentations réseau limitées.

Les receveurs syslog DOIVENT être en mesure d'accepter des messages d'au moins 480 octets. Ils DEVRAIENT pouvoir accepter des messages allant jusqu'à 2048 octets.

Les émetteurs syslog PEUVENT envoyer des messages de plus de 480 octets ; ils DEVRAIENT alors implémenter des mécanismes de troncature ou de découpe si nécessaire.

Les mappages de transport PEUVENT spécifier des tailles maximales différentes. Par exemple, le transport TLS autorise typiquement des messages bien plus volumineux.

La longueur du message se mesure en octets, pas en caractères. Le codage UTF-8 peut produire plusieurs octets par caractère.

6.2. HEADER​

Le HEADER contient les champs suivants, dans cet ordre exact :

6.2.1. PRI​

La partie PRI contient la valeur de priorité, encadrée par des chevrons. La valeur de priorité se calcule à partir des valeurs Facility et Severity :

Priority = Facility * 8 + Severity

Valeurs de Facility :

ValeurFacility
0messages noyau
1messages utilisateur
2système de messagerie
3démons système
4messages de sécurité/autorisation
5messages générés en interne par syslogd
6sous-système d'imprimante
7sous-système de news réseau
8sous-système UUCP
9démon d'horloge
10messages de sécurité/autorisation
11démon FTP
12sous-système NTP
13log audit
14log alert
15démon d'horloge
16-23usage local 0-7 (local0 - local7)

Valeurs de Severity :

ValeurSeverityDescription
0Emergencysystème inutilisable
1Alertune action immédiate est nécessaire
2Criticalconditions critiques
3Errorconditions d'erreur
4Warningconditions d'avertissement
5Noticecondition normale mais significative
6Informationalmessages informationnels
7Debugmessages de niveau débogage

Exemple : un message avec Facility 4 (sécurité/autorisation) et Severity 2 (Critical) a pour valeur de priorité :

Priority = 4 * 8 + 2 = 34
PRI = "<34>"

La valeur PRI DOIT être comprise entre 0 et 191.

6.2.2. VERSION​

Le champ VERSION indique la version du protocole syslog. Le présent document définit la version 1. La valeur VERSION DOIT être un entier non nul dans la plage 1-999.

6.2.3. TIMESTAMP​

Le champ TIMESTAMP est un horodatage formaté indiquant le moment de génération du message. Il DEVRAIT représenter le moment où l'événement décrit s'est produit.

Le format d'horodatage repose sur la RFC 3339 avec les exigences suivantes :

  • Date au format AAAA-MM-JJ
  • Séparateur d'heure « T »
  • Heure au format HH:MM:SS (24 h)
  • Fractions de seconde optionnelles (jusqu'à 6 chiffres)
  • Décalage de fuseau horaire (« Z » pour UTC ou « +/-HH:MM »)

Exemples :

2003-10-11T22:14:15.003Z
2003-08-24T05:14:15.000003-07:00
2009-03-12T18:53:01+00:00

Si l'originator ignore l'heure, il DOIT utiliser la valeur NILVALUE (« - »).

Bonnes pratiques :

  • Utiliser l'UTC (Z) lorsque c'est possible, pour la cohérence.
  • Inclure les fractions de seconde quand la précision compte.
  • S'assurer d'une synchronisation horaire (NTP) pour des horodatages précis.

6.2.4. HOSTNAME​

Le champ HOSTNAME identifie la machine qui a initialement généré le message syslog. Il DEVRAIT contenir l'une des informations suivantes :

  1. Nom de domaine pleinement qualifié (FQDN) — RECOMMANDÉ.
  2. Adresse IP statique.
  3. Nom d'hôte.
  4. Adresse IP dynamique.
  5. NILVALUE (« - ») si inconnu.

Le FQDN est le format RECOMMANDÉ car il fournit l'identification la plus précise.

Si une adresse IPv6 est utilisée, elle DEVRAIT être encadrée par des crochets.

Longueur maximale : 255 caractères ASCII imprimables.

6.2.5. APP-NAME​

Le champ APP-NAME identifie le périphérique ou l'application qui a généré le message. Il s'agit d'une chaîne libre sans espaces.

Exemples :

myapp
su
postfix/smtpd

Longueur maximale : 48 caractères ASCII imprimables.

Si APP-NAME est inconnu, utiliser NILVALUE (« - »).

6.2.6. PROCID​

Le champ PROCID est une valeur qui change à chaque démarrage ou redémarrage d'un processus. Il contient typiquement :

  • Un identifiant de processus (PID) sur les systèmes de type Unix.
  • Un identifiant de thread.
  • Un nom de processus.
  • Tout autre identifiant unique.

Exemples :

12345
thread1
-

Longueur maximale : 128 caractères ASCII imprimables.

Si PROCID n'est pas utilisé, mettre NILVALUE (« - »).

6.2.7. MSGID​

Le champ MSGID identifie le type de message. C'est une chaîne libre sans espaces, utilisable pour l'analyse et le routage automatisés.

Exemples :

ID47
TCPIN
login-failure
config-change

Longueur maximale : 32 caractères ASCII imprimables.

Si MSGID n'est pas utilisé, mettre NILVALUE (« - »).

6.3. STRUCTURED-DATA​

STRUCTURED-DATA fournit un mécanisme pour exprimer des informations dans un format structuré et facilement analysable. Il est composé d'un ou plusieurs SD-ELEMENT.

6.3.1. SD-ELEMENT​

Un SD-ELEMENT comprend :

  • Un SD-ID (identifiant)
  • Zéro ou plusieurs SD-PARAM (paramètres)

Format : [SD-ID PARAM1="value1" PARAM2="value2" ...]

6.3.2. SD-ID​

Le SD-ID identifie de façon unique le type et le but de l'élément.

SD-ID enregistrés à l'IANA : composés de caractères ASCII imprimables, à l'exclusion de =, ], " et de l'espace.

SD-ID privés d'entreprise : doivent suivre le format name@<numéro privé d'entreprise>, le numéro étant enregistré auprès de l'IANA.

Exemples :

timeQuality
origin
myCompany@32473

6.3.3. SD-PARAM​

Chaque SD-PARAM est une paire nom-valeur :

PARAM-NAME="PARAM-VALUE"

La PARAM-VALUE DOIT être encodée en UTF-8. Les caractères spéciaux doivent être échappés :

  • " devient \"
  • \ devient \\
  • ] devient \]

Exemple :

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Plusieurs valeurs pour un même nom de paramètre sont autorisées en répétant le paramètre :

[example ip="192.0.2.1" ip="192.0.2.2"]

6.3.4. Contrôle des changements​

De nouveaux SD-ID peuvent être enregistrés via l'IANA. Voir la section 9 pour plus de détails.

Les entreprises privées peuvent utiliser leur numéro d'entreprise enregistré pour créer des SD-ID privés sans enregistrement.

6.3.5. Exemples​

Un seul SD-ELEMENT :

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Plusieurs SD-ELEMENT :

[exampleSDID@32473 iut="3"][examplePriority@32473 class="high"]

Pas de structured data :

-

6.4. MSG​

La partie MSG contient le texte de message libre. Elle a deux formats possibles :

  1. MSG-ANY : toute séquence d'octets.
  2. MSG-UTF8 : chaîne UTF-8 préfixée par un BOM (Byte Order Mark : 0xEF 0xBB 0xBF).

Si la MSG commence par le BOM UTF-8, le collector ou le relay DEVRAIT supposer que la MSG est encodée en UTF-8. Sinon, l'encodage n'est pas spécifié.

La partie MSG est optionnelle. Si elle est absente, aucun SP ne précède la fin du message.

Bonnes pratiques :

  • Utiliser l'encodage UTF-8 avec BOM pour une prise en charge cohérente des caractères internationaux.
  • Éviter d'inclure des sauts de ligne ou autres caractères de contrôle.
  • Placer les informations importantes en début de message (dans les 480 premiers octets).

6.5. Exemples​

Exemple 1 : message complet avec tous les champs et structured data

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMsystem crashed

Exemple 2 : message avec champs NILVALUE

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

Exemple 3 : message avec contenu UTF-8 et plusieurs SD-ELEMENT

<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"] BOMAn application event log entry...

Exemple 4 : message minimal (message noyau Emergency)

<0>1 2009-03-12T18:53:01+00:00 server1 kernel - - - System will shutdown
Dernière mise à jour le