Questo documento descrive, a livello generale, il linguaggio di query di Logging che utilizzi per eseguire query e filtrare i dati di Cloud Logging.
Per informazioni dettagliate sulla progettazione del linguaggio di query di Logging, consulta le specifiche formali delle API di Google per il filtraggio.
Per esempi di query comuni che potresti voler utilizzare, vedi Query di esempio con Esplora log.
Panoramica
Puoi utilizzare il linguaggio di query Logging in Esplora log nella consoleGoogle Cloud , nell'API Logging o nell'interfaccia a riga di comando. Puoi utilizzare il linguaggio di query di Logging per eseguire query sui dati e scrivere filtri per creare sink e metriche basate su log.
Una query è un'espressione booleana che specifica un sottoinsieme di tutte le voci di log nella risorsa Google Cloud selezionata, ad esempio un progetto o una cartella Google Cloud .
Puoi creare query basate sul LogEntry
campo indicizzato utilizzando gli operatori logici AND
e OR
.
Utilizzando il campo resource.type
negli esempi seguenti, la
grammatica del linguaggio di query di Logging ha il seguente aspetto:
Limitazione semplice:
resource.type = "k8s_cluster"
Limitazione congiunta:
resource.type = "k8s_cluster" AND severity = "ERROR"
Limitazione disgiuntiva:
resource.type = "k8s_cluster" OR resource.type = "gce_instance"
- In alternativa:
resource.type = ("k8s_cluster" OR "gce_instance")
- In alternativa:
Espressione congiuntiva/disgiuntiva complessa:
resource.type = "k8s_cluster" AND (severity = "ERROR" OR "error")
Di seguito è riportato un esempio di query:
resource.type = "gce_instance" AND severity >= "ERROR" AND NOT textPayload:robot
Questa query corrisponde alle voci di log di Compute Engine con valori di gravità
pari almeno a ERROR
e il cui campo textPayload
non contiene la stringa
robot
. I confronti tra stringhe non sono sensibili alle maiuscole. I nomi
resource
, severity
e textPayload
sono definiti nel tipo
LogEntry
.
Notazione della sintassi
Le sezioni seguenti forniscono una panoramica della sintassi del linguaggio di query di Logging e descrivono in dettaglio la struttura delle query e la modalità di esecuzione della corrispondenza. Alcuni esempi utilizzano i commenti per fornire testo esplicativo.
Tieni presente quanto segue:
La lunghezza di una query non può superare i 20.000 caratteri.
Il linguaggio di query di Logging non fa distinzione tra maiuscole e minuscole, ad eccezione delle espressioni regolari e degli operatori logici, come
AND
eOR
. Gli operatori logici devono essere in maiuscolo.
Riepilogo della sintassi
La sintassi del linguaggio di query di Logging può essere pensata in termini di query e confronti.
Una query è una stringa contenente un'espressione:
expression = ["NOT"] comparison { ("AND" | "OR") ["NOT"] comparison }
Un confronto è un singolo valore o un'espressione booleana:
"The cat in the hat" resource.type = "k8s_cluster"
La prima riga è un esempio di confronto che è un singolo valore. Questi
tipi di confronti sono limitazioni globali. Ogni campo di una voce di log viene
confrontato con il valore utilizzando implicitamente l'operatore has. Per questo
esempio, se un campo di un LogEntry
o il relativo payload contiene la frase
"Il gatto con il cappello", il confronto ha esito positivo.
La seconda riga è un esempio di confronto che è un'espressione booleana della forma [FIELD_NAME] [OP] [VALUE]
. Un confronto è composto da tre componenti:
[FIELD_NAME]
è un campo in una voce di log. Ad esempio,resource.type
.[OP]
è un operatore di confronto. Ad esempio,=
.[VALUE]
è un numero, una stringa, una funzione o un'espressione tra parentesi. Ad esempio,"k8s_cluster"
. Per i valori null JSON, utilizzaNULL_VALUE
.
Operatori booleani
Gli operatori booleani AND
e OR
sono
operatori di cortocircuito.
L'operatore NOT
ha la precedenza più alta, seguito da OR
e AND
in quest'ordine. Ad esempio, le seguenti due espressioni sono equivalenti:
"a" OR NOT "b" AND NOT "c" OR "d" ("a" OR (NOT "b")) AND ((NOT "c") OR "d")
Puoi omettere l'operatore AND
tra i confronti. Puoi anche sostituire
l'operatore NOT
con l'operatore -
(meno). Ad esempio, le seguenti due query sono identiche:
a="b" AND c="d" AND NOT e="f" a="b" c="d" -e="f"
Questa documentazione utilizza sempre AND
e NOT
.
Per tutti i filtri, ad eccezione di quelli utilizzati dalle visualizzazioni log, puoi utilizzare gli operatori AND
, OR
e NOT
. Le visualizzazioni di log supportano solo le operazioni AND
e
NOT
.
Per combinare le regole AND
e OR
nella stessa espressione, devi nidificare le regole utilizzando le parentesi. Se non utilizzi le parentesi, la query potrebbe non
funzionare come previsto.
Gli operatori booleani devono sempre essere scritti in maiuscolo. and
, or
e not
in minuscolo vengono analizzati come termini di ricerca.
Confronti
I confronti hanno il seguente formato:
[FIELD_NAME] [OP] [VALUE]
Un confronto è composto da tre componenti:
[FIELD_NAME]: è l'identificatore del percorso di un campo in una voce di log. Di seguito sono riportati esempi di questi identificatori:
resource.type resource.labels.zone resource.labels.project_id insertId jsonPayload.httpRequest.protocol labels."compute.googleapis.com/resource_id"
Se un componente di un identificatore del percorso del campo contiene caratteri speciali, il componente deve essere racchiuso tra virgolette doppie. Ad esempio,
compute.googleapis.com/resource_id
deve essere racchiuso tra virgolette doppie perché contiene una barra/
.Per maggiori dettagli, consulta la sezione Identificatori del percorso del campo di questo documento.
[OP]: è un operatore di confronto, uno dei seguenti:
= -- equal != -- not equal > < >= <= -- numeric ordering : -- "has" matches any substring in the log entry field =~ -- regular expression search for a pattern !~ -- regular expression search not for a pattern
Per scoprire come cercare le voci di log utilizzando le espressioni regolari, vedi Utilizzo delle espressioni regolari.
- [VALUE]: è un numero, una stringa, una funzione o un'espressione tra parentesi.
Le stringhe vengono utilizzate per rappresentare testo arbitrario, oltre a valori booleani, di enumerazione e di stringhe di byte. Il valore
[VALUE]
viene convertito nel tipo di campo prima del confronto. Per i valori null JSON, utilizzaNULL_VALUE
.
Per filtrare in base a un valore nullo JSON, utilizza la seguente sintassi:
jsonPayload.field = NULL_VALUE -- includes "field" with null value NOT jsonPayload.field = NULL_VALUE -- excludes "field" with null value
Se [VALUE]
è una combinazione booleana tra parentesi di confronti,
il nome del campo e l'operatore di confronto vengono applicati a ogni elemento.
Ad esempio:
jsonPayload.cat = ("longhair" OR "shorthair") jsonPayload.animal : ("nice" AND "pet")
Il primo confronto verifica che il campo cat
abbia il valore "longhair" o
"shorthair". La seconda verifica che il valore del campo animal
contenga
entrambe le parole "nice" e "pet", in qualsiasi ordine.
Identificatori del percorso del campo
Tutte le voci di log sono istanze di tipo LogEntry
. L'identificatore
che è (o inizia) il lato sinistro di un confronto deve essere un
campo definito nel tipo LogEntry
. Per informazioni dettagliate sugli identificatori possibili
e sui relativi valori, consulta il tipo LogEntry
.
Ecco l'elenco attuale dei campi delle voce di log. Ogni campo è seguito dal livello successivo di nomi per quel campo, se applicabile:
httpRequest
: {cacheFillBytes
,cacheHit
,cacheLookup
,cacheValidatedWithOriginServer
,latency
,protocol
,referer
,remoteIp
,requestMethod
,requestSize
,requestUrl
,responseSize
,serverIp
,status
,userAgent
}insertId
jsonPayload
{ variable }labels
{ variable }logName
metadata
{systemLabels
,userLabels
}operation
{id
,producer
,first
,last
}protoPayload
{@type
, variable }receiveTimestamp
resource
{type
,labels
}severity
sourceLocation
: {file
,line
,function
}spanId
textPayload
timestamp
trace
Di seguito sono riportati esempi di identificatori del percorso del campo che puoi utilizzare nei confronti:
resource.type: se il primo identificatore di percorso è
resource
, l'identificatore successivo deve essere un campo del tipoMonitoredResource
.httpRequest.latency: se il primo identificatore di percorso è
httpRequest
, allora l'identificatore successivo deve essere un campo del tipoHttpRequest
.labels.[KEY] Se il primo identificatore del percorso è
labels
, l'identificatore successivo,[KEY]
, deve essere una delle chiavi delle coppie chiave-valore visualizzate nel campolabels
.logName: poiché il campo
logName
è una stringa, non puoi seguirlo con alcun nome di sottocampo.
Quando esegui query sui campi map o struct, devi conservare il formato e la distinzione tra maiuscole e minuscole delle chiavi nell'espressione.
Ad esempio, jsonPayload
è un campo struct, quindi un nome di campo nidificato all'interno di jsonPayload
come jsonPayload.end_time
è diverso da jsonPayload.endTime
. Allo stesso modo, per un campo della mappa come labels
, la chiave dell'etichetta
labels.env_name
è diversa da labels.envName
. Al contrario, quando
esegui una query sul campo del buffer del protocollo normale
protoPayload, non
devi conservare la distinzione tra maiuscole e minuscole.
Per informazioni sui tipi di campi LogEntry
, consulta il riferimento
google.logging.v2.
Caratteri speciali
Se un campo LogEntry
contiene caratteri speciali, il campo log deve essere racchiuso tra virgolette.
Ad esempio:
jsonPayload.":name":apple jsonPayload."foo.bar":apple jsonPayload."\"foo\"":apple
Per l'elenco dei caratteri speciali, consulta la sezione string
in
Valori e conversioni.
Per ulteriori informazioni sull'utilizzo degli identificatori del percorso del campo che fanno riferimento a oggetti o array, consulta Tipi di oggetti e array in questo documento.
Tipi di risorse monitorate
Per query più rapide, specifica un tipo di risorsa monitorata. Per un elenco dei tipi di risorse, consulta Tipi di risorse monitorate.
Ad esempio, le VM Compute Engine utilizzano il tipo di risorsa gce_instance
e le istanze Amazon EC2 utilizzano aws_ec2_instance
. L'esempio seguente mostra
come limitare le query a entrambi i tipi di VM:
resource.type = ("gce_instance" OR "aws_ec2_instance")
I valori del tipo di risorsa monitorata nei log vengono indicizzati. L'utilizzo di corrispondenze di sottostringhe per questi campi comporta query più lente.
Campi mancanti
Se utilizzi il nome di un campo in una query e questo campo non viene visualizzato in una voce di log, il campo è mancante, non definito o impostato come predefinito:
Se il campo fa parte del payload della voce di log (
jsonPayload
oprotoPayload
) o se si trova in un'etichetta nella sezionelabels
della voce di log, il campo è mancante. L'utilizzo di un campo mancante non mostrerà un errore, ma tutti i confronti che utilizzano campi mancanti non andranno a buon fine in modo invisibile.Esempi:
jsonPayload.nearest_store
,protoPayload.name.nickname
Se il campo è definito nel tipo
LogEntry
, il campo è impostato come predefinito. I confronti vengono eseguiti come se il campo fosse presente e avesse il valore predefinito.Esempi:
httpRequest.remoteIp
,trace
,operation.producer
In caso contrario, il campo è undefined, ovvero un errore rilevato prima dell'utilizzo della query.
Esempi:
thud
,operation.thud
,textPayload.thud
Per verificare se esiste un campo mancante o predefinito senza testare un valore
specifico nel campo, utilizza il confronto :*
. Ad esempio, il seguente confronto ha esito positivo se il campo operation.id
è presente in modo esplicito in una voce di log:
operation.id:*
Tieni presente il comportamento delle seguenti query:
Quando utilizzi l'operatore booleano
NOT
su un campo mancante, il risultato èTRUE
:-- Returns TRUE NOT missingField=foo
Quando utilizzi l'operatore di confronto diverso da
!=
su un campo mancante, il risultato èFALSE
:-- Returns FALSE missingField!=foo
Tipi di oggetti e array
Ogni campo della voce di log può contenere uno scalare, un oggetto o un array.
Un campo scalare memorizza un singolo valore, ad esempio
174.4
o-1
. Unstring
è considerato anche uno scalare. Anche i campi che possono essere convertiti in (o da) una stringa, comeDuration
eTimestamp
, sono tipi scalari.Un tipo di oggetto memorizza una raccolta di valori denominati, come il seguente valore JSON:
{"age": 24, "height": 67}
Puoi fare riferimento al valore all'interno di un oggetto. Ad esempio, se
jsonPayload.x
conteneva il valore precedente,jsonPayload.x.age
avrebbe il valore24
.Un campo array memorizza un elenco di valori, tutti dello stesso tipo. Ad esempio, un campo contenente misurazioni potrebbe avere un array di numeri:
{8.5, 9, 6}
Quando vengono eseguiti confronti e
[FIELD_NAME]
è un campo array, ogni membro dell'array viene confrontato con[VALUE]
e i risultati vengono uniti utilizzando l'operatoreOR
. Ad esempio, sejsonPayload.shoeSize
è un campo array che memorizza{8.5, 9, 6}
, il confronto:jsonPayload.shoeSize < 7
è equivalente a:
8.5 < 7 OR 9 < 7 OR 6 < 7
In questo esempio, il confronto complessivo risulta riuscito.
Valori e conversioni
Il primo passaggio per valutare un confronto consiste nel convertire il valore sul lato destro
nel tipo di campo della voce di log. I tipi di campi scalari sono consentiti nei
confronti, insieme a due tipi aggiuntivi i cui valori sono rappresentati come
stringhe: Duration
e Timestamp
. Per un elenco dei tipi scalari, consulta l'elenco dei
tipi di buffer di protocollo scalari. La tabella seguente spiega
quali valori possono essere convertiti nei tipi di campi log:
Tipo di campo | Valore di query consentito |
---|---|
bool |
"True" o "false" in qualsiasi caso. Esempi: "True", "true" |
bytes |
Una stringa contenente qualsiasi sequenza di byte. Esempio: "\377\377". |
Duration |
Una stringa contenente un numero decimale con segno seguito da una delle unità "ns", "us", "ms", "s", "m" o "h". Le durate sono precise al nanosecondo. Esempio: "3.2s". |
enum |
Il nome di un valore letterale di tipo enumerazione, senza distinzione tra maiuscole e minuscole. Esempi: "WARNING", che è un valore di tipo LogSeverity. |
double |
Qualsiasi numero, con o senza segno e parte esponente, o le stringhe di valori speciali "NaN", "-Infinity" e "Infinity" (con o senza maiuscole). Esempi: "-3.2e-8", "nan". |
intNN |
Qualsiasi numero intero con segno che non superi le dimensioni del tipo. Esempio: "-3". |
string |
Qualsiasi stringa che contenga testo codificato in UTF-8 o ASCII a 7 bit. Le virgolette incorporate devono essere precedute da una barra rovesciata. I valori stringa devono essere racchiusi tra virgolette doppie per eseguire l'escape dei seguenti caratteri speciali:
|
Timestamp |
Una stringa in formato
RFC 3339
o ISO 8601.
Esempi: "2024-08-02T15:01:23.045Z" (RFC 3339),
"2024-08-02" (ISO 8601). Nelle espressioni di query, i timestamp in formato RFC 3339
possono specificare un fuso orario con "Z" o |
uintNN |
Qualsiasi numero intero senza segno che non superi le dimensioni del tipo. Esempio: "1234". |
Se un tentativo di conversione non va a buon fine, il confronto non va a buon fine.
Quando una conversione richiede una stringa, puoi utilizzare anche un numero o un testo senza virgolette se non contengono caratteri speciali come spazi e operatori. Allo stesso modo, quando una conversione richiede un numero, puoi utilizzare una stringa il cui contenuto è un numero.
I tipi intNN
e uintNN
rappresentano tipi interi di varie dimensioni, ad esempio
int32
e uint64
. Quando scrivi un valore da convertire in un tipo di numero intero a 64 bit, scrivi il valore come stringa, ad esempio "9223372036854775807".
Tipi di campi di log
Ecco come viene determinato il tipo di un campo di una voce di log:
I campi di log definiti nel tipo
LogEntry
e nel tipo di componente sono campi del buffer del protocollo. I campi del buffer del protocollo hanno tipi espliciti.I campi di log che fanno parte degli oggetti
protoPayload
sono anche campi protocol buffer e hanno tipi espliciti. Il nome del tipo di buffer del protocollo è memorizzato nel campo"@type"
diprotoPayload
. Per ulteriori informazioni, consulta la mappatura JSON.Quando filtri in base a un campo associato al tipo di messaggio
Any
, il campovalue
viene attraversato automaticamente. Pertanto, non includerlo nella query. Per saperne di più, vedi Risoluzione dei problemi.I campi log all'interno di
jsonPayload
hanno tipi dedotti dal valore del campo quando viene ricevuta la voce di log:- I campi i cui valori sono numeri senza virgolette hanno il tipo
double
. - I campi i cui valori sono
true
ofalse
hanno il tipobool
. - I campi i cui valori sono stringhe hanno il tipo
string
.
I numeri interi lunghi (64 bit) vengono memorizzati nei campi stringa perché non possono essere rappresentati esattamente come valori
double
.- I campi i cui valori sono numeri senza virgolette hanno il tipo
I tipi
Duration
eTimestamp
vengono riconosciuti solo nei campi del buffer di protocollo. Altrove, questi valori vengono memorizzati nei campi stringa.
Commenti
I commenti iniziano con due trattini (--
) e qualsiasi testo che segue i trattini viene ignorato fino alla fine della riga. I commenti possono essere inseriti all'inizio di un filtro, tra i termini e alla fine di un filtro.
Potresti utilizzare i commenti nei seguenti casi:
Per annotare i filtri complessi con informazioni sulla funzione di una clausola:
-- All of our target users are emitted by Compute Engine instances. resource.type = "gce_instance" -- Looking for logs from "alex". jsonPayload.targetUser = "alex"
Per attivare o disattivare rapidamente una clausola aggiungendo o rimuovendo il prefisso del commento:
resource.type = "gce_instance" -- jsonPayload.targetUser = "alex" jsonPayload.targetUser = "kiran" -- jsonPayload.targetUser = "sasha"
Operatori di confronto
Il significato degli operatori di uguaglianza (=
, !=
) e disuguaglianza (<
, <=
, >
, >=
)
dipende dal tipo sottostante del nome del campo a sinistra.
- Tutti i tipi numerici: uguaglianza e disuguaglianza hanno il loro significato normale per i numeri.
bool
: l'uguaglianza indica lo stesso valore booleano. La disuguaglianza è definita datrue
>false
.enum
: l'uguaglianza indica lo stesso valore di enumerazione. La disuguaglianza utilizza i valori numerici sottostanti dei valori letterali di enumerazione.Duration
: l'uguaglianza indica la stessa durata. La disuguaglianza si basa sulla durata. Esempio: come durate,"1s"
>"999ms"
.Timestamp
: uguaglianza significa lo stesso istante nel tempo. Se a e b sono valoriTimestamp
, a < b significa che a è precedente a b.bytes
: gli operandi vengono confrontati byte per byte, da sinistra a destra.string
: I confronti ignorano la distinzione tra maiuscole e minuscole. Nello specifico, entrambi gli operandi vengono prima normalizzati utilizzando la normalizzazione Unicode NFKC_CF e poi vengono utilizzati confronti lessicografici. Tuttavia, le ricerche con espressioni regolari non vengono normalizzate. Per ulteriori informazioni sulla ricerca di voci di log utilizzando le espressioni regolari, vedi Utilizzo delle espressioni regolari.
L'operatore di sottostringa (:
) è applicabile a string
e bytes
ed è
gestito come l'uguaglianza, tranne per il fatto che l'operando destro deve essere uguale solo a una
parte del campo sinistro. Le corrispondenze di sottostringhe nei campi indicizzati non sfruttano
gli indici di log.
Limitazioni globali
Se il confronto è costituito da un singolo valore, viene chiamato
limitazione globale. La registrazione utilizza l'operatore has (:
) per determinare
se un campo in una voce di log o il relativo payload contiene la limitazione globale.
In questo caso, il confronto va a buon fine.
La query più semplice scritta in termini di limitazione globale è un singolo valore:
"The Cat in The Hat"
Puoi combinare le limitazioni globali utilizzando gli operatori AND
e OR
per una query più interessante. Ad esempio, se vuoi visualizzare tutte le voci di log
che hanno un campo che contiene cat
e un campo che contiene hat
o bat
, scrivi la query nel seguente modo:
("cat" AND ("hat" OR "bat"))
In questo caso, esistono tre limitazioni globali: cat
, hat
e bat
. Queste limitazioni globali vengono applicate separatamente e i risultati vengono combinati, proprio come se l'espressione fosse stata scritta senza parentesi.
Una limitazione globale è un modo per eseguire query nei log per un determinato valore.
Ad esempio, se stai cercando nel log delle attività voci contenenti qualsiasi
menzione di GCE_OPERATION_DONE
, puoi utilizzare la seguente query:
logName = "projects/my-project-id/logs/compute.googleapis.com%2Factivity_log" AND "GCE_OPERATION_DONE"
Anziché utilizzare restrizioni globali, che possono essere lente, ti consigliamo di utilizzare la
funzione SEARCH
integrata
e di eseguire query sui campi indicizzati. Per saperne di più,
consulta la sezione Trovare rapidamente le voci di log in questo documento.
Funzioni
Puoi utilizzare le funzioni integrate come limitazioni globali nelle query:
function = identifier ( [ argument { , argument } ] )
dove argument
è un valore, un nome campo o un'espressione tra parentesi.
Le funzioni sono descritte nelle sezioni seguenti.
log_id
La funzione log_id
è utile quando si crea una visualizzazione log personalizzata in un bucket log che contiene voci di log di molti progetti, cartelle o organizzazioni. Google Cloud
L'unico argomento della funzione log_id
è un ID log non codificato in URL:
log_id(non-URL-encoded log ID)
Ad esempio, la seguente query restituisce tutti i log di controllo delle attività:
log_id("cloudaudit.googleapis.com/activity")
Nella query precedente, l'argomento è costituito solo da
caratteri alfanumerici e caratteri speciali (/
, _
, -
, .
).
trasmettere
La funzione cast
accetta due parametri: il campo LogEntry
da convertire e il tipo di dati in cui viene convertito il campo:
cast([FIELD], [TYPE][, OPTION])
I parametri dell'espressione precedente sono definiti come segue:
[FIELD]
: il nome di un campo nella voce di log, ad esempiologName
ojsonPayload.a_field
.[TYPE]
: il tipo di dati, ad esempioSTRING
,INT64
,FLOAT64
,BOOL
.TIMESTAMP
oDURATION
: alcuni tipi di dati offrono opzioni aggiuntive, ad esempio la specifica di un fuso orario del database dei fusi orari IANA per il tipo di datiTIMESTAMP
.
Ad esempio, la seguente query esegue il cast del campo timestamp
in una STRINGA
e specifica il fuso orario America/New_York
:
cast(timestamp, STRING, TIME_ZONE("America/New_York")) =~ "^2025-04-02.*"
regexp_extract
Utilizza la funzione regexp_extract
per trovare la prima sottostringa che corrisponde a un'espressione regolare:
REGEXP_EXTRACT([FIELD], [REGULAR_EXPRESSION])
Nell'espressione precedente, i campi sono definiti come segue:
[FIELD]
: il nome di un campo nella voce di log, ad esempiologName
ojsonPayload.a_field
.[REGULAR_EXPRESSION]
: l'espressione regolare RE2 che deve contenere un gruppo di acquisizione ((...)
). Se è necessario un raggruppamento aggiuntivo per l'espressione regolare, deve essere utilizzato un gruppo non di acquisizione(?:...)
. Più gruppi di acquisizione o nessun gruppo di acquisizione generano un errore.
Puoi concatenare le funzioni cast
e regexp_extract
:
CAST(REGEXP_EXTRACT(CAST(timestamp, STRING), "\\d+:\\d+:(\\d+)"), INT64) < 30
L'esempio precedente esegue il cast del campo timestamp
come stringa. L'espressione
regolare acquisisce il valore del campo dei secondi dalla stringa timestamp
e lo converte in un numero intero per eseguire un confronto numerico. Il risultato della query
elenca una voce di log quando il campo dei secondi del timestamp è inferiore
a 30.
origine
La funzione source
corrisponde alle voci di log di una risorsa specifica nella gerarchia di organizzazioni, cartelle e progetti. Google Cloud
La funzione source
non corrisponde alle risorse secondarie. Ad esempio, l'utilizzo di
source(folders/folder_123)
corrisponde ai log della risorsa folder_123
e non ai log delle risorse del progetto Google Cloud all'interno di folder_123
.
Per eseguire query per i log a un determinato livello di risorsa, utilizza la seguente sintassi:
source(RESOURCE_TYPE/RESOURCE_ID)
Risorsa | Query di esempio |
---|---|
Organizzazione | source(organizations/ ORGANIZATION_ID) |
Cartella | source(folders/ FOLDER_ID) |
Google Cloud progetti | source(projects/ PROJECT_ID) |
esempio
La funzione sample
seleziona una frazione del numero totale di voci di log:
sample([FIELD], [FRACTION])
[FIELD]
è il nome di un campo nella voce di log, ad esempio logName
o
jsonPayload.a_field
. Il valore del campo determina se la voce di log
è nel campione. Il tipo di campo deve essere un valore stringa o numerico.
L'impostazione di [FIELD]
su insertId
è una buona scelta, perché ogni voce di log ha
un valore diverso per quel campo.
[FRACTION]
è la frazione di voci di log che hanno valori per [FIELD]
da
includere. È un numero maggiore di 0,0 e non superiore a 1,0. Ad esempio,
se specifichi 0.01
, il campione contiene circa l'1% di tutte le voci di log
che hanno valori per [FIELD]
. Se [FRACTION]
è 1, vengono scelte tutte le voci di log
che hanno valori per [FIELD]
.
Esempio: la seguente query restituisce il 25% delle voci di log
del log syslog
:
logName = "projects/my-project/logs/syslog" AND sample(insertId, 0.25)
Dettagli:
Per determinare se una voce di log è inclusa o esclusa dal campione, viene utilizzato un algoritmo deterministico basato sull'hashing. L'accuratezza del campione risultante dipende dalla distribuzione dei valori sottoposti ad hashing.
Se i valori sottoposti ad hashing non sono distribuiti in modo uniforme,
il campione risultante può essere distorto.
Nel caso peggiore, quando [FIELD]
contiene sempre lo stesso valore, il campione risultante contiene [FRACTION]
di tutte le voci di log o nessuna voce di log.
Se [FIELD]
viene visualizzato in una voce di log:
- Viene calcolato un hash del valore.
- Il valore hash, che è un numero, viene diviso per il valore hash massimo possibile.
- Se la frazione risultante è minore o uguale a
[FRACTION]
, la voce di log viene inclusa nel campione; in caso contrario, viene esclusa dal campione.
Se [FIELD]
non viene visualizzato in una voce di log:
- Se
[FIELD]
fa parte del payload o delle sezionilabels
della voce di log, la voce di log non viene selezionata per il campione, anche se[FRACTION]
è 1. - In caso contrario, la voce di log viene trattata come se
[FIELD]
fosse presente nella voce di log e il valore di[FIELD]
è il valore predefinito. Il valore predefinito è determinato dal tipoLogEntry
. Per saperne di più sui campi mancanti e predefiniti, consulta la sezione Campi mancanti in questo documento.
Per escludere dal campione le voci di log con campi predefiniti, utilizza l'operatore
field-exists, :*
. La seguente query produce un campione dell'1% delle voci di log che hanno fornito esplicitamente un valore per field
:
field:* AND sample(field, 0.01)
ip_in_net
La funzione ip_in_net
determina se un indirizzo IP in una voce di log è contenuto
in una subnet. Puoi utilizzare questo campo per sapere se una richiesta proviene da una fonte interna o esterna. Ad esempio:
ip_in_net([FIELD], [SUBNET])
[FIELD]
è un campo con valori stringa nella voce di log che contiene un indirizzo IP
o un intervallo. Il campo può essere ripetuto, nel qual caso solo uno dei campi ripetuti
deve contenere un indirizzo o un intervallo contenuto nella subnet.
[SUBNET]
è una costante stringa per un indirizzo o un intervallo IP. Si verifica un errore se
[SUBNET]
non è un indirizzo IP o un intervallo valido, come descritto più avanti in questa
sezione.
Esempio: la seguente query testa un indirizzo IP nel payload delle voci di log del log my_log
:
logName = "projects/my_project/logs/my_log" AND ip_in_net(jsonPayload.realClientIP, "10.1.2.0/24")
Dettagli: se in una voce di log [FIELD]
è mancante, predefinito o non
contiene un indirizzo o un intervallo IP legale, la funzione restituisce false. Per ulteriori
informazioni sui campi mancanti e predefiniti, consulta la sezione
Campi mancanti in questo documento.
Di seguito sono riportati alcuni esempi di indirizzi e intervalli IP supportati:
- IPv4:
10.1.2.3
- Subnet IPv4:
10.1.2.0/24
- CIDR IPv6:
1234:5678:90ab:cdef:1234:5678:90ab:cdef
- Subnet IPv6 CIDR:
1:2::/48
SEARCH
funzione
Puoi utilizzare la funzione integrata SEARCH
per trovare stringhe nei dati di log:
SEARCH([query]) SEARCH([field], [query])
Entrambe le forme della funzione SEARCH
contengono un argomento query
, che deve
essere formattato come valore stringa letterale. Nel primo modulo, viene eseguita la ricerca
nell'intera voce di log. Nel secondo modulo, specifica il campo della voce di log in cui eseguire la ricerca.
Devi specificare il campo query
. Se questo campo non viene specificato, viene restituito un errore.
Quando viene elaborata la funzione SEARCH
, la stringa query
viene elaborata da
un analizzatore di testo che la suddivide in token. Cloud Logging esegue sempre confronti senza distinzione tra maiuscole e minuscole, anche per i token racchiusi tra apici inversi. Questo comportamento è diverso da quello di BigQuery,
che conserva le maiuscole e minuscole nei token racchiusi tra apici inversi.
Per informazioni sulle regole dell'analizzatore, consulta il documento BigQuery
Regole dell'analizzatore di testo.
Quando crei una ricerca, considera quanto segue:
I token non distinguono tra maiuscole e minuscole. Le seguenti funzioni producono gli stessi risultati:
SEARCH("world") SEARCH("World")
Le funzioni precedenti corrispondono a una voce di log quando un singolo campo contiene il token "world". Poiché
SEARCH
esegue corrispondenze esatte e non corrispondenze di sottostringhe, le funzioni precedenti non corrispondono a un campo il cui valore è "worldwide".Se non specifichi il campo in cui eseguire la ricerca, la funzione
SEARCH
corrisponde a una voce di log quando questa contiene tutti i token. Tuttavia, l'ordine dei token non è importante e non è necessario che si trovino nello stesso campo della voce di log.Le seguenti funzioni producono gli stessi risultati e corrispondono a una voce di log che contiene i token "hello" e "world":
SEARCH("hello world") SEARCH("World hello")
Se specifichi il campo in cui eseguire la ricerca, la funzione
SEARCH
esegue la ricerca solo in quel campo. Si verifica una corrispondenza quando il campo contiene tutti i token; tuttavia, l'ordine dei token non ha importanza.Le seguenti funzioni producono una corrispondenza solo quando il campo
textPayload
contiene i token "hello" e "world":SEARCH(textPayload, "hello world")
Per imporre una corrispondenza esatta ma senza distinzione tra maiuscole e minuscole per una frase, racchiudi la frase tra apici inversi. Ad esempio, le seguenti funzioni corrispondono alla stringa "hello world":
SEARCH("`hello world`") SEARCH("`Hello World`") SEARCH("`HELLO WORLD`")
Poiché i backtick vengono utilizzati nelle seguenti funzioni, producono risultati diversi:
SEARCH("`hello world`") SEARCH("`world hello`")
Il linguaggio di query di Logging supporta diversi modi per cercare
i dati dei log. Quando cerchi una stringa, è più efficiente utilizzare la funzione
SEARCH
che eseguire una ricerca globale o una ricerca di sottostringhe.
Tuttavia, non puoi utilizzare la funzione SEARCH
per trovare corrispondenze nei campi non di testo.
Per indicazioni sull'esecuzione delle operazioni di ricerca, vedi
Ridurre al minimo le ricerche globali e di sottostringhe.
Ricerca per ora
Nell'interfaccia puoi impostare limiti specifici per la data e l'ora delle voci di log da visualizzare. Ad esempio, se aggiungi le seguenti condizioni alla query, il riquadro dei risultati mostra esattamente le voci di log nel periodo di 30 minuti indicato e non potrai scorrere al di fuori di questo intervallo di date:
timestamp >= "2023-11-29T23:00:00Z" timestamp <= "2023-11-29T23:30:00Z"
Quando scrivi una query con un timestamp, devi utilizzare date e ore nel formato mostrato in precedenza.
Puoi anche cercare voci di log utilizzando le scorciatoie timestamp
. Ad esempio,
puoi inserire una data con un operatore di confronto per ottenere tutte le voci di log successive a un
determinato giorno:
timestamp > "2023-11-29"
Utilizzo delle espressioni regolari
Puoi utilizzare le espressioni regolari per creare query e filtri per sink, metriche e ovunque vengano utilizzati i filtri di log. Ad esempio, puoi utilizzare le espressioni regolari in Esplora log e con Google Cloud CLI.
Un'espressione regolare è una sequenza di caratteri che definisce una ricerca. Il linguaggio di query di Logging utilizza la sintassi RE2. Per una spiegazione completa della sintassi RE2, consulta il wiki RE2 su GitHub.
Le query con espressioni regolari hanno le seguenti caratteristiche:
Solo i campi di tipo stringa possono essere abbinati a un'espressione regolare.
La normalizzazione delle stringhe non viene eseguita; ad esempio,
kubernetes
non è considerato uguale aKUBERNETES
. Per ulteriori informazioni, consulta la sezione Operatori di confronto.Le query sono sensibili alle maiuscole e non sono ancorate per impostazione predefinita.
Gli operatori booleani possono essere utilizzati tra più espressioni regolari sul lato destro degli operatori di confronto delle espressioni regolari,
=~
e!~
.
Una query con espressione regolare ha la seguente struttura:
Corrispondenza di un pattern:
jsonPayload.message =~ "regular expression pattern"
Non corrisponde a un pattern:
jsonPayload.message !~ "regular expression pattern"
=~
e !~
modificano la query in una query con espressione regolare e il
pattern che stai cercando di trovare deve essere racchiuso tra virgolette doppie. Per eseguire query
per pattern che contengono virgolette doppie, esegui l'escape utilizzando una
barra rovesciata.
Esempi di query dei log utilizzando le espressioni regolari
Tipo di query | Esempio |
---|---|
Query standard | sourceLocation.file =~ "foo" |
Query con ricerca non sensibile alle maiuscole | labels.subnetwork_name =~ "(?i)foo" |
Query contenente virgolette | jsonPayload.message =~ "field1=\"bar.*\"" |
Query utilizzando un valore booleano or |
labels.pod_name =~ "(foo|bar)" |
Query utilizzando gli ancoraggi | logName =~ "/my%2Flog$" |
Query che non corrisponde a un pattern | labels.pod_name !~ "foo" |
Query che utilizza l'operatore booleano | labels.env =~ ("^prod.*server" OR "^staging.*server") |
Query che inizia con un valore | logName =~ "^foo" |
Query che termina con un valore | logName =~ "foo$" |
Trovare rapidamente le voci di log
Per trovare le voci di log in modo efficiente:
- Esegui query utilizzando i campi indicizzati.
- Riduci al minimo il numero di voci di log da cercare.
Utilizzare i campi indicizzati
La registrazione indicizza sempre i seguenti campi LogEntry
:
- resource.type
- resource.labels.*
- logName
- severity
- timestamp
- insertId
- operation.id
- trace
- httpRequest.status
- labels.*
- split.uid
Puoi anche aggiungere campi indicizzati personalizzati a
qualsiasi bucket di log o utilizzare la funzione SEARCH
per accelerare la query.
Ottimizzare le query
Rendi più veloci le tue ricerche riducendo il numero di log, il numero di voci di log o l'intervallo di tempo delle ricerche. Ancora meglio, puoi ridurre tutti e tre.
Esempio: utilizzare la funzione SEARCH
Anziché eseguire ricerche globali o di sottostringhe, puoi utilizzare la funzione SEARCH
per utilizzare gli indici e ottimizzare le query.
Esempio: utilizza il nome del log corretto
Specifica il log contenente le voci di log che ti interessano. Assicurati di conoscere il nome effettivo del log esaminando una delle voci di log. Ad esempio, il riquadro dei risultati mostra che la sezione Compute Engine contiene un log denominato "activity". A un esame più attento delle voci di audit log delle attività di amministrazione, il log si chiama in realtà "cloudaudit.googleapis.com/activity".
Il seguente confronto è errato. Non corrisponde a nulla perché utilizza il nome log errato:
logName = "projects/my-project-id/logs/activity" -- WRONG!
Il seguente confronto è corretto. Sceglie le voci di log dalle voci di audit log delle attività di amministrazione. Devi codificare l'URL del nome del log, come mostrato di seguito:
logName = "projects/my-project-id/logs/cloudaudit.googleapis.com%2Factivity"
Esempio: scegliere le voci di log giuste
Se sai che le voci di log che ti interessano provengono da una particolare istanza VM, specificala. Verifica i nomi delle etichette corrette esaminando una delle voci di log che vuoi cercare. Nel seguente esempio,
instance_id
è una delle etichette indicizzate:
resource.type = "gce_instance" AND resource.labels.instance_id = "6731710280662790612" logName = "projects/my-project-id/logs/cloudaudit.googleapis.com%2Factivity"
Esempio: scegliere il periodo di tempo giusto
Specifica un periodo di tempo in cui eseguire la ricerca. Un modo rapido per determinare i timestamp utili
nel formato RFC 3339 è utilizzare il comando GNU/Linux date
:
$ date --rfc-3339=s 2023-06-27 17:39:00-04:00 $ date --rfc-3339=s --date="3 hours ago" 2023-06-27 14:40:00-04:00 $ date --rfc-3339=s --date="5 hours ago" 2023-06-27 12:40:00-04:00
Utilizza i valori di questi timestamp nelle query seguenti. Per creare un
timestamp accettabile per Logging, sostituisci lo spazio tra la
data e l'ora con la lettera T
.
Ad esempio, per eseguire una ricerca nelle ultime tre ore:
timestamp >= "2023-06-27T14:40:00-04:00"
Come altro esempio, per cercare tra le tre e le cinque ore precedenti:
timestamp >= "2023-06-27T12:40:00-04:00" AND timestamp <= "2023-06-27T14:40:00-04:00"
Ridurre al minimo le limitazioni disgiuntive
Le query che utilizzano solo restrizioni congiuntive, AND
, possono sfruttare meglio gli indici. Puoi utilizzare la limitazione disgiuntiva, OR
, ma queste query possono
essere lente e non possono utilizzare gli indici.
Ad esempio, SEARCH("foo") AND SEARCH("bar")
utilizza gli indici e sarà
più veloce di una query come SEARCH("foo") OR SEARCH("bar")
.
Ridurre al minimo le ricerche globali e di sottostringhe
Evita la tentazione di prendere scorciatoie quando digiti le query.
Esempio: non utilizzare ricerche globali
Se stai cercando una voce di log con "Hello Kitty" nel payload:
Non utilizzare una ricerca globale. Per un motivo, sono tutte ricerche di sottostringhe:
"Hello Kitty" -- THIS CAUSES A SLOW SEARCH!
Limita la ricerca a un singolo campo, anche se devi mantenere la ricerca di sottostringhe:
textPayload:"Hello Kitty"
Utilizza un test di uguaglianza se puoi:
textPayload = "Hello Kitty"
Fai riferimento a singoli campi in un payload se le voci di log hanno payload strutturati:
jsonPayload.my_favorite_cat = "Hello Kitty"
Utilizza un campo indicizzato per limitare la ricerca:
logName = "projects/my-project_id/logs/somelog" AND jsonPayload.my_favorite_cat = "Hello Kitty"
Utilizza la funzione
SEARCH
e specifica il testo completo da corrispondere. La funzioneSEARCH
esegue una corrispondenza che non distingue tra maiuscole e minuscole:SEARCH("
Hello Kitty
")Non utilizzare la funzione
SEARCH
e specificare un testo parziale. Ad esempio, la seguente funzione non corrisponde a "Hello Kitty".SEARCH("
Hello Kit
")
Esempi di ricerca
Le voci di log mostrate sono quelle che corrispondono a una query. Se il menu Vai all'ora contiene un valore, la visualizzazione scorre fino a quel momento. Ecco alcuni esempi di query:
resource.type=k8s_cluster
Trova tutte le voci di log di Google Kubernetes Engine. Per un elenco dei tipi di risorse, consulta l'elenco delle risorse monitorate.
Mentre digiti, il riquadro della query suggerisce i completamenti per i campi come
resource.type
.resource.type=k8s_cluster AND logName:request_log
Trova le voci di log per i cluster Google Kubernetes Engine dai nomi dei log contenenti
request_log
. Tieni presente diverse cose:- L'operatore
=
indica l'uguaglianza esatta. Il tipo di risorsa deve essere esattamente"k8s_cluster"
, ad eccezione della distinzione tra maiuscole e minuscole. - L'operatore
:
significa "ha". Il campologName
deve contenererequest_log
, in qualsiasi combinazione di maiuscole e minuscole. Il nome effettivo del log è molto più lungo. L'utilizzo di:
potrebbe rallentare le ricerche. - I due confronti sono uniti da
AND
. Puoi anche utilizzareOR
, maAND
viene considerato se ometti l'operatore.
- L'operatore
resource.type = (gce_instance OR aws_ec2_instance) AND severity >= ERROR
Trova voci di log con uno dei due tipi di risorse: istanza VM Compute Engine o istanza VM AWS EC2. Le voci di log devono avere
severity
di almenoERROR
, che equivale a selezionare ERROR nel menu di gravità dell'interfaccia di query.logName = "projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Factivity"
Trova tutte le voci di audit log delle attività di amministrazione nel progetto
[PROJECT_ID]
. Tutti gli audit log utilizzano lo stesso nome di log in un progetto, ma hanno tipi di risorse diversi. L'ID log,cloudaudit.googleapis.com/activity
, deve essere codificato nell'URL nel nome del log. L'utilizzo dell'uguaglianza nel confronto velocizza la ricerca. Per saperne di più, consulta Comprendere i log di controllo.unicorn
Trova le voci di log che contengono
unicorn
in qualsiasi campo, in qualsiasi caso. Un termine di ricerca che non fa parte di un confronto tra campi è una query "tutti i campi".unicorn phoenix
Trova le voci di log che contengono
unicorn
in un campo ephoenix
in un altro.textPayload:(unicorn phoenix)
Trova le voci di log il cui campo
textPayload
contiene siaunicorn
siaphoenix
in qualsiasi ordine.AND
è implicito tra le due parole.textPayload:"unicorn phoenix"
Trova le voci di log il cui campo
textPayload
contiene la stringa"unicorn phoenix"
.NOT textPayload: "unicorn phoenix"
Trova le voci di log il cui campo
textPayload
non contiene la stringa"unicorn phoenix"
. Questo tipo di query riduce le voci di log indesiderate.timestamp >= "2023-11-29T23:00:00Z" timestamp <= "2023-11-29T23:30:00Z"
Trova le voci di log in un periodo di 30 minuti.
Risoluzione dei problemi
Problemi di sintassi
Se hai problemi con le espressioni delle query, controlla quanto segue:
La query rispetta le regole di sintassi, con parentesi e virgolette corrispondenti.
I nomi dei campi voce di log sono scritti correttamente.
Le operazioni booleane sono in lettere maiuscole (
AND
,OR
,NOT
).Assicurati di utilizzare
NULL_VALUE
per rappresentare i valori null JSON.Le espressioni booleane come limitazioni globali o come lato destro dei confronti devono essere racchiuse tra parentesi per chiarezza. Ad esempio, le due query seguenti sembrano uguali, ma non lo sono:
insertId = "ABC-1" OR "ABC-2" -- ERROR!? insertId = ("ABC-1" OR "ABC-2")
Il testo senza virgolette non deve contenere caratteri speciali. In caso di dubbi, aggiungi le doppie virgolette. Ad esempio, nel seguente codice, il primo confronto non è valido a causa dell'operatore di sottostringa incorporato (
:
). Il confronto deve essere scritto tra virgolette:insertId = abc:def -- ILLEGAL! insertId = "abc:def"
Google Cloud CLI richiede che la query sia racchiusa tra virgolette doppie. Per utilizzare le virgolette doppie per l'escape dei caratteri speciali utilizzando il comando
gcloud logging
, racchiudi l'intera query tra virgolette singole:gcloud logging read 'resource.type=gce_instance AND jsonPayload.message="Stopped Unattended Upgrades Shutdown."' gcloud logging read 'timestamp>="2020-06-17T21:00:00Z"'
Quando filtri in base a un campo associato al tipo di messaggio
Any
, il campovalue
viene attraversato automaticamente. Pertanto, non includerevalue
nella query.Ad esempio, il campo
Status
in un messaggioAuditLog
ha un campodetails
di tipogoogle.protobuf.Any
. Per eseguire una query sul campodetails
, ometti il campovalue
quando specifichi il filtro:Azione
protoPayload.status.details.conditionNotMet.userVisibleMessage =~ "Specified reservation.*"
Cosa non fare
protoPayload.status.details.value.conditionNotMet.userVisibleMessage =~ "Specified reservation.*"