6. Syslog Message Format (Formato del messaggio Syslog)
Il messaggio syslog ha la seguente definizione ABNF [RFC5234]:
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 (Lunghezza del messaggio)
I limiti di dimensione per i messaggi syslog sono determinati dalla mappatura di trasporto syslog utilizzata. Non esiste un limite superiore di per sé. Ogni mappatura di trasporto definisce il supporto massimo minimo richiesto per la lunghezza del messaggio, e il massimo minimo DEVE essere lungo almeno 480 ottetti.
Ogni ricevitore di trasporto DEVE essere in grado di accettare messaggi fino a una lunghezza di 480 ottetti inclusi. Tutte le implementazioni di ricevitori di trasporto DOVREBBERO essere in grado di accettare messaggi fino a una lunghezza di 2048 ottetti inclusi. I ricevitori di trasporto POSSONO ricevere messaggi più lunghi di 2048 ottetti. Se un ricevitore di trasporto riceve un messaggio con una lunghezza maggiore di quella supportata, DOVREBBE troncare il payload. In alternativa, PUÒ scartare il messaggio.
Se un ricevitore di trasporto tronca i messaggi, il troncamento DEVE avvenire alla fine del messaggio. Dopo il troncamento, il messaggio PUÒ contenere codifica UTF-8 non valida o STRUCTURED-DATA non validi. Il ricevitore di trasporto PUÒ scartare il messaggio o PUÒ in questo caso tentare di elaborare quanto più possibile.
6.2. HEADER
Il set di caratteri utilizzato in HEADER DEVE essere ASCII a sette bit in un campo a otto bit, come descritto in [RFC5234]. Questi sono i codici ASCII come definiti in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968].
Il formato dell'intestazione è progettato per fornire una certa interoperabilità con il syslog tradizionale basato su BSD. I dettagli sono forniti nell'Appendice A.1.
6.2.1. PRI (Priorità)
La parte PRI DEVE avere tre, quattro o cinque caratteri ed è delimitata
da parentesi angolari come primo e ultimo carattere. La parte PRI inizia
con una "<" iniziale (carattere 'less-than', %d60), seguita da un numero,
seguito da un ">" (carattere 'greater-than', %d62). Il numero contenuto
tra queste parentesi angolari è chiamato valore di priorità (PRIVAL) e
rappresenta sia la Facility che la Severity. Il valore di priorità è
composto da una, due o tre cifre decimali (ABNF DIGITS) con valori da
%d48 (per "0") a %d57 (per "9").
I valori di Facility e Severity non sono normativi, ma sono comunemente utilizzati. Sono descritti nelle seguenti tabelle a solo scopo informativo. I valori di Facility DEVONO essere nell'intervallo da 0 a 23 inclusi.
| Codice numerico | Facility |
|---|---|
| 0 | Messaggi del kernel |
| 1 | Messaggi a livello utente |
| 2 | Sistema di posta |
| 3 | Daemon di sistema |
| 4 | Messaggi di sicurezza/autorizzazione |
| 5 | Messaggi generati internamente da syslogd |
| 6 | Sottosistema stampante di linea |
| 7 | Sottosistema news di rete |
| 8 | Sottosistema UUCP |
| 9 | Daemon orologio |
| 10 | Messaggi di sicurezza/autorizzazione |
| 11 | Daemon FTP |
| 12 | Sottosistema NTP |
| 13 | Audit log |
| 14 | Allarme log |
| 15 | Daemon orologio (nota 2) |
| 16 | Uso locale 0 (local0) |
| 17 | Uso locale 1 (local1) |
| 18 | Uso locale 2 (local2) |
| 19 | Uso locale 3 (local3) |
| 20 | Uso locale 4 (local4) |
| 21 | Uso locale 5 (local5) |
| 22 | Uso locale 6 (local6) |
| 23 | Uso locale 7 (local7) |
Tabella 1. Facility dei messaggi Syslog
Ogni priorità del messaggio ha anche un indicatore decimale del livello di gravità. Questi sono descritti nella seguente tabella insieme ai loro valori numerici. I valori di Severity DEVONO essere nell'intervallo da 0 a 7 inclusi.
| Codice numerico | Severity |
|---|---|
| 0 | Emergency: sistema inutilizzabile |
| 1 | Alert: azione richiesta immediatamente |
| 2 | Critical: condizioni critiche |
| 3 | Error: condizioni di errore |
| 4 | Warning: condizioni di avvertimento |
| 5 | Notice: condizione normale ma significativa |
| 6 | Informational: messaggi informativi |
| 7 | Debug: messaggi di livello debug |
Tabella 2. Severity dei messaggi Syslog
Il valore di priorità viene calcolato moltiplicando prima il numero di
Facility per 8 e poi aggiungendo il valore numerico della Severity. Ad
esempio, un messaggio del kernel (Facility=0) con una Severity di Emergency
(Severity=0) avrebbe un valore di priorità di 0. Allo stesso modo, un
messaggio "local use 4" (Facility=20) con una Severity di Notice
(Severity=5) avrebbe un valore di priorità di 165. Nel PRI di un messaggio
syslog, questi valori sarebbero posizionati tra le parentesi angolari come
<0> e <165> rispettivamente. L'unica volta in cui un valore di "0"
segue il "<" è per il valore di priorità di "0". Altrimenti, gli "0"
iniziali NON DEVONO essere utilizzati.
6.2.2. VERSION (Versione)
Il campo VERSION indica la versione della specifica del protocollo syslog. Il numero di versione DEVE essere incrementato per ogni nuova specifica del protocollo syslog che modifica qualsiasi parte del formato HEADER. Le modifiche includono l'aggiunta o la rimozione di campi o una modifica della sintassi o della semantica dei campi esistenti. Questo documento utilizza un valore VERSION di "1". I valori VERSION sono assegnati dalla IANA (Sezione 9.1) tramite il metodo Standards Action, come descritto in [RFC5226].
6.2.3. TIMESTAMP (Marca temporale)
Il campo TIMESTAMP è una marca temporale formalizzata derivata da [RFC3339]. Mentre [RFC3339] consente diverse sintassi, questo documento impone ulteriori restrizioni. Il valore TIMESTAMP DEVE seguire queste restrizioni:
- I caratteri "T" e "Z" in questa sintassi DEVONO essere maiuscoli.
- L'uso del carattere "T" è RICHIESTO.
- I secondi intercalari NON DEVONO essere utilizzati.
L'originator DOVREBBE includere TIME-SECFRAC se la precisione e le prestazioni del suo orologio lo consentono. L'SD-ID "timeQuality" descritto nella Sezione 7.1 consente all'originator di indicare la precisione e l'affidabilità della marca temporale.
Un'applicazione syslog DEVE utilizzare il NILVALUE come TIMESTAMP quando l'applicazione syslog non è in grado di ottenere l'ora del sistema.
6.2.3.1. Examples (Esempi)
Esempio 1
1985-04-12T23:20:50.52Z
Questo rappresenta 20 minuti e 50,52 secondi dopo le 23:00 del 12 aprile 1985 in UTC.
Esempio 2
1985-04-12T19:20:50.52-04:00
Questo rappresenta la stessa ora dell'Esempio 1, ma espressa in US Eastern Standard Time (osservando l'ora legale).
Esempio 3
2003-10-11T22:14:15.003Z
Questo rappresenta l'11 ottobre 2003 alle 22:14:15, 3 millisecondi nel secondo successivo. La marca temporale è in UTC. La marca temporale fornisce una risoluzione al millisecondo. L'originator potrebbe aver effettivamente avuto una risoluzione migliore, ma fornire solo tre cifre per la frazione di secondo non ce lo dice.
Esempio 4
2003-08-24T05:14:15.000003-07:00
Questo rappresenta il 24 agosto 2003 alle 05:14:15, 3 microsecondi nel secondo successivo. La risoluzione al microsecondo è indicata dalle cifre aggiuntive in TIME-SECFRAC. La marca temporale indica che la sua ora locale è -7 ore da UTC. Questa marca temporale potrebbe essere stata creata nel fuso orario del Pacifico degli Stati Uniti durante l'ora legale.
Esempio 5 - Un TIMESTAMP non valido
2003-08-24T05:14:15.000000003-07:00
Questo esempio è quasi identico all'Esempio 4, ma specifica TIME-SECFRAC in nanosecondi. Ciò fa sì che TIME-SECFRAC sia più lungo delle 6 cifre consentite, rendendolo non valido.
6.2.4. HOSTNAME
Il campo HOSTNAME identifica la macchina che ha originariamente inviato il messaggio syslog.
Il campo HOSTNAME DOVREBBE contenere il nome host e il nome di dominio dell'originator nel formato specificato in STD 13 [RFC1034]. Questo formato è indicato in questo documento come Fully Qualified Domain Name (FQDN).
In pratica, non tutte le applicazioni syslog possono fornire un FQDN. Come tale, anche altri valori POSSONO essere presenti in HOSTNAME. Questo documento prevede l'uso di altri valori in tali situazioni. Un'applicazione syslog DOVREBBE fornire prima il valore più specifico disponibile. L'ordine di preferenza per il contenuto del campo HOSTNAME è il seguente:
- FQDN
- Indirizzo IP statico
- Nome host
- Indirizzo IP dinamico
- il NILVALUE
Se viene utilizzato un indirizzo IPv4, DEVE essere nel formato della notazione decimale puntata come utilizzato in STD 13 [RFC1035]. Se viene utilizzato un indirizzo IPv6, DEVE essere utilizzata una rappresentazione testuale valida, come descritto in [RFC4291], Sezione 2.2.
Le applicazioni syslog DOVREBBERO utilizzare in modo coerente lo stesso valore nel campo HOSTNAME il più a lungo possibile.
Il NILVALUE DOVREBBE essere utilizzato solo quando l'applicazione syslog non ha modo di ottenere il suo vero nome host. Questa situazione è considerata altamente improbabile.
6.2.5. APP-NAME (Nome dell'applicazione)
Il campo APP-NAME DOVREBBE identificare il dispositivo o l'applicazione che ha generato il messaggio. È una stringa senza ulteriore semantica. È destinato al filtraggio dei messaggi su un relay o collector.
Il NILVALUE PUÒ essere utilizzato quando l'applicazione syslog non ha idea del suo APP-NAME o non può fornire tali informazioni. Potrebbe essere che un dispositivo non possa fornire queste informazioni a causa di una decisione di policy locale o perché le informazioni non sono disponibili o non applicabili sul dispositivo.
Questo campo PUÒ essere assegnato dall'operatore.
6.2.6. PROCID (ID del processo)
PROCID è un valore incluso nel messaggio che non ha significato interoperabile, tranne che una modifica del valore indica che c'è stata una discontinuità nella segnalazione syslog. Il campo non ha sintassi o semantica specifica; il valore dipende dall'implementazione e/o è assegnato dall'operatore. Il NILVALUE PUÒ essere utilizzato quando non viene fornito alcun valore.
Il campo PROCID è spesso utilizzato per fornire il nome del processo o l'ID del processo associato a un sistema syslog. Il NILVALUE potrebbe essere utilizzato quando non è disponibile alcun ID del processo. Su un sistema embedded senza un ID di processo del sistema operativo, PROCID potrebbe essere un ID di riavvio.
PROCID può consentire agli analizzatori di log di rilevare discontinuità nella segnalazione syslog rilevando una modifica nell'ID del processo syslog. Tuttavia, PROCID non è un'identificazione affidabile di un processo riavviato, poiché al processo syslog riavviato potrebbe essere assegnato lo stesso ID del processo del precedente processo syslog.
PROCID può anche essere utilizzato per identificare quali messaggi appartengono a un gruppo di messaggi. Ad esempio, un Mail Transfer Agent SMTP potrebbe inserire il suo ID di transazione SMTP in PROCID, il che consentirebbe al collector o relay di raggruppare i messaggi in base alla transazione SMTP.
6.2.7. MSGID (ID del messaggio)
Il MSGID DOVREBBE identificare il tipo di messaggio. Ad esempio, un firewall potrebbe utilizzare il MSGID "TCPIN" per il traffico TCP in entrata e il MSGID "TCPOUT" per il traffico TCP in uscita. I messaggi con lo stesso MSGID dovrebbero riflettere eventi della stessa semantica. Il MSGID stesso è una stringa senza ulteriore semantica. È destinato al filtraggio dei messaggi su un relay o collector.
Il NILVALUE DOVREBBE essere utilizzato quando l'applicazione syslog non fornisce o non può fornire alcun valore.
Questo campo PUÒ essere assegnato dall'operatore.
6.3. STRUCTURED-DATA (Dati strutturati)
STRUCTURED-DATA fornisce un meccanismo per esprimere informazioni in un formato di dati ben definito, facilmente analizzabile e interpretabile. Esistono diversi scenari di utilizzo. Ad esempio, può esprimere meta-informazioni sul messaggio syslog o informazioni specifiche dell'applicazione come contatori di traffico o indirizzi IP.
STRUCTURED-DATA può contenere zero, uno o più elementi di dati strutturati, indicati in questo documento come "SD-ELEMENT".
Nel caso di zero elementi di dati strutturati, il campo STRUCTURED-DATA DEVE contenere il NILVALUE.
Il set di caratteri utilizzato in STRUCTURED-DATA DEVE essere ASCII a sette bit in un campo a otto bit, come descritto in [RFC5234]. Questi sono i codici ASCII come definiti in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. Un'eccezione è il campo PARAM-VALUE (vedere Sezione 6.3.3), in cui DEVE essere utilizzata la codifica UTF-8.
Un collector PUÒ ignorare elementi STRUCTURED-DATA non corretti. Un relay DEVE inoltrare STRUCTURED-DATA non corretti senza alcuna modifica.
6.3.1. SD-ELEMENT
Un SD-ELEMENT consiste in un nome e coppie nome-valore del parametro. Il nome è indicato come SD-ID. Le coppie nome-valore sono indicate come "SD-PARAM".
6.3.2. SD-ID
Gli SD-ID sono sensibili alle maiuscole e minuscole e identificano in modo univoco il tipo e lo scopo dell'SD-ELEMENT. Lo stesso SD-ID NON DEVE apparire più di una volta in un messaggio.
Esistono due formati per i nomi SD-ID:
-
I nomi che non contengono un carattere chiocciola ("@", ABNF %d64) sono riservati per essere assegnati tramite IETF Review, come descritto in BCP26 [RFC5226]. Attualmente, questi sono i nomi definiti nella Sezione 7. I nomi di questo formato sono validi solo se prima registrati presso l'IANA. I nomi registrati NON DEVONO contenere un carattere chiocciola ('@', ABNF %d64), un segno di uguale ('=', ABNF %d61), una parentesi quadra chiusa (']', ABNF %d93), un segno di virgolette ('"', ABNF %d34), spazi o caratteri di controllo (codice ASCII 127 e codici 32 o inferiori).
-
Chiunque può definire SD-ID aggiuntivi con nomi nel formato
name@<private enterprise number>, ad esempio,"ourSDID@32473". Il formato della parte prima del carattere chiocciola non è specificato; tuttavia, questi nomi DEVONO essere stringhe US-ASCII stampabili e NON DEVONO contenere un carattere chiocciola ('@', ABNF %d64), un segno di uguale ('=', ABNF %d61), una parentesi quadra chiusa (']', ABNF %d93), un segno di virgolette ('"', ABNF %d34), spazi o caratteri di controllo. La parte dopo il carattere chiocciola DEVE essere un numero di impresa privata, come specificato nella Sezione 7.2.2. Si prega di notare che in tutto questo documento, il valore 32473 viene utilizzato per tutti i numeri di impresa privata. Questo valore è stato riservato dall'IANA per essere utilizzato come numero di esempio nella documentazione. Gli implementatori devono utilizzare il proprio numero di impresa privata per il parametro enterpriseId e quando creano nomi SD-ID estensibili localmente.
6.3.3. SD-PARAM (Parametro di dati strutturati)
Ogni SD-PARAM consiste in un nome, indicato come PARAM-NAME, e un valore, indicato come PARAM-VALUE.
PARAM-NAME è sensibile alle maiuscole e minuscole. L'IANA controlla tutti i PARAM-NAME, ad eccezione di quelli negli SD-ID i cui nomi contengono un carattere chiocciola. L'ambito di PARAM-NAME è all'interno di uno specifico SD-ID. Pertanto, valori PARAM-NAME con lo stesso nome contenuti in due SD-ID diversi non sono gli stessi.
Per supportare i caratteri internazionali, il campo PARAM-VALUE DEVE essere codificato utilizzando UTF-8. Un'applicazione syslog PUÒ emettere qualsiasi sequenza UTF-8 valida. Un'applicazione syslog DEVE accettare qualsiasi sequenza UTF-8 valida nella "forma più breve". NON DEVE fallire se sono presenti caratteri di controllo in PARAM-VALUE. L'applicazione syslog PUÒ modificare messaggi che contengono caratteri di controllo (ad esempio, cambiando un ottetto con il valore 0 (USASCII NUL) nei quattro caratteri "#000"). Per le ragioni esposte in UNICODE TR36 [UNICODE-TR36], Sezione 3.1, un originator DEVE codificare i messaggi nella "forma più breve", e un collector o relay NON DEVE interpretare messaggi nella "forma non più breve".
All'interno di PARAM-VALUE, i caratteri '"' (ABNF %d34), '\' (ABNF %d92)
e ']' (ABNF %d93) DEVONO essere escaped. Questo è necessario per evitare
errori di parsing. L'escaping di ']' non sarebbe strettamente necessario,
ma è RICHIESTO da questa specifica per evitare errori di implementazione
nelle applicazioni syslog. Ognuno di questi tre caratteri DEVE essere
escaped rispettivamente come \\", \\\\ e \\]. Il backslash viene
utilizzato per l'escaping dei caratteri di controllo per essere coerente
con il suo utilizzo nell'escaping in altre parti del messaggio syslog e
anche nel syslog tradizionale.
Un backslash ('\') che non è seguito da uno dei tre caratteri descritti viene considerato una sequenza di escape non valida. In questo caso, il backslash DEVE essere trattato come un backslash normale e il carattere seguente come un carattere normale. La sequenza non valida NON DEVE quindi essere modificata.
Un SD-PARAM PUÒ essere ripetuto più volte all'interno di un SD-ELEMENT.
6.3.4. Change Control (Controllo delle modifiche)
Una volta definiti gli SD-ID e i PARAM-NAME, la sintassi e la semantica di questi oggetti NON DEVONO essere modificate. Se si desidera una modifica a un SD-ID o PARAM-NAME esistente, gli SD-ID e PARAM-NAME già definiti DEVONO rimanere invariati e ne DEVE essere creato uno nuovo.
6.3.5. Examples (Esempi)
Esempio 1 - STRUCTURED-DATA validi
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]
In questo esempio, "exampleSDID@32473" è l'SD-ID; "iut",
"eventSource" e "eventID" sono nomi SD-PARAM.
Esempio 2 - Due elementi di dati strutturati
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
6.4. MSG (Messaggio)
La parte MSG contiene un messaggio di testo libero che fornisce informazioni sull'evento. Il set di caratteri utilizzato in MSG DOVREBBE essere UNICODE, codificato utilizzando UTF-8 come specificato in [RFC3629]. Se l'applicazione syslog non può codificare MSG in Unicode, PUÒ utilizzare qualsiasi altra codifica.
Le applicazioni syslog DOVREBBERO evitare l'uso di caratteri di controllo (codici USASCII 127 e codici 32 o inferiori) in MSG. Se un'applicazione syslog utilizza caratteri di controllo, potrebbe non essere possibile interpretare il messaggio sul collector o relay.
La codifica della parte MSG è determinata dal primo ottetto. Se il primo ottetto è il valore ABNF %xEF.BB.BF, questo è il Byte Order Mark (BOM) Unicode per UTF-8. In questo caso, MSG DEVE essere codificato in UTF-8 e NON DEVE contenere una BOM altrove. Se il primo ottetto non è il BOM, la codifica non è specificata.
Le applicazioni syslog tradizionali utilizzavano solo caratteri USASCII stampabili in MSG. Questa specifica consente l'uso di caratteri di controllo e altri valori di codice in MSG. Tuttavia, poiché ciò può causare problemi nella visualizzazione e nell'elaborazione generale dei messaggi, si RACCOMANDA che le applicazioni syslog utilizzino la stessa strategia di codifica delle applicazioni syslog tradizionali.
6.5. Examples (Esempi)
Esempio 1 - con BOM, UTF-8 multi-byte e 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...
In questo esempio, i caratteri UTF-8 multi-byte si trovano solo in MSG, e il "BOM" qui segna l'inizio della parte MSG. La codifica di questo messaggio syslog è tale da essere leggibile se la parte MSG viene interpretata come ISO 8859-1. Tuttavia, questo non sarebbe appropriato in questo caso, poiché questo messaggio inizia con un BOM. Dato ciò, il ricevitore DOVREBBE interpretare MSG come testo codificato UTF-8.
Esempio 2 - nessun 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.
Questo esempio mostra un messaggio senza STRUCTURED-DATA. Il NILVALUE "-" viene utilizzato sia nei campi MSGID che STRUCTURED-DATA. MSG stessa è testo libero.
Esempio 3 - con 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"]
Questo esempio mostra un messaggio con due SD-ELEMENT e nessuna parte MSG.