Aller au contenu principal

6. Format de message Syslog (Syslog Message Format)

Le message Syslog a la définition 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 sur le message (priorité, version, horodatage, informations source)
  • STRUCTURED-DATA: Informations structurées optionnelles en paires nom-valeur
  • MSG: Contenu de message en format libre optionnel

6.1. Longueur du message (Message Length)

Les messages Syslog ne doivent pas dépasser 480 octets pour le transport UDP. Cela garantit la compatibilité avec les implémentations réseau limitées.

Les récepteurs Syslog doivent être capables d'accepter des messages allant jusqu'à 480 octets. Les récepteurs devraient être capables d'accepter des messages allant jusqu'à 2048 octets.

Les émetteurs Syslog peuvent envoyer des messages de plus de 480 octets. Cependant, ils devraient implémenter des mécanismes de troncature ou de division de messages si nécessaire.

Les mappages de transport peuvent spécifier des tailles de messages maximales différentes. Par exemple, le transport TLS permet généralement des messages beaucoup plus volumineux.

La longueur du message est mesurée en octets, pas en caractères. L'encodage UTF-8 peut résulter en 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é (Priority) entre crochets angulaires. La valeur de priorité est calculée à partir des valeurs Facility et Severity:

Priority = Facility * 8 + Severity

Valeurs Facility:

ValeurFacility
0messages du noyau (kernel messages)
1messages au niveau utilisateur
2système de messagerie
3daemons système
4messages de sécurité/autorisation
5messages générés en interne par syslogd
6sous-système d'imprimante ligne
7sous-système de nouvelles réseau
8sous-système UUCP
9daemon horloge
10messages de sécurité/autorisation
11daemon FTP
12sous-système NTP
13audit de log
14alerte de log
15daemon horloge
16-23utilisation locale 0-7 (local0 - local7)

Valeurs Severity:

ValeurSeverityDescription
0EmergencyLe système est inutilisable
1AlertUne action doit être prise immédiatement
2CriticalConditions critiques
3ErrorConditions d'erreur
4WarningConditions d'avertissement
5NoticeNormal mais significatif
6InformationalMessages informationnels
7DebugMessages de niveau debug

Exemple: Un message avec Facility 4 (sécurité/autorisation) et Severity 2 (Critical) a la 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. Ce 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 quand le message a été généré. Il devrait représenter le moment où l'événement décrit s'est produit.

Le format d'horodatage est basé sur RFC 3339 avec les exigences suivantes:

  • Date au format YYYY-MM-DD
  • Séparateur de temps "T"
  • Heure au format HH:MM:SS (24 heures)
  • Fractions de secondes 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'émetteur ne connaît pas l'heure, il doit utiliser NILVALUE ("-").

Meilleures pratiques:

  • Utilisez le fuseau horaire UTC (Z) lorsque possible pour la cohérence
  • Incluez les fractions de secondes lorsque la précision est importante
  • Assurez la synchronisation temporelle (NTP) pour des horodatages précis

6.2.4. HOSTNAME

Le champ HOSTNAME identifie la machine qui a généré initialement le message Syslog. Il devrait contenir l'un des éléments suivants:

  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 format FQDN est recommandé car il fournit l'identification la plus précise.

Si une adresse IPv6 est utilisée, elle devrait être entre crochets.

Longueur maximale: 255 caractères ASCII imprimables.

6.2.5. APP-NAME

Le champ APP-NAME identifie l'appareil ou l'application qui a généré le message. C'est une chaîne de format libre sans espaces.

Exemples:

myapp
su
postfix/smtpd

Longueur maximale: 48 caractères ASCII imprimables.

Si APP-NAME est inconnu, utilisez NILVALUE ("-").

6.2.6. PROCID

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

  • ID de processus (PID) sur les systèmes de type Unix
  • ID de thread
  • Nom de processus
  • Autre identificateur unique

Exemples:

12345
thread1
-

Longueur maximale: 128 caractères ASCII imprimables.

Si PROCID n'est pas utilisé, définissez sur NILVALUE ("-").

6.2.7. MSGID

Le champ MSGID identifie le type de message. C'est une chaîne de format libre sans espaces qui peut être utilisée 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é, définissez sur NILVALUE ("-").

6.3. STRUCTURED-DATA

STRUCTURED-DATA fournit un mécanisme pour exprimer des informations dans un format structuré facilement analysable. Il se compose d'un ou plusieurs SD-ELEMENTs.

6.3.1. SD-ELEMENT

Un SD-ELEMENT se compose de:

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

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

6.3.2. SD-ID

Le SD-ID identifie de manière unique le type et le but de l'élément.

SD-IDs enregistrés auprès de l'IANA: Composés de caractères ASCII imprimables excluant =, ], " et l'espace.

SD-IDs d'entreprise privés: Doivent être au format name@<numéro d'entreprise privé> où le numéro d'entreprise est 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"

Le PARAM-VALUE doit être encodé 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 le 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 modifications (Change Control)

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

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

6.3.5. Exemples

SD-ELEMENT unique:

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

Multiples SD-ELEMENTs:

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

Pas de données structurées:

-

6.4. MSG

La partie MSG contient le texte du message en format 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 BOM (Byte Order Mark: 0xEF 0xBB 0xBF)

Si MSG commence par la BOM UTF-8, le collecteur ou le relais devrait supposer que MSG est encodé en UTF-8. Sinon, l'encodage n'est pas spécifié.

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

Meilleures pratiques:

  • Utilisez l'encodage UTF-8 avec BOM pour un support cohérent des caractères internationaux
  • Évitez d'inclure des sauts de ligne ou d'autres caractères de contrôle
  • Conservez les informations importantes au début du message (dans les premiers 480 octets)

6.5. Exemples

Exemple 1: Message complet avec tous les champs et données structurées

<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 multiples SD-ELEMENTs

<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 d'urgence)

<0>1 2009-03-12T18:53:01+00:00 server1 kernel - - - System will shutdown