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:
| Valeur | Facility |
|---|---|
| 0 | messages du noyau (kernel messages) |
| 1 | messages au niveau utilisateur |
| 2 | système de messagerie |
| 3 | daemons 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 | daemon horloge |
| 10 | messages de sécurité/autorisation |
| 11 | daemon FTP |
| 12 | sous-système NTP |
| 13 | audit de log |
| 14 | alerte de log |
| 15 | daemon horloge |
| 16-23 | utilisation locale 0-7 (local0 - local7) |
Valeurs Severity:
| Valeur | Severity | Description |
|---|---|---|
| 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 | Normal mais significatif |
| 6 | Informational | Messages informationnels |
| 7 | Debug | Messages 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:
- Nom de domaine pleinement qualifié (FQDN) - RECOMMANDÉ
- Adresse IP statique
- Nom d'hôte
- Adresse IP dynamique
- 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:
- MSG-ANY: Toute séquence d'octets
- 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