Passa al contenuto principale

6. Formato del messaggio Syslog (Syslog Message Format)

Il messaggio Syslog ha la seguente definizione ABNF:

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        = "-"

Il messaggio è composto da:

  • HEADER: Contiene i metadati sul messaggio (priorità, versione, timestamp, informazioni sulla sorgente)
  • STRUCTURED-DATA: Informazioni strutturate opzionali in coppie nome-valore
  • MSG: Contenuto del messaggio in formato libero opzionale

6.1. Lunghezza del messaggio (Message Length)​

I messaggi Syslog non devono superare 480 byte per il trasporto UDP. Ciò garantisce la compatibilità con implementazioni di rete limitate.

I ricevitori Syslog devono essere in grado di accettare messaggi fino a 480 byte. I ricevitori dovrebbero essere in grado di accettare messaggi fino a 2048 byte.

I mittenti Syslog possono inviare messaggi più lunghi di 480 byte. Tuttavia, dovrebbero implementare meccanismi di troncamento o divisione dei messaggi se necessario.

Le mappature di trasporto possono specificare dimensioni massime di messaggio diverse. Ad esempio, il trasporto TLS consente tipicamente messaggi molto più grandi.

La lunghezza del messaggio è misurata in byte, non in caratteri. La codifica UTF-8 può risultare in più byte per carattere.

6.2. HEADER​

L'HEADER contiene i seguenti campi in questo ordine esatto:

6.2.1. PRI​

La parte PRI contiene il valore di priorità (Priority) racchiuso tra parentesi angolari. Il valore di priorità è calcolato dai valori Facility e Severity:

Priority = Facility * 8 + Severity

Valori Facility:

ValoreFacility
0messaggi del kernel (kernel messages)
1messaggi a livello utente
2sistema di posta
3daemon di sistema
4messaggi di sicurezza/autorizzazione
5messaggi generati internamente da syslogd
6sottosistema stampante di linea
7sottosistema notizie di rete
8sottosistema UUCP
9daemon orologio
10messaggi di sicurezza/autorizzazione
11daemon FTP
12sottosistema NTP
13audit log
14alert log
15daemon orologio
16-23uso locale 0-7 (local0 - local7)

Valori Severity:

ValoreSeverityDescrizione
0EmergencyIl sistema è inutilizzabile
1AlertÈ necessaria un'azione immediata
2CriticalCondizioni critiche
3ErrorCondizioni di errore
4WarningCondizioni di avviso
5NoticeNormale ma significativo
6InformationalMessaggi informativi
7DebugMessaggi a livello debug

Esempio: Un messaggio con Facility 4 (sicurezza/autorizzazione) e Severity 2 (Critical) ha il valore di priorità:

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

Il valore PRI deve essere compreso tra 0 e 191.

6.2.2. VERSION​

Il campo VERSION indica la versione del protocollo Syslog. Questo documento definisce la versione 1. Il valore VERSION deve essere un intero diverso da zero nell'intervallo 1-999.

6.2.3. TIMESTAMP​

Il campo TIMESTAMP è un timestamp formattato che indica quando è stato generato il messaggio. Dovrebbe rappresentare il momento in cui si è verificato l'evento descritto.

Il formato del timestamp è basato su RFC 3339 con i seguenti requisiti:

  • Data in formato YYYY-MM-DD
  • Separatore temporale "T"
  • Ora in formato HH:MM:SS (24 ore)
  • Frazioni di secondi opzionali (fino a 6 cifre)
  • Offset del fuso orario ("Z" per UTC o "+/-HH:MM")

Esempi:

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

Se il mittente non conosce l'ora, deve utilizzare NILVALUE ("-").

Best practice:

  • Utilizzare il fuso orario UTC (Z) quando possibile per coerenza
  • Includere frazioni di secondi quando la precisione è importante
  • Garantire la sincronizzazione temporale (NTP) per timestamp accurati

6.2.4. HOSTNAME​

Il campo HOSTNAME identifica la macchina che ha generato originariamente il messaggio Syslog. Dovrebbe contenere uno dei seguenti:

  1. Nome di dominio completamente qualificato (FQDN) - RACCOMANDATO
  2. Indirizzo IP statico
  3. Nome host
  4. Indirizzo IP dinamico
  5. NILVALUE ("-") se sconosciuto

Il formato FQDN è raccomandato poiché fornisce l'identificazione più accurata.

Se viene utilizzato un indirizzo IPv6, dovrebbe essere racchiuso tra parentesi quadre.

Lunghezza massima: 255 caratteri ASCII stampabili.

6.2.5. APP-NAME​

Il campo APP-NAME identifica il dispositivo o l'applicazione che ha generato il messaggio. È una stringa a formato libero senza spazi.

Esempi:

myapp
su
postfix/smtpd

Lunghezza massima: 48 caratteri ASCII stampabili.

Se APP-NAME è sconosciuto, utilizzare NILVALUE ("-").

6.2.6. PROCID​

Il campo PROCID è un valore che cambia ogni volta che un processo viene avviato o riavviato. Contiene tipicamente:

  • ID processo (PID) su sistemi Unix-like
  • ID thread
  • Nome processo
  • Altro identificatore univoco

Esempi:

12345
thread1
-

Lunghezza massima: 128 caratteri ASCII stampabili.

Se PROCID non è utilizzato, impostare su NILVALUE ("-").

6.2.7. MSGID​

Il campo MSGID identifica il tipo di messaggio. È una stringa a formato libero senza spazi che può essere utilizzata per l'analisi e il routing automatizzati.

Esempi:

ID47
TCPIN
login-failure
config-change

Lunghezza massima: 32 caratteri ASCII stampabili.

Se MSGID non è utilizzato, impostare su NILVALUE ("-").

6.3. STRUCTURED-DATA​

STRUCTURED-DATA fornisce un meccanismo per esprimere informazioni in un formato strutturato facilmente analizzabile. Consiste di uno o più SD-ELEMENT.

6.3.1. SD-ELEMENT​

Un SD-ELEMENT è composto da:

  • SD-ID (identificatore)
  • Zero o più SD-PARAM (parametri)

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

6.3.2. SD-ID​

L'SD-ID identifica univocamente il tipo e lo scopo dell'elemento.

SD-ID registrati IANA: Consistono di caratteri ASCII stampabili escludendo =, ], " e spazio.

SD-ID di impresa privati: Devono essere nel formato name@<numero impresa privato> dove il numero di impresa è registrato con IANA.

Esempi:

timeQuality
origin
myCompany@32473

6.3.3. SD-PARAM​

Ogni SD-PARAM è una coppia nome-valore:

PARAM-NAME="PARAM-VALUE"

Il PARAM-VALUE deve essere codificato utilizzando UTF-8. I caratteri speciali devono essere escaped:

  • " diventa \"
  • \ diventa \\
  • ] diventa \]

Esempio:

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

Sono consentiti più valori per lo stesso nome di parametro ripetendo il parametro:

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

6.3.4. Controllo delle modifiche (Change Control)​

Nuovi SD-ID possono essere registrati tramite IANA. Vedere la sezione 9 per i dettagli.

Le imprese private possono utilizzare il loro numero di impresa registrato per creare SD-ID privati senza registrazione.

6.3.5. Esempi​

Singolo SD-ELEMENT:

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

Multipli SD-ELEMENT:

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

Nessun dato strutturato:

-

6.4. MSG​

La parte MSG contiene il testo del messaggio in formato libero. Ha due possibili formati:

  1. MSG-ANY: Qualsiasi sequenza di byte
  2. MSG-UTF8: Stringa UTF-8 con prefisso BOM (Byte Order Mark: 0xEF 0xBB 0xBF)

Se MSG inizia con il BOM UTF-8, il collector o relay dovrebbe assumere che MSG sia codificato in UTF-8. Altrimenti, la codifica non è specificata.

La parte MSG è opzionale. Se assente, nessuno SP precede la fine del messaggio.

Best practice:

  • Utilizzare la codifica UTF-8 con BOM per un supporto coerente dei caratteri internazionali
  • Evitare di includere interruzioni di riga o altri caratteri di controllo
  • Mantenere informazioni importanti all'inizio del messaggio (entro i primi 480 byte)

6.5. Esempi​

Esempio 1: Messaggio completo con tutti i campi e dati strutturati

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

Esempio 2: Messaggio con campi 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.

Esempio 3: Messaggio con contenuto UTF-8 e multipli 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...

Esempio 4: Messaggio minimo (messaggio kernel di emergenza)

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