Questo documento spiega come trovare le voci di log instradate da cui hai eseguito il routing. Cloud Logging in tabelle BigQuery. Sink di Logging flussi di dati di logging in BigQuery in piccoli batch, il che consente di eseguire query sui dati senza eseguire un job di caricamento. Per aiutarti a creare query e comprendere il formato del tuo BigQuery, questo documento descrive anche le Schema di BigQuery per i log con routing.
Cloud Logging utilizza API di streaming legacy per creare un flusso di voci di log in BigQuery. In genere, le voci di log sono visibili in BigQuery entro un minuto. Tuttavia, quando viene creata una nuova tabella, potrebbero essere necessari diversi minuti prima che sono disponibili le prime voci di log.
Prima di iniziare
Per una discussione concettuale sui sink, vedi Panoramica dei modelli di routing e archiviazione: sink.
Per istruzioni su come eseguire il routing dei log, consulta Esegui il routing dei log alle destinazioni supportate.
Per informazioni su come vengono denominati i campi delle voci di voce di log, consulta Schema di BigQuery per i log con routing.
Visualizza i log
Per visualizzare i log indirizzati a BigQuery:
-
Nella console Google Cloud, vai alla pagina BigQuery:
Puoi trovare questa pagina anche utilizzando la barra di ricerca.
Nel riquadro Spazio di esplorazione, espandi il progetto e seleziona un set di dati.
Le voci di log sono visibili su la scheda Dettagli oppure puoi eseguire una query sulla tabella per restituire i dati.
Query di esempio
Per informazioni sulla sintassi delle query BigQuery, consulta Riferimento per le query. Sono particolarmente utili funzioni con caratteri jolly della tabella, che ti consente di eseguire query su più tabelle operatore flatten, che ti consente di per visualizzare i dati di campi ripetuti.
Query Compute Engine di esempio
La seguente query BigQuery recupera le voci di log da più giorni e più tipi di log:
La query cerca negli ultimi tre giorni i log
syslog
eapache-access
. La query è stata effettuata il 23 febbraio 2020 e riguarda tutte le voci di log ricevute il 21 e il 22 febbraio, più le voci di log ricevute il 23 febbraio fino al momento in cui è stata eseguita la query.La query recupera i risultati per una singola istanza Compute Engine,
1554300700000000000
.
SELECT timestamp AS Time, logName as Log, textPayload AS Message FROM (TABLE_DATE_RANGE(my_bq_dataset.syslog_, DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())), (TABLE_DATE_RANGE(my_bq_dataset.apache_access_, DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())) WHERE resource.type == 'gce_instance' AND resource.labels.instance_id == '1554300700000000000' ORDER BY time;
Ecco alcuni esempi di righe di output:
Row | Time | Log | Message --- | ----------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- 5 | 2020-02-21 03:40:14 UTC | projects/project-id/logs/syslog | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269; 6 | 2020-02-21 04:17:01 UTC | projects/project-id/logs/syslog | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 7 | 2020-02-21 04:49:58 UTC | projects/project-id/logs/apache-access | 128.61.240.66 - - [21/Feb/2020:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)" 8 | 2020-02-21 05:17:01 UTC | projects/project-id/logs/syslog | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 9 | 2020-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2020:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"
Query di esempio su App Engine
La seguente query BigQuery recupera le informazioni non riuscite Richieste App Engine dell'ultimo mese:
SELECT timestamp AS Time, protoPayload.host AS Host, protoPayload.status AS Status, protoPayload.resource AS Path FROM (TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_, DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP())) WHERE protoPayload.status != 200 ORDER BY time
Ecco alcuni risultati:
Row | Time | Host | Status | Path --- | ----------------------- | ------------------------------------- | ------ | ------ 6 | 2020-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com | 404 | /foo?thud=3 7 | 2020-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com | 404 | /foo 8 | 2020-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com | 404 | /favicon.ico 9 | 2020-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com | 404 | /foo?thud=%22what???%22
Schema BigQuery per i log con routing
Gli schemi delle tabelle BigQuery per i log con routing si basano su struttura del tipo LogEntry e dei contenuti del log e carichi di lavoro superflui. Cloud Logging applica anche regole per ridurre Nomi dei campi dello schema BigQuery per audit log e per alcuni campi payload strutturati. Puoi visualizzare lo schema della tabella selezionando una tabella con log indirizzato nel Interfaccia di BigQuery.
Convenzioni di denominazione dei campi
Esistono alcune convenzioni di denominazione che si applicano ai campi voce di log quando Invio dei log a BigQuery:
I nomi dei campi di voce di log non possono superare i 128 caratteri.
I nomi dei campi delle voci di log possono essere composti solo da caratteri alfanumerici. Qualsiasi I caratteri non supportati vengono rimossi dai nomi dei campi e sostituiti con il trattino basso. Ad esempio,
jsonPayload.foo%%
verrà trasformato ajsonPayload.foo__
.I nomi dei campi di voce di log devono iniziare con un carattere alfanumerico, anche dopo transformation; vengono rimossi tutti i trattini bassi.
Per i campi voce di log che fanno parte del tipo LogEntry, la riga i nomi dei campi BigQuery corrispondenti sono esattamente gli stessi nei campi voce di log.
Per tutti i campi voce di log forniti dall'utente, il valore I nomi dei campi BigQuery sono normalizzati in minuscolo, ma viene mantenuta in altro modo.
Per i campi nei payload strutturati, purché l'indicatore
@type
non sia i nomi dei campi BigQuery corrispondenti sono normalizzati alle lettere minuscole, ma in caso contrario la denominazione viene mantenuta.Per informazioni sui payload strutturati in cui l'indicatore
@type
è vedi Campi di payload con@type
in questa pagina.
I seguenti esempi mostrano come vengono applicate queste convenzioni di denominazione:
Campo di immissione del log | Mappatura del tipo LogEntry | Nome campo BigQuery |
---|---|---|
insertId |
insertId |
insertId |
textPayload |
textPayload |
textPayload |
httpRequest.status |
httpRequest.status |
httpRequest.status |
httpRequest.requestMethod.GET |
httpRequest.requestMethod.[ABC] |
httpRequest.requestMethod.get |
resource.labels.moduleid |
resource.labels.[ABC] |
resource.labels.moduleid |
jsonPayload.MESSAGE |
jsonPayload.[ABC] |
jsonPayload.message |
jsonPayload.myField.mySubfield |
jsonPayload.[ABC].[XYZ] |
jsonPayload.myfield.mysubfield |
Campi payload con @type
Questa sezione illustra i nomi dei campi dello schema BigQuery per i log
voci i cui payload contengono l'indicatore @type
. È incluso l'audit log
indirizzate a BigQuery.
I payload nelle voci di log possono contenere dati strutturati. Qualsiasi campo strutturato può includi un indicatore di tipo facoltativo nel formato seguente:
@type: type.googleapis.com/[TYPE]
Le regole di denominazione spiegano perché il campo protoPayload
di una voce di audit voce di log potrebbe essere
mappato al campo dello schema BigQuery protopayload_auditlog
.
Regole di denominazione per @type
I campi strutturati con specificatori di tipo vengono abitualmente forniti
Nomi dei campi BigQuery con [TYPE]
aggiunto al campo
. Il valore di [TYPE]
può essere qualsiasi stringa.
Le regole di denominazione per @type
si applicano solo al primo livello di jsonPayload
oppure
protoPayload
; vengono ignorati. Nel caso dei contenuti strutturati di primo livello,
nei campi del payload, Logging rimuove il prefisso type.googleapis.com
.
Ad esempio, la tabella seguente mostra la mappatura della struttura di primo livello dei campi payload ai nomi dei campi BigQuery:
Payload | Payload @type | Campo Payload | Nome campo BigQuery |
---|---|---|---|
jsonPayload |
(nessuno) | statusCode |
jsonPayload.statusCode |
jsonPayload |
type.googleapis.com/abc.Xyz |
statusCode |
jsonpayload_abc_xyz.statuscode |
protoPayload |
(nessuno) | statusCode |
protoPayload.statuscode |
protoPayload |
type.googleapis.com/abc.Xyz |
statusCode |
protopayload_abc_xyz.statuscode |
Alcune eccezioni si applicano alle regole precedenti per i campi con specificatori di tipo:
Nei log delle richieste di App Engine, il nome del payload nei log instradati a BigQuery è
protoPayload
, anche se il payload include o un specificatore di tipo.Cloud Logging applica alcune regole speciali per Nomi dei campi dello schema BigQuery per gli audit log. Questo argomento verrà discusso nella sezione Campi degli audit log di questa pagina.
Esempio
Questo esempio mostra come vengono denominati e utilizzati i campi del payload strutturati quando ricevute da BigQuery.
Supponiamo che il payload di una voce di log sia strutturato come segue:
jsonPayload: {
@type: "type.googleapis.com/google.cloud.v1.CustomType"
name_a: {
sub_a: "A value"
}
name_b: {
sub_b: 22
}
}
La mappatura ai campi di BigQuery è la seguente:
Il campo strutturato di primo livello
jsonPayload
contiene un indicatore@type
. Il suo nome BigQuery èjsonpayload_v1_customtype
.I campi nidificati vengono trattati con Regole di denominazione BigQuery, come specificatore del tipo non si applicano ai campi nidificati.
Pertanto, i seguenti nomi BigQuery sono definiti per il log payload della voce:
jsonpayload_v1_customtype
jsonpayload_v1_customtype._type
jsonpayload_v1_customtype.name_b
jsonpayload_v1_customtype.name_b.sub_b
jsonpayload_v1_customtype.name_a
jsonpayload_v1_customtype.name_a.sub_a
Campi degli audit log
Se non stai utilizzando gli audit log indirizzati a BigQuery, puoi saltare questa sezione.
I campi del payload dell'audit log protoPayload.request
, protoPayload.response
,
e protoPayload.metadata
hanno specificato @type
ma vengono trattati come
Dati JSON. Vale a dire, i nomi degli schemi BigQuery sono il loro campo
con l'aggiunta di Json
e contengono dati stringa in formato JSON.
I due set di nomi dei campi del payload degli audit log sono elencati di seguito tabella:
Campo di immissione del log | Nome campo BigQuery |
---|---|
protoPayload |
protopayload_auditlog |
protopayload.metadata |
protopayload_auditlog.metadataJson |
protoPayload.serviceData |
protopayload_auditlog.servicedata_v1_bigquery Esempio: protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest |
protoPayload.request |
protopayload_auditlog.requestJson |
protoPayload.response |
protopayload_auditlog.responseJson |
Tieni presente che la convenzione di denominazione serviceData
è specifica per gli audit log che sono
generati da BigQuery e indirizzati quindi
da Cloud Logging a BigQuery. Queste voci di audit log contengono un
Campo serviceData
con un specificatore @type di
type.googleapis.com/google.cloud.bigquery.logging.v1.auditdata
.
Esempio
Una voce dell'audit log generata da BigQuery ha un campo con seguente nome:
protoPayload.serviceData.tableInsertRequest
Se questa voce di log fosse stata instradata a BigQuery, in che modo
Fare riferimento a tableInsertRequest
campo? Prima dell'abbreviazione del nome,
il nome del campo corrispondente in BigQuery sarebbe:
protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest
Dopo l'abbreviazione del nome, viene fatto riferimento allo stesso campo Tabelle BigQuery come questa:
protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest
Organizzazione della tabella
Questa sezione fornisce una panoramica tabelle partizionate per i log con routing in BigQuery.
Quando esegui il routing dei log su un set di dati BigQuery, Logging crea tabelle per contenere le voci di log. La prima voce di log ricevuta BigQuery determina lo schema per la tabella BigQuery di destinazione. BigQuery crea una tabella le cui colonne si basano sui campi della prima voce di log e i relativi tipi. Le voci di log successive potrebbero causare una mancata corrispondenza dello schema. Per su quando si verificano e come vengono gestiti, consulta Mancate corrispondenze nello schema.
Esistono due tipi di tabella per cui
Logging organizza i dati che instrada: tabelle con suddivisione in date e
tabelle partizionate. Entrambi i tipi di tabella suddividono i dati dei log in base ai log
voci timestamp
campi. Tuttavia, ci sono due differenze fondamentali tra
tipi di tabella come segue:
Prestazioni: una tabella partizionata suddivide una tabella grande in una tabella più piccola partizioni di memoria, in modo da poter migliorare le prestazioni delle query e, di conseguenza, controlla i costi di BigQuery riducendo il numero di byte letto da una query.
Nomenclatura delle tabelle: i tipi di tabella utilizzano convenzioni di denominazione diverse, come di cui parleremo nella sezione di seguito.
Organizzazione della tabella
Le voci di log vengono suddivise con sharding in tabelle BigQuery dell'organizzazione e i nomi si basano sulle voci nomi di log e timestamp.
I nomi delle tabelle hanno come suffisso la data di calendario del fuso orario UTC della voce di log timestamp, utilizzando il formato di base ISO 8601 (AAAAMMGG).
La tabella seguente mostra esempi di come vengono visualizzati nomi di log e timestamp di esempio mappate ai nomi delle tabelle in BigQuery:
Nome log | Voce di log timestamp 1 |
Nome tabella BigQuery (con suddivisione in date) |
Nome tabella BigQuery (partizionata) |
---|---|---|---|
syslog |
2017-05-23T18:19:22.135Z |
syslog_20170523 |
syslog |
apache-access |
2017-01-01T00:00:00.000Z |
apache_access_20170101 |
apache_access |
compute.googleapis.com/activity_log |
2017-12-31T23:59:59.999Z |
compute_googleapis_com_activity_log_20171231 |
compute_googleapis_com_activity_log |
1 I timestamp delle voci di log sono espressi nel fuso orario UTC (Coordinated tempo universale).
Creazione delle tabelle partizionate
Quando crei un sink per instradare i log a BigQuery, puoi: o utilizzare tabelle partizionate o con frazioni di date. La selezione predefinita è una tabella con data:
Per istruzioni su come creare i sink, consulta le risorse seguenti:
Console Google Cloud: Esegui il routing dei log alle destinazioni supportate.
Google Cloud CLI:
gcloud logging sinks create
Mancate corrispondenze nello schema
La prima voce di log ricevuta da BigQuery determina lo schema per la tabella BigQuery di destinazione. BigQuery crea una tabella le cui colonne si basano sui campi della prima voce di log e i relativi tipi.
Si verifica una mancata corrispondenza dello schema quando le voci di log vengono scritte nella destinazione tabella e si verifica uno dei seguenti errori:
Una voce di log successiva modifica il tipo di campo di un campo esistente nella tabella.
Ad esempio, se il campo
jsonPayload.user_id
della voce di log iniziale è unstring
, la voce di log genera una tabella con un tipo di stringa corrispondente . Se in seguito inizi a registrarejsonPayload.user_id
comearray
, questo causa una mancata corrispondenza dello schema.Una nuova voce di log contiene un campo che non fa parte dello schema attuale Inserendo quel campo nella tabella di destinazione supererebbe Limite di colonne BigQuery:
La tabella di destinazione può accettare il nuovo campo se questo non genera la visualizzazione della colonna limite da superare.
Quando BigQuery identifica una mancata corrispondenza dello schema, crea una tabella
all'interno del set di dati corrispondente
per archiviare le informazioni sull'errore. La
determina il nome della tabella. Per le tabelle con frazioni di date, il formato di denominazione è
export_errors_YYYYMMDD
. Per le tabelle partizionate, il formato di denominazione è
export_errors
. Per ulteriori informazioni, vedi Organizzazione della tabella.
Quando esegui il routing delle voci di log, Logging invia i messaggi in batch in BigQuery. BigQuery utilizza le seguenti regole per determinare in quale tabella le voci di log nel batch corrente vengono scritti:
Quando si verifica una modifica del tipo di campo, solo le voci di log corrispondenti che hanno causato una mancata corrispondenza dello schema vengono scritte nella tabella degli errori. Registra le voci del batch corrente di messaggi che non vengono scritte una mancata corrispondenza dello schema nella tabella di destinazione originale.
Quando viene superato il limite di colonne, tutte le voci di log nel batch corrente di messaggi vengono scritte in nella tabella degli errori.
Schema della tabella degli errori
La tabella degli errori contiene i dati di LogEntry
e le informazioni
relative alla mancata corrispondenza:
logEntry
: contiene la voce di log completa. ma la voce di log convertito da JSON in una stringa.schemaErrorDetail
: contiene il messaggio di errore completo restituito da in BigQuery.sink
: contiene il percorso completo della risorsa per il sink di log.logName
: estratto dalla tabellaLogEntry
.timestamp
: estratto dalla tabellaLogEntry
.receiveTimestamp
: estratto dalla tabellaLogEntry
.severity
: estratto dalla tabellaLogEntry
.insertId
: estratto dalla tabellaLogEntry
.trace
: estratto dalla tabellaLogEntry
.resourceType
: estratto dalla tabellaLogEntry
.
Logging comunica le mancate corrispondenze dello schema progetto Google Cloud che contiene il sink di routing nei seguenti modi:
- I proprietari del progetto ricevono un'email. Dettagli includi l'ID progetto Google Cloud, il nome del sink e la destinazione.
- Nella pagina Attività della console Google Cloud viene visualizzato l'errore
Stackdriver Config error
. I dettagli includono il nome e la destinazione del sink e un link a un esempio di voce di log che ha causato l'errore.
Previeni le future mancate corrispondenze dei tipi di campo
Per correggere le mancate corrispondenze dei tipi di campo per le voci di log successive, correggi il campo in modo che corrisponda allo schema attuale. Per informazioni su come correggere un tipo di campo, consulta Modificare il tipo di dati di una colonna.
A volte il tipo di campo non può essere modificato, ad esempio, non puoi modificare tipo di campo per i log generati automaticamente da Google Cloud i servizi di machine learning. Per evitare errori di corrispondenza dello schema quando non puoi modificare un tipo di campo, rinomina la tabella o modifica i parametri del sink, Logging ricrea la tabella in un set di dati diverso. Per istruzioni, vedi Gestisci i sink.
Risoluzione dei problemi
Se i log sembrano non essere presenti nella destinazione del sink o sospetti in altro modo se il sink non esegue correttamente il routing dei log, Risolvi i problemi relativi ai log di routing.
Prezzi
Cloud Logging non addebita alcun costo per il routing dei log a un
destinazione supportata; ma la destinazione potrebbe applicare dei costi.
Ad eccezione del bucket di log _Required
,
Cloud Logging addebita un costo per trasferire i log nei bucket di log.
per un'archiviazione più lunga del periodo di conservazione predefinito del bucket di log.
Cloud Logging non addebita alcun costo per la copia dei log, per la definizione degli ambiti di log, o per le query inviate tramite Pagine Esplora log o Analisi dei log.
Per ulteriori informazioni, consulta i seguenti documenti:
- Riepilogo dei prezzi di Cloud Logging
Costi di destinazione:
- Costi per la generazione di log di flusso VPC si applicano quando invii e poi escludi i log di flusso Virtual Private Cloud da Cloud Logging.