Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Processori configurabili di tipo parser Questa sezione contiene informazioni sui processori di analisi dei dati configurabili che è possibile utilizzare in un trasformatore di eventi di registro. **Contents** + [parseJSON](#CloudWatch-Logs-Transformation-parseJSON) + [grok](#CloudWatch-Logs-Transformation-Grok) + [Esempi di Grok](#Grok-Examples) + [Esempio 1: Usa grok per estrarre un campo da log non strutturati](#Grok-Example1) + [Esempio 2: usa grok in combinazione con parseJSON per estrarre campi da un evento di registro JSON](#Grok-Example3) + [Esempio 3: pattern Grok con annotazione punteggiata in FIELD\_NAME](#Grok-Example4) + [Schemi grok supportati](#Grok-Patterns) + [Esempi di formati di log comuni](#Common-Log-Examples) + [Esempio di log di Apache](#Apache-Log-Example) + [Esempio di log NGINX](#NGINX-Log-Example) + [Esempio di log del protocollo Syslog (RFC 5424)](#syslog5424-Log-Example) + [csv](#CloudWatch-Logs-Transformation-csv) + [parseKeyValue](#CloudWatch-Logs-Transformation-parseKeyValue) ## parseJSON Il processore **ParseJSON** analizza gli eventi di registro JSON e inserisce le coppie chiave-valore JSON estratte nella destinazione. Se non si specifica una destinazione, il processore posiziona la coppia chiave-valore sotto il nodo radice. Quando si utilizza `parseJSON` come primo processore, è necessario analizzare l'intero evento di registro utilizzandolo `@message` come campo di origine. Dopo l'analisi JSON iniziale, è possibile manipolare campi specifici nei processori successivi. Il `@message` contenuto originale non viene modificato, le nuove chiavi vengono aggiunte al messaggio. | Campo | Description | Obbligatorio? | Predefinita | Limits | | --- | --- | --- | --- | --- | | origine | Percorso del campo nel registro dell'evento che verrà analizzato. Usa la notazione a punti per accedere ai campi secondari. Ad esempio, store.book | No | `@message` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | | destinazione | Il campo di destinazione del file JSON analizzato | No | `Parent JSON node` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | **Esempio** Supponiamo che un evento di registro importato abbia il seguente aspetto: ``` { "outer_key": { "inner_key": "inner_value" } } ``` Quindi se abbiamo questo processore **ParseJson**: ``` [ { "parseJSON": { "destination": "new_key" } } ] ``` L'evento di registro trasformato sarebbe il seguente. ``` { "new_key": { "outer_key": { "inner_key": "inner_value" } } } ``` ## grok Usa il processore grok per analizzare e strutturare i dati non strutturati utilizzando il pattern matching. Questo processore può anche estrarre campi dai messaggi di registro. | Campo | Description | Obbligatorio? | Predefinita | Limits | Note | | --- | --- | --- | --- | --- | --- | | origine | Percorso del campo su cui applicare la corrispondenza Grok | No | `@message` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | | match | Il pattern grok da confrontare con l'evento log
| Sì | | Lunghezza massima: 512
Schemi di gruppo massimi: 20
Alcuni tipi di pattern grok hanno limiti di utilizzo individuali. Qualsiasi combinazione dei seguenti modelli può essere utilizzata fino a cinque volte: {URI, URIPARAM, URIPATHPARAM, SPACE, DATA, GREEDYDATA, GREEDYDATA\_MULTILINE}
I pattern Grok non supportano le conversioni di tipo.
Per i modelli di formato di log comuni (APACHE\_ACCESS\_LOG, NGINX\_ACCESS\_LOG, SYSLOG5424), è supportato l'inclusione solo dei modelli DATA, GREEDYDATA o GREEDYDATA\_MULTILINE dopo il modello di log comune. | [Vedi tutti i pattern Grok supportati](#Grok-Patterns) | **Struttura di un pattern Grok** Questa è la struttura del pattern grok supportata: ``` %{PATTERN_NAME:FIELD_NAME} ``` + **PATTERN\_NAME**: si riferisce a un'espressione regolare predefinita per la corrispondenza di un tipo specifico di dati. [Sono supportati solo i modelli grok predefiniti.](#Grok-Patterns) La creazione di modelli personalizzati non è consentita. + **FIELD\_NAME**: assegna un nome al valore estratto. `FIELD_NAME`è facoltativo, ma se non si specifica questo valore, i dati estratti verranno eliminati dall'evento di registro trasformato. Se `FIELD_NAME` utilizza la notazione punteggiata (ad esempio, «parent.child»), viene considerata un percorso JSON. + Conversione dei **tipi: le conversioni** di tipo esplicite non sono supportate. Usa il [TypeConverter processore](CloudWatch-Logs-Transformation-Datatype.md#CloudWatch-Logs-Transformation-typeConverter) per convertire il tipo di dati di qualsiasi valore estratto da grok. Per creare espressioni di corrispondenza più complesse, puoi combinare diversi modelli grok. È possibile combinare fino a 20 pattern grok per abbinare un evento log. Ad esempio, questa combinazione di pattern `%{NUMBER:timestamp} [%{NUMBER:db} %{IP:client_ip}:%{NUMBER:client_port}] %{GREEDYDATA:data}` può essere utilizzata per estrarre campi da una voce di slow log di Redis come questa: `1629860738.123456 [0 127.0.0.1:6379] "SET" "key1" "value1"` ### Esempi di Grok #### Esempio 1: Usa grok per estrarre un campo da log non strutturati Registro di esempio: ``` 293750 server-01.internal-network.local OK "[Thread-000] token generated" ``` Trasformatore utilizzato: ``` [ { "grok": { "match": "%{NUMBER:version} %{HOSTNAME:hostname} %{NOTSPACE:status} %{QUOTEDSTRING:logMsg}" } } ] ``` Output: ``` { "version": "293750", "hostname": "server-01.internal-network.local", "status": "OK", "logMsg": "[Thread-000] token generated" } ``` Registro di esempio: ``` 23/Nov/2024:10:25:15 -0900 172.16.0.1 200 ``` Trasformatore utilizzato: ``` [ { "grok": { "match": "%{HTTPDATE:timestamp} %{IPORHOST:clientip} %{NUMBER:response_status}" } } ] ``` Output: ``` { "timestamp": "23/Nov/2024:10:25:15 -0900", "clientip": "172.16.0.1", "response_status": "200" } ``` #### Esempio 2: usa grok in combinazione con parseJSON per estrarre campi da un evento di registro JSON Registro di esempio: ``` { "timestamp": "2024-11-23T16:03:12Z", "level": "ERROR", "logMsg": "GET /page.html HTTP/1.1" } ``` Trasformatore utilizzato: ``` [ { "parseJSON": {} }, { "grok": { "source": "logMsg", "match": "%{WORD:http_method} %{NOTSPACE:request} HTTP/%{NUMBER:http_version}" } } ] ``` Output: ``` { "timestamp": "2024-11-23T16:03:12Z", "level": "ERROR", "logMsg": "GET /page.html HTTP/1.1", "http_method": "GET", "request": "/page.html", "http_version": "1.1" } ``` #### Esempio 3: pattern Grok con annotazione punteggiata in FIELD\_NAME Registro di esempio: ``` 192.168.1.1 GET /index.html?param=value 200 1234 ``` Trasformatore utilizzato: ``` [ { "grok": { "match": "%{IP:client.ip} %{WORD:method} %{URIPATHPARAM:request.uri} %{NUMBER:response.status} %{NUMBER:response.bytes}" } } ] ``` Output: ``` { "client": { "ip": "192.168.1.1" }, "method": "GET", "request": { "uri": "/index.html?param=value" }, "response": { "status": "200", "bytes": "1234" } } ``` ### Schemi grok supportati Le tabelle seguenti elencano i modelli supportati dal `grok` processore. **Schemi di gruppo generali** | Modello Grok | Description | Limite massimo del pattern | Esempio | | --- | --- | --- | --- | | USERNAME o USER | Corrisponde a uno o più caratteri che possono includere lettere minuscole (a-z), lettere maiuscole (A-Z), cifre (0-9), punti (.), caratteri di sottolineatura (\_) o trattini (-) | 20 | Input: `user123.name-TEST`
Modello: `%{USERNAME:name}`
Uscita: `{"name": "user123.name-TEST"}` | | INT | Corrisponde a un segno più o meno opzionale seguito da una o più cifre. | 20 | Ingresso: `-456`
Modello: `%{INT:num}`
Uscita: `{"num": "-456"}` | | BASE10NUM | Corrisponde a un numero intero o a virgola mobile con segno e virgola decimale opzionali | 20 | Ingresso: `-0.67`
Modello: `%{BASE10NUM:num}`
Uscita: `{"num": "-0.67"}` | | BASE16NUM | Corrisponde ai numeri decimali ed esadecimali con un segno opzionale (\+ o -) e un prefisso 0x opzionale | 20 | Ingresso: `+0xA1B2`
Modello: `%{BASE16NUM:num}`
Uscita: `{"num": "+0xA1B2"}` | | PUNTO | Corrisponde a numeri interi positivi senza zeri iniziali, costituiti da una o più cifre (1-9 seguito da 0-9) | 20 | Ingresso: `123`
Modello: `%{POSINT:num}`
Uscita: `{"num": "123"}` | | NONNEGINT | Corrisponde a qualsiasi numero intero (composto da una o più cifre da 0 a 9) compresi zero e numeri con zeri iniziali. | 20 | Ingresso: `007`
Modello: `%{NONNEGINT:num}`
Uscita: `{"num": "007"}` | | PAROLA | Corrisponde a parole intere composte da uno o più caratteri di parola (\\ w), incluse lettere, cifre e caratteri di sottolineatura | 20 | Ingresso: `user_123`
Modello: `%{WORD:user}`
Uscita: `{"user": "user_123"}` | | NON SPAZIO | Corrisponde a uno o più caratteri diversi dagli spazi bianchi. | 5 | Ingresso: `hello_world123`
Modello: `%{NOTSPACE:msg}`
Uscita: `{"msg": "hello_world123"}` | | SPACE | Corrisponde a zero o più caratteri di spazio bianco. | 5 | Ingresso: `" "`
Modello: `%{SPACE:extra}`
Uscita: `{"extra": " "}` | | DATA | Corrisponde a qualsiasi carattere (eccetto la nuova riga) zero o più volte, non è avido. | 5 | Ingresso: `abc def ghi`
Modello: `%{DATA:x} %{DATA:y}`
Uscita: `{"x": "abc", "y": "def ghi"}` | | DATI AVIDI | Corrisponde a qualsiasi carattere (eccetto la nuova riga) zero o più volte, greedy. | 5 | Ingresso: `abc def ghi`
Modello: `%{GREEDYDATA:x} %{GREEDYDATA:y}`
Uscita: `{"x": "abc def", "y": "ghi"}` | | GREEDYDATA\_MULTILINE | Corrisponde a qualsiasi carattere (inclusa la nuova riga) zero o più volte, greedy. | 1 | Input:
`abc`
`def`
`ghi`
Modello: `%{GREEDYDATA_MULTILINE:data}`
Uscita: `{"data": "abc\ndef\nghi"}` | | STRINGA TRA VIRGOLETTE | Corrisponde alle stringhe tra virgolette (virgolette singole o doppie) ai caratteri con escape. | 20 | Ingresso: `"Hello, world!"`
Modello: `%{QUOTEDSTRING:msg}`
Uscita: `{"msg": "Hello, world!"}` | | UUID | Corrisponde a un formato UUID standard: 8 caratteri esadecimali, seguiti da tre gruppi di 4 caratteri esadecimali e termina con 12 caratteri esadecimali, tutti separati da trattini. | 20 | Ingresso: `550e8400-e29b-41d4-a716-446655440000`
Modello: `%{UUID:id}`
Uscita: `{"id": "550e8400-e29b-41d4-a716-446655440000"}` | | URNA | Corrisponde alla sintassi URN (Uniform Resource Name). | 20 | Ingresso: `urn:isbn:0451450523`
Modello: `%{URN:urn}`
Uscita: `{"urn": "urn:isbn:0451450523"}` | **AWS modelli grok** | Pattern | Description | Limite massimo del modello | Esempio | | --- | --- | --- | --- | | ARN | Corrisponde AWS ad Amazon Resource Names (ARNs), acquisendo la partizione (`aws`,, or`aws-us-gov`)`aws-cn`, il servizio, la regione, l'ID account e fino a 5 identificatori gerarchici di risorse separati da barre. Non ARNs corrisponderà alle informazioni mancanti tra i due punti. | 5 | Ingresso: `arn:aws:iam:us-east-1:123456789012:user/johndoe`
Modello: `%{ARN:arn}`
Uscita: `{"arn": "arn:aws:iam:us-east-1:123456789012:user/johndoe"}` | **Schemi di gruppo di rete** | Modello Grok | Description | Limite massimo del pattern | Esempio | | --- | --- | --- | --- | | CISCOMAC | Corrisponde a un indirizzo MAC in formato esadecimale 4-4-4. | 20 | Ingresso: `0123.4567.89AB`
Modello: `%{CISCOMAC:MacAddress}`
Uscita: `{"MacAddress": "0123.4567.89AB"}` | | WINDOWS MAC | Corrisponde a un indirizzo MAC in formato esadecimale con trattini | 20 | Ingresso: `01-23-45-67-89-AB`
Modello: `%{WINDOWSMAC:MacAddress}`
Uscita: `{"MacAddress": "01-23-45-67-89-AB"}` | | MAC COMUNE | Corrisponde a un indirizzo MAC in formato esadecimale con due punti. | 20 | Ingresso: `01:23:45:67:89:AB`
Modello: `%{COMMONMAC:MacAddress}`
Uscita: `{"MacAddress": "01:23:45:67:89:AB"}` | | MAC | Corrisponde a uno dei pattern grok CISCOMAC, WINDOWSMAC o COMMONMAC | 20 | Ingresso: `01:23:45:67:89:AB`
Modello: `%{MAC:m1}`
Uscita: `{"m1":"01:23:45:67:89:AB"}` | | IPV6 | Corrisponde IPv6 agli indirizzi, inclusi i moduli compressi e gli indirizzi IPv4 mappati IPv6 . | 5 | Ingresso: `2001:db8:3333:4444:5555:6666:7777:8888`
Modello: `%{IPV6:ip}`
Uscita: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | IPV4 | Corrisponde a un IPv4 indirizzo. | 20 | Ingresso: `192.168.0.1`
Modello: `%{IPV4:ip}`
Uscita: `{"ip": "192.168.0.1"}` | | IP | IPv6 Corrisponde agli indirizzi supportati da% {IPv6} o IPv4 agli indirizzi supportati da% {IPv4} | 5 | Ingresso: `192.168.0.1`
Modello: `%{IP:ip}`
Uscita: `{"ip": "192.168.0.1"}` | | HOSTNAME o HOST | Corrisponde ai nomi di dominio, inclusi i sottodomini | 5 | Ingresso: `server-01.internal-network.local`
Modello: `%{HOST:host}`
Uscita: `{"host": "server-01.internal-network.local"}` | | IP O HOST | Corrisponde a un nome host o a un indirizzo IP | 5 | Ingresso: `2001:db8:3333:4444:5555:6666:7777:8888`
Modello: `%{IPORHOST:ip}`
Uscita: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | HOSTPORT | Corrisponde a un indirizzo IP o a un nome host come supportato dal pattern% {IPORHOST} seguito da due punti e da un numero di porta, che nell'output registra la porta come «PORT». | 5 | Ingresso: `192.168.1.1:8080`
Modello: `%{HOSTPORT:ip}`
Uscita: `{"ip":"192.168.1.1:8080","PORT":"8080"}` | | URIHOST | Corrisponde a un indirizzo IP o a un nome host, come supportato dal pattern% {IPORHOST}, seguito facoltativamente da due punti e da un numero di porta, identificando la porta come «porta», se presente. | 5 | Ingresso: `example.com:443 10.0.0.1`
Modello: `%{URIHOST:host} %{URIHOST:ip}`
Uscita: `{"host":"example.com:443","port":"443","ip":"10.0.0.1"}` | **Schemi di gruppi di tracciati** | Modello Grok | Description | Limite massimo del pattern | Esempio | | --- | --- | --- | --- | | UNIXPATH | Corrisponde ai percorsi degli URL, inclusi potenzialmente i parametri di query. | 20 | Ingresso: `/search?q=regex`
Modello: `%{UNIXPATH:path}`
Uscita: `{"path":"/search?q=regex"}` | | PERCORSO VINCENTE | Corrisponde ai percorsi dei file di Windows. | 5 | Ingresso: `C:\Users\John\Documents\file.txt`
Modello: `%{WINPATH:path}`
Uscita: `{"path": "C:\\Users\\John\\Documents\\file.txt"}` | | PATH | Corrisponde ai percorsi dei file URL o Windows | 5 | Ingresso: `/search?q=regex`
Modello: `%{PATH:path}`
Uscita: `{"path":"/search?q=regex"}` | | TTY | Corrisponde ai percorsi dei dispositivi Unix per terminali e pseudo-terminali. | 20 | Ingresso: `/dev/tty1`
Modello: `%{TTY:path}`
Uscita: `{"path":"/dev/tty1"}` | | URIPROTO | Corrisponde alle lettere, seguite facoltativamente da un carattere più (\+) e lettere aggiuntive o caratteri più (\+) | 20 | Ingresso: `web+transformer`
Modello: `%{URIPROTO:protocol}`
Uscita: `{"protocol":"web+transformer"}` | | URIPATA | Corrisponde al componente del percorso di un URI | 20 | Ingresso: `/category/sub-category/product_name`
Modello: `%{URIPATH:path}`
Uscita: `{"path":"/category/sub-category/product_name"}` | | URIPARAM | Corrisponde ai parametri della query URL | 5 | Ingresso: `?param1=value1¶m2=value2`
Modello: `%{URIPARAM:url}`
Uscita: `{"url":"?param1=value1¶m2=value2"}` | | PARAMETRO URIPATH | Corrisponde a un percorso URI seguito facoltativamente da parametri di query | 5 | Ingresso: `/category/sub-category/product?id=12345&color=red`
Modello: `%{URIPATHPARAM:path}`
Uscita: `{"path":"/category/sub-category/product?id=12345&color=red"}` | | URI | Corrisponde a un URI completo | 5 | Ingresso: `https://user:password@example.com/path/to/resource?param1=value1¶m2=value2`
Modello: `%{URI:uri}`
Uscita: `{"path":"https://user:password@example.com/path/to/resource?param1=value1¶m2=value2"}` | **Schemi grok di data e ora** | Modello Grok | Description | Limite massimo del pattern | Esempio | | --- | --- | --- | --- | | MESE | Corrisponde ai nomi completi o abbreviati dei mesi inglesi a parole intere | 20 | Ingresso: `Jan`
Modello: `%{MONTH:month}`
Uscita: `{"month":"Jan"}`
Ingresso: `January`
Modello: `%{MONTH:month}`
Uscita: `{"month":"January"}` | | NUMERO DI MESI | Corrisponde ai numeri dei mesi da 1 a 12, con lo zero iniziale opzionale per i mesi a una cifra. | 20 | Ingresso: `5`
Modello: `%{MONTHNUM:month}`
Uscita: `{"month":"5"}`
Ingresso: `05`
Modello: `%{MONTHNUM:month}`
Uscita: `{"month":"05"}` | | MONTHNUM2 | Corrisponde ai numeri dei mesi a due cifre compresi tra 01 e 12. | 20 | Ingresso: `05`
Modello: `%{MONTHNUM2:month}`
Uscita: `{"month":"05"}` | | MESE/GIORNO | Corrisponde al giorno del mese compreso tra 1 e 31, con zero iniziale opzionale. | 20 | Ingresso: `31`
Modello: `%{MONTHDAY:monthDay}`
Uscita: `{"monthDay":"31"}` | | ANNO | Corrisponde all'anno in due o quattro cifre | 20 | Ingresso: `2024`
Modello: `%{YEAR:year}`
Uscita: `{"year":"2024"}`
Ingresso: `24`
Modello: `%{YEAR:year}`
Uscita: `{"year":"24"}` | | GIORNO | Corrisponde ai nomi dei giorni completi o abbreviati. | 20 | Ingresso: `Tuesday`
Modello: `%{DAY:day}`
Uscita: `{"day":"Tuesday"}` | | ORA | Corrisponde all'ora nel formato a 24 ore con uno zero iniziale opzionale (0) 0-23. | 20 | Ingresso: `22`
Modello: `%{HOUR:hour}`
Uscita: `{"hour":"22"}` | | MINUTO | Corrisponde ai minuti (00-59). | 20 | Ingresso: `59`
Modello: `%{MINUTE:min}`
Uscita: `{"min":"59"}` | | SECOND | Corrisponde a un numero che rappresenta i secondi (0) 0-60, seguito facoltativamente da un punto decimale o due punti e da una o più cifre per i minuti frazionari | 20 | Ingresso: `3`
Modello: `%{SECOND:second}`
Uscita: `{"second":"3"}`
Ingresso: `30.5`
Modello: `%{SECOND:minSec}`
Uscita: `{"minSec":"30.5"}`
Ingresso: `30:5`
Modello: `%{SECOND:minSec}`
Uscita: `{"minSec":"30:5"}` | | TIME | Corrisponde a un formato orario con ore, minuti e secondi nel formato (H) H:mm :( s) s. I secondi includono il secondo intercalare (0) 0-60. | 20 | Ingresso: `09:45:32`
Modello: `%{TIME:time}`
Uscita: `{"time":"09:45:32"}` | | DATA\_US | Corrisponde a una data nel formato (M) M/ (d) d/ (yy) yy o (M) M- (d) d- (yy) yy. | 20 | Ingresso: `11/23/2024`
Modello: `%{DATE_US:date}`
Uscita: `{"date":"11/23/2024"}`
Ingresso: `1-01-24`
Modello: `%{DATE_US:date}`
Uscita: `{"date":"1-01-24"}` | | DATE\_EU | Corrisponde alla data nel formato (d) d/ (M) M/ (yy) yy, (d) d- (M) M- (yy) yy o (d) d. (M) M. (yy) yy. | 20 | Ingresso: `23/11/2024`
Modello: `%{DATE_EU:date}`
Uscita: `{"date":"23/11/2024"}`
Ingresso: `1.01.24`
Modello: `%{DATE_EU:date}`
Uscita: `{"date":"1.01.24"}` | | ISO8601\_FUSO ORARIO | Corrisponde all'offset UTC 'Z' o all'offset del fuso orario con due punti opzionali nel formato [\+-] (H) H (:) mm. | 20 | Ingresso: `+05:30`
Modello: `%{ISO8601_TIMEZONE:tz}`
Uscita: `{"tz":"+05:30"}`
Ingresso: `-530`
Modello: `%{ISO8601_TIMEZONE:tz}`
Uscita: `{"tz":"-530"}`
Ingresso: `Z`
Modello: `%{ISO8601_TIMEZONE:tz}`
Uscita: `{"tz":"Z"}` | | ISO8601\_SECONDO | Corrisponde a un numero che rappresenta i secondi (0) 0-60, seguito facoltativamente da un punto decimale o due punti e da una o più cifre per frazioni di secondo | 20 | Ingresso: `60`
Modello: `%{ISO8601_SECOND:second}`
Uscita: `{"second":"60"}` | | TIMESTAMP\_ ISO8601 | Corrisponde al formato ISO8601 datetime (yy) yy- (M) M- (d) dT (H) H:mm :( (s) s) (Z\| [\+-] (H) H:mm) con secondi e fuso orario opzionali. | 20 | Ingresso: `2023-05-15T14:30:00+05:30`
Modello: `%{TIMESTAMP_ISO8601:timestamp}`
Uscita: `{"timestamp":"2023-05-15T14:30:00+05:30"}`
Ingresso: `23-5-1T1:25+5:30`
Modello: `%{TIMESTAMP_ISO8601:timestamp}`
Uscita: `{"timestamp":"23-5-1T1:25+5:30"}`
Ingresso: `23-5-1T1:25Z`
Modello: `%{TIMESTAMP_ISO8601:timestamp}`
Uscita: `{"timestamp":"23-5-1T1:25Z"}` | | DATE | Corrisponde a una data nel formato USA utilizzando% {DATE\_US} o nel formato UE utilizzando% {DATE\_EU} | 20 | Ingresso: `11/29/2024`
Modello: `%{DATE:date}`
Uscita: `{"date":"11/29/2024"}`
Ingresso: `29.11.2024`
Modello: `%{DATE:date}`
Uscita: `{"date":"29.11.2024"}` | | TIMBRO DATARIO | Corrisponde a% {DATE} seguito dallo schema% {TIME}, separato da uno spazio o da un trattino. | 20 | Ingresso: `29-11-2024 14:30:00`
Modello: `%{DATESTAMP:dateTime}`
Uscita: `{"dateTime":"29-11-2024 14:30:00"}` | | TZ | Corrisponde alle abbreviazioni dei fusi orari comuni (PST, PDT, MST, MDT, CST CDT, EST, EDT, UTC). | 20 | Ingresso: `PDT`
Modello: `%{TZ:tz}`
Uscita: `{"tz":"PDT"}` | | DATESTAMP\_ RFC822 | Corrisponde a data e ora nel formato: Day MonthName (D) D (YY) YY (H) H:mm :( s) s Timezone | 20 | Ingresso: `Monday Jan 5 23 1:30:00 CDT`
Modello: `%{DATESTAMP_RFC822:dateTime}`
Uscita: `{"dateTime":"Monday Jan 5 23 1:30:00 CDT"}`
Ingresso: `Mon January 15 2023 14:30:00 PST`
Modello: `%{DATESTAMP_RFC822:dateTime}`
Uscita: `{"dateTime":"Mon January 15 2023 14:30:00 PST"}` | | DATESTAMP\_ RFC2822 | Corrisponde al formato RFC2822 data-ora: Day, (d) d (yy) yy MonthName (H) H:mm :( s) s Z\| [\+-] (H) H:mm | 20 | Ingresso: `Mon, 15 May 2023 14:30:00 +0530`
Modello: `%{DATESTAMP_RFC2822:dateTime}`
Uscita: `{"dateTime":"Mon, 15 May 2023 14:30:00 +0530"}`
Ingresso: `Monday, 15 Jan 23 14:30:00 Z`
Modello: `%{DATESTAMP_RFC2822:dateTime}`
Uscita: `{"dateTime":"Monday, 15 Jan 23 14:30:00 Z"}` | | DATESTAMP\_OTHER | Corrisponde a data e ora nel formato: Giorno MonthName (d) d (H) H:mm :( s) s Fuso orario (yy) yy | 20 | Ingresso: `Mon May 15 14:30:00 PST 2023`
Modello: `%{DATESTAMP_OTHER:dateTime}`
Uscita: `{"dateTime":"Mon May 15 14:30:00 PST 2023"}` | | DATESTAMP\_EVENTLOG | Corrisponde al formato datetime compatto senza separatori: (yy) yYmm (d) d (H) Hmm (s) s | 20 | Ingresso: `20230515143000`
Modello: `%{DATESTAMP_EVENTLOG:dateTime}`
Uscita: `{"dateTime":"20230515143000"}` | **Schemi di gruppo logaritmici** | Modello Grok | Description | Limite massimo del pattern | Esempio | | --- | --- | --- | --- | | LIVELLO DI REGISTRO | Corrisponde ai livelli di log standard in diverse lettere maiuscole e abbreviazioni, tra cui:Alert/ALERT,Trace/TRACE,Debug/DEBUG,Notice/NOTICE,Info/INFO,,Warn/Warning/WARN/WARNING,Err/Error/ERR/ERROR, Crit/Critical/CRIT/CRITICAL Fatal/FATAL Severe/SEVERE Emerg/Emergency/EMERG/EMERGENCY | 20 | Ingresso: `INFO`
Modello: `%{LOGLEVEL:logLevel}`
Uscita: `{"logLevel":"INFO"}` | | HTTP: DATA | Corrisponde al formato di data e ora spesso utilizzato nei file di registro. Formato: (d) d/MonthName/(yy) yy :( H) H:mm :( s) s Fuso orario: corrisponde ai nomi completi o abbreviati dei mesi in inglese (esempio MonthName: «Jan» o «January») Fuso orario: corrisponde al modello% {INT} grok | 20 | Ingresso: `23/Nov/2024:14:30:00 +0640`
Modello: `%{HTTPDATE:date}`
Uscita: `{"date":"23/Nov/2024:14:30:00 +0640"}` | | TIMESTAMP SYSLOG | Corrisponde al formato della data con MonthName (d) d (H) H:mm :( s) s: corrisponde ai nomi completi o abbreviati dei mesi in inglese (esempio MonthName: «Jan» o «January») | 20 | Ingresso: `Nov 29 14:30:00`
Modello: `%{SYSLOGTIMESTAMP:dateTime}`
Uscita: `{"dateTime":"Nov 29 14:30:00"}` | | PROG | Corrisponde al nome di un programma composto da una stringa di lettere, cifre, punti, trattini bassi, barra, segno di percentuale e trattini. | 20 | Ingresso: `user.profile/settings-page`
Modello: `%{PROG:program}`
Uscita: `{"program":"user.profile/settings-page"}` | | SYSLOGPROG | Corrisponde al pattern PROG grok seguito facoltativamente da un ID di processo tra parentesi quadre. | 20 | Ingresso: `user.profile/settings-page[1234]`
Modello: `%{SYSLOGPROG:programWithId}`
Uscita: `{"programWithId":"user.profile/settings-page[1234]","program":"user.profile/settings-page","pid":"1234"}` | | SYSLOGHOST | Corrisponde a uno schema% {HOST} o% {IP} | 5 | Ingresso: `2001:db8:3333:4444:5555:6666:7777:8888`
Modello: `%{SYSLOGHOST:ip}`
Uscita: `{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | IMPIANTO SYSLOG | Corrisponde alla priorità syslog in formato decimale. Il valore deve essere racchiuso tra parentesi angolari (<>). | 20 | Ingresso: `<13.6>`
Modello: `%{SYSLOGFACILITY:syslog}`
Uscita: `{"syslog":"<13.6>","facility":"13","priority":"6"}` | **Schemi di log grok comuni** È possibile utilizzare modelli grok personalizzati predefiniti per abbinare i formati di registro Apache, NGINX e Syslog Protocol (RFC 5424). Quando si utilizzano questi modelli specifici, devono essere i primi modelli nella configurazione corrispondente e nessun altro modello può precederli. Inoltre, puoi seguirli solo con esattamente un **DATO**. **Pattern GREEDYDATA o GREEDYDATA\_MULTILINE****.** | Pattern grok | Description | Limite massimo del modello | | --- | --- | --- | | APACHE\_ACCESS\_LOG | Corrisponde ai log di accesso di Apache | 1 | | NGINX\_ACCESS\_LOG | Corrisponde ai log di accesso NGINX | 1 | | SYSLOG5424 | Corrisponde ai log del protocollo Syslog (RFC 5424) | 1 | Di seguito sono riportati esempi validi e non validi per l'utilizzo di questi modelli di formato di registro comuni. ``` "%{NGINX_ACCESS_LOG} %{DATA}" // Valid "%{SYSLOG5424}%{DATA:logMsg}" // Valid "%{APACHE_ACCESS_LOG} %{GREEDYDATA:logMsg}" // Valid "%{APACHE_ACCESS_LOG} %{SYSLOG5424}" // Invalid (multiple common log patterns used) "%{NGINX_ACCESS_LOG} %{NUMBER:num}" // Invalid (Only GREEDYDATA and DATA patterns are supported with common log patterns) "%{GREEDYDATA:logMsg} %{SYSLOG5424}" // Invalid (GREEDYDATA and DATA patterns are supported only after common log patterns) ``` #### Esempi di formati di log comuni ##### Esempio di log di Apache Registro di esempio: ``` 127.0.0.1 - - [03/Aug/2023:12:34:56 +0000] "GET /page.html HTTP/1.1" 200 1234 ``` Trasformatore: ``` [ { "grok": { "match": "%{APACHE_ACCESS_LOG}" } } ] ``` Output: ``` { "request": "/page.html", "http_method": "GET", "status_code": 200, "http_version": "1.1", "response_size": 1234, "remote_host": "127.0.0.1", "timestamp": "2023-08-03T12:34:56Z" } ``` ##### Esempio di log NGINX Registro di esempio: ``` 192.168.1.100 - Foo [03/Aug/2023:12:34:56 +0000] "GET /account/login.html HTTP/1.1" 200 42 "https://www.amazon.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36" ``` Trasformatore: ``` [ { "grok": { "match": "%{NGINX_ACCESS_LOG}" } } ] ``` Output: ``` { "request": "/account/login.html", "referrer": "https://www.amazon.com/", "agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36", "http_method": "GET", "status_code": 200, "auth_user": "Foo", "http_version": "1.1", "response_size": 42, "remote_host": "192.168.1.100", "timestamp": "2023-08-03T12:34:56Z" } ``` ##### Esempio di log del protocollo Syslog (RFC 5424) Registro di esempio: ``` <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"] ``` Trasformatore: ``` [ { "grok": { "match": "%{SYSLOG5424}" } } ] ``` Output: ``` { "pri": 165, "version": 1, "timestamp": "2003-10-11T22:14:15.003Z", "hostname": "mymachine.example.com", "app": "evntslog", "msg_id": "ID47", "structured_data": "exampleSDID@32473 iut=\"3\" eventSource= \"Application\" eventID=\"1011\"", "message": "[examplePriority@32473 class=\"high\"]" } ``` ## csv Il processore **csv** analizza i valori separati da virgole (CSV) dagli eventi di registro in colonne. | Campo | Description | Obbligatorio? | Predefinita | Limits | | --- | --- | --- | --- | --- | | origine | Percorso del campo nell'evento di registro che verrà analizzato | No | `@message` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | | delimitatore | Il carattere utilizzato per separare ogni colonna nell'evento di registro dei valori separati da virgole originale | No | `,` | Lunghezza massima: 1 a meno che il valore non sia o `\t` `\s` | | Cita carattere | Carattere utilizzato come qualificatore di testo per una singola colonna di dati | No | `"` | Lunghezza massima: 1 | | columns | Elenco di nomi da utilizzare per le colonne dell'evento di registro trasformato. | No | `[column_1, column_2 ...]` | Numero massimo di colonne CSV: 100
Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | | destinazione | Il campo principale in cui inserire le coppie chiave-valore trasformate | No | `Root node` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | L'impostazione `delimiter` su `\t` separerà ogni colonna su un carattere di tabulazione e `\t` separerà ogni colonna su un singolo carattere di spazio. **Esempio** Supponiamo che parte di un evento di registro importato abbia il seguente aspetto: ``` 'Akua Mansa':28:'New York: USA' ``` **Supponiamo di utilizzare solo il processore csv:** ``` [ { "csv": { "delimiter": ":", "quoteCharacter": "'" } } ] ``` L'evento di registro trasformato sarebbe il seguente. ``` { "column_1": "Akua Mansa", "column_2": "28", "column_3": "New York: USA" } ``` **Esempio 2** Supponiamo che un evento di registro importato abbia il seguente aspetto: ``` { "timestamp": "2024-11-23T16:03:12Z", "type": "user_data", "logMsg": "'Akua Mansa':28:'New York: USA'" } ``` Supponiamo di analizzare l'evento come JSON, loro analizzano un campo JSON con il processore **csv**, specificando i nomi delle colonne e la destinazione: ``` [ { "parseJSON": {} }, { "csv": { "source": "logMsg", "delimiter": ":", "quoteCharacter": "'", "columns":["name","age","location"], "destination": "msg" } } ] ``` L'evento di registro trasformato sarebbe il seguente. ``` { "timestamp": "2024-11-23T16:03:12Z", "logMsg": "'Akua Mansa':28:'New York: USA'", "type": "user_data", "msg": { "name": "Akua Mansa", "age": "28", "location": "New York: USA" } } ``` ## parseKeyValue Utilizzate il **parseKeyValue**processore per analizzare un campo specificato in coppie chiave-valore. È possibile personalizzare il processore per analizzare le informazioni sui campi con le seguenti opzioni. | Campo | Description | Obbligatorio? | Predefinita | Limits | | --- | --- | --- | --- | --- | | origine | Percorso del campo nel registro dell'evento che verrà analizzato | No | `@message` | Lunghezza massima: 128.
Profondità massima della chiave annidata: 3 | | destinazione | Il campo di destinazione in cui inserire le coppie chiave-valore estratte | No | | Lunghezza massima: 128. | | FieldDelimiter | La stringa delimitatrice di campo utilizzata tra coppie chiave-valore negli eventi del registro originale | No | `&` | Lunghezza massima: 128. | | keyValueDelimiter | La stringa delimitatrice da utilizzare tra la chiave e il valore in ogni coppia nell'evento di registro trasformato | No | `=` | Lunghezza massima: 128. | | nonMatchValue | Un valore da inserire nel campo del valore del risultato, quando una coppia chiave-valore non viene divisa correttamente. | No | | Lunghezza massima: 128. | | keyPrefix | Se vuoi aggiungere un prefisso a tutte le chiavi trasformate, specificalo qui. | No | | Lunghezza massima: 128. | | overwriteIfExists | Se sovrascrivere il valore se la chiave di destinazione esiste già | No | `false` | | **Esempio** Prendiamo il seguente esempio di evento di registro: ``` key1:value1!key2:value2!key3:value3!key4 ``` Supponiamo di utilizzare la seguente configurazione del processore: ``` [ { "parseKeyValue": { "destination": "new_key", "fieldDelimiter": "!", "keyValueDelimiter": ":", "nonMatchValue": "defaultValue", "keyPrefix": "parsed_" } } ] ``` L'evento di registro trasformato sarebbe il seguente. ``` { "new_key": { "parsed_key1": "value1", "parsed_key2": "value2", "parsed_key3": "value3", "parsed_key4": "defaultValue" } } ```