Dokumen ini menjelaskan cara menemukan entri log yang dirutekan dari Cloud Logging ke tabel BigQuery. Logging sink men-streaming data logging streaming ke BigQuery dalam beberapa batch kecil, sehingga Anda dapat membuat kueri data tanpa menjalankan tugas pemuatan. Untuk membantu Anda membuat kueri dan memahami format tabel BigQuery, dokumen ini juga menjelaskan skema BigQuery untuk log yang dirutekan.
Biasanya, entri log terlihat di BigQuery dalam waktu satu menit. Namun, saat tabel baru dibuat, mungkin perlu waktu beberapa menit sebelum entri log pertama tersedia.
Sebelum memulai
Untuk diskusi konseptual tentang sink, lihat Ringkasan model pemilihan rute dan penyimpanan: Sink.
Untuk mendapatkan petunjuk tentang cara merutekan log Anda, lihat Merutekan log ke tujuan yang didukung.
Untuk mempelajari cara menamai kolom entri log yang dirutekan, lihat skema BigQuery untuk log yang dirutekan.
Lihat log
Untuk melihat log yang dirutekan ke BigQuery, lakukan langkah berikut:
-
Di panel navigasi konsol Google Cloud, pilih BigQuery:
Di panel Explorer, luaskan project Anda dan pilih set data.
Entri log terlihat di tab Details atau Anda dapat membuat kueri di tabel untuk menampilkan data.
Sampel kueri
Untuk mengetahui informasi tentang sintaksis kueri BigQuery, lihat Referensi kueri. Fungsi karakter pengganti tabel sangat berguna, yang memungkinkan Anda membuat kueri di beberapa tabel, serta operator perataan untuk menampilkan data dari kolom berulang.
Contoh kueri Compute Engine
Kueri BigQuery berikut mengambil entri log dari beberapa hari dan berbagai jenis log:
Kueri menelusuri log
syslog
danapache-access
selama tiga hari terakhir. Kueri dibuat pada 23 Feb 2020 dan mencakup semua entri log yang diterima pada 21 Feb dan 22 Feb, ditambah entri log yang diterima pada 23 Feb hingga saat kueri dikeluarkan.Kueri tersebut mengambil hasil untuk satu instance 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;
Berikut adalah beberapa contoh baris 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 "-" "-"
Contoh kueri App Engine
Kueri BigQuery berikut mengambil permintaan App Engine yang gagal dari bulan lalu:
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
Berikut beberapa hasilnya:
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
Skema BigQuery untuk log yang dirutekan
Skema tabel BigQuery untuk log yang dirutekan didasarkan pada struktur jenis LogEntry dan konten payload log. Cloud Logging juga menerapkan aturan untuk mempersingkat nama kolom skema BigQuery untuk log audit dan untuk kolom payload terstruktur tertentu. Anda dapat melihat skema tabel dengan memilih tabel berisi entri log yang dirutekan di antarmuka BigQuery.
Konvensi penamaan bidang
Ada beberapa konvensi penamaan yang berlaku untuk kolom entri log saat mengirim log ke BigQuery:
Nama kolom entri log tidak boleh melebihi 128 karakter.
Nama kolom entri log hanya dapat terdiri dari karakter alfanumerik. Setiap karakter yang tidak didukung akan dihapus dari nama kolom dan diganti dengan karakter garis bawah. Misalnya,
jsonPayload.foo%%
akan diubah menjadijsonPayload.foo__
.Nama kolom entri log harus diawali dengan karakter alfanumerik, bahkan setelah transformasi; semua garis bawah di awal akan dihapus.
Untuk kolom entri log yang merupakan bagian dari jenis LogEntry, nama kolom BigQuery yang sesuai sama persis dengan kolom entri log.
Untuk kolom entri log yang disediakan pengguna, nama kolom BigQuery yang sesuai akan dinormalkan ke huruf kecil, tetapi penamaan akan dipertahankan.
Untuk kolom dalam payload terstruktur, selama penentu
@type
tidak ada, nama kolom BigQuery yang sesuai akan dinormalkan menjadi huruf kecil, tetapi penamaan akan dipertahankan.Untuk mengetahui informasi tentang payload terstruktur tempat penentu
@type
ada, lihat Kolom payload dengan@type
di halaman ini.
Contoh berikut menunjukkan bagaimana konvensi penamaan ini diterapkan:
Kolom entri log | Pemetaan jenis LogEntry | Nama kolom 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 |
Kolom payload dengan @type
Bagian ini membahas nama kolom skema BigQuery khusus untuk entri log yang payload-nya berisi penentu @type
. Hal ini mencakup entri log audit
yang dirutekan ke BigQuery.
Payload dalam entri log dapat berisi data terstruktur. Setiap kolom terstruktur dapat menyertakan penentu jenis opsional dalam format berikut:
@type: type.googleapis.com/[TYPE]
Aturan penamaan menjelaskan alasan kolom protoPayload
entri log audit mungkin dipetakan ke kolom skema BigQuery protopayload_auditlog
.
Menamai aturan untuk @type
Kolom terstruktur yang memiliki penentu jenis biasanya diberi nama kolom BigQuery dengan [TYPE]
yang ditambahkan ke nama kolomnya. Nilai [TYPE]
dapat berupa string apa pun.
Aturan penamaan untuk @type
hanya berlaku untuk jsonPayload
atau
protoPayload
tingkat teratas; kolom bertingkat akan diabaikan. Saat memperlakukan kolom payload terstruktur
level atas, Logging menghapus awalan type.googleapis.com
.
Misalnya, tabel berikut menunjukkan pemetaan kolom payload terstruktur level teratas terhadap nama kolom BigQuery:
Payload | @type payload | Kolom Payload | Nama kolom BigQuery |
---|---|---|---|
jsonPayload |
(tidak ada) | statusCode |
jsonPayload.statusCode |
jsonPayload |
type.googleapis.com/abc.Xyz |
statusCode |
jsonpayload_abc_xyz.statuscode |
protoPayload |
(tidak ada) | statusCode |
protoPayload.statuscode |
protoPayload |
type.googleapis.com/abc.Xyz |
statusCode |
protopayload_abc_xyz.statuscode |
Beberapa pengecualian berlaku untuk aturan sebelumnya untuk kolom dengan penentu jenis:
Di log permintaan App Engine, nama payload di log yang dirutekan ke BigQuery adalah
protoPayload
, meskipun payload menyertakan penentu jenis.Cloud Logging menerapkan beberapa aturan khusus guna mempersingkat nama kolom skema BigQuery untuk log audit. Hal ini dibahas di bagian Kolom log audit pada halaman ini.
Contoh
Contoh ini menunjukkan cara penamaan kolom payload terstruktur dan digunakan saat diterima oleh BigQuery.
Asumsikan bahwa payload entri log memiliki struktur seperti berikut:
jsonPayload: {
@type: "type.googleapis.com/google.cloud.v1.CustomType"
name_a: {
sub_a: "A value"
}
name_b: {
sub_b: 22
}
}
Pemetaan ke kolom BigQuery adalah sebagai berikut:
Kolom terstruktur tingkat atas
jsonPayload
berisi penentu@type
. Nama BigQuery-nya adalahjsonpayload_v1_customtype
.Kolom bertingkat diperlakukan dengan aturan penamaan BigQuery standar, karena aturan penentu jenis tidak berlaku untuk kolom bertingkat.
Dengan demikian, nama BigQuery berikut ditentukan untuk payload entri log:
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
Kolom log audit
Jika Anda tidak menangani log audit yang telah dirutekan ke BigQuery, Anda dapat melewati bagian ini.
Kolom payload log audit protoPayload.request
, protoPayload.response
, dan protoPayload.metadata
memiliki penentu @type
, tetapi diperlakukan sebagai data JSON. Artinya, nama skema BigQuery adalah nama kolomnya dengan tambahan Json
, dan berisi data string dalam format JSON.
Kedua kumpulan nama kolom payload log audit tercantum dalam tabel berikut:
Kolom entri log | Nama kolom BigQuery |
---|---|
protoPayload |
protopayload_auditlog |
protopayload.metadata |
protopayload_auditlog.metadataJson |
protoPayload.serviceData |
protopayload_auditlog.servicedata_v1_bigquery Contoh: protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest |
protoPayload.request |
protopayload_auditlog.requestJson |
protoPayload.response |
protopayload_auditlog.responseJson |
Perhatikan bahwa konvensi penamaan serviceData
ini khusus untuk log audit yang dihasilkan oleh BigQuery, yang kemudian dirutekan dari Cloud Logging ke BigQuery. Entri log audit tersebut berisi
kolom serviceData
yang memiliki @type penentu
type.googleapis.com/google.cloud.bigquery.logging.v1.auditdata
.
Contoh
Entri log audit yang dibuat oleh BigQuery memiliki kolom dengan nama berikut:
protoPayload.serviceData.tableInsertRequest
Jika entri log ini kemudian dirutekan ke BigQuery, bagaimana kolom tableInsertRequest
akan direferensikan? Sebelum penyingkatan nama, nama kolom yang sesuai di BigQuery adalah:
protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest
Setelah penyingkatan nama, kolom yang sama dirujuk di tabel BigQuery seperti ini:
protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest
Pengaturan tabel
Bagian ini memberikan ringkasan tabel yang dipartisi untuk log yang dirutekan ke BigQuery.
Saat Anda mengarahkan log ke set data BigQuery, Logging akan membuat tabel untuk menyimpan entri log. Entri log pertama yang diterima oleh BigQuery menentukan skema untuk tabel BigQuery tujuan. BigQuery membuat tabel yang kolomnya didasarkan pada kolom entri log pertama dan jenisnya. Entri log berikutnya dapat menyebabkan ketidakcocokan skema. Untuk mengetahui informasi tentang kapan hal ini terjadi dan cara penanganannya, lihat Ketidakcocokan dalam skema.
Ada dua jenis tabel yang digunakan
Logging untuk mengatur data yang diarahkan: tabel dengan shard tanggal dan
tabel berpartisi. Kedua jenis tabel mempartisi data log berdasarkan kolom timestamp
entri log. Namun, ada dua perbedaan utama antara
jenis tabel sebagai berikut:
Performa: Tabel yang dipartisi membagi tabel besar menjadi partisi yang lebih kecil, sehingga Anda dapat meningkatkan performa kueri dan, dengan demikian, dapat mengontrol biaya BigQuery secara lebih baik dengan mengurangi jumlah byte yang dibaca oleh kueri.
Nomenklatur tabel: Jenis tabel menggunakan konvensi penamaan yang berbeda, seperti yang dibahas di bagian di bawah ini.
Pengaturan tabel
Entri log di-sharding ke dalam tabel BigQuery yang organisasi dan namanya didasarkan pada nama log dan stempel waktu entri.
Nama tabel diberi akhiran dengan tanggal kalender stempel waktu UTC entri log, menggunakan format dasar ISO 8601 (YYYYMMDD).
Tabel berikut menampilkan contoh cara nama log dan contoh stempel waktu dipetakan ke nama tabel di BigQuery:
Nama log | Entri log timestamp 1 |
Nama tabel BigQuery (di-sharding pada tanggal) |
Nama tabel BigQuery (dipartisi) |
---|---|---|---|
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 Stempel waktu entri log dinyatakan dalam UTC (Waktu Universal Terkoordinasi).
Membuat tabel berpartisi
Saat membuat sink untuk mengarahkan log ke BigQuery, Anda dapat menggunakan tabel dengan sharding tanggal atau tabel berpartisi. Pilihan default-nya adalah tabel shard tanggal:
Untuk mengetahui petunjuk cara membuat sink, lihat referensi berikut:
Konsol Google Cloud: Merutekan log ke tujuan yang didukung.
Google Cloud CLI:
gcloud logging sinks create
.
Ketidakcocokan dalam skema
Entri log pertama yang diterima oleh BigQuery menentukan skema untuk tabel BigQuery tujuan. BigQuery membuat tabel yang kolomnya didasarkan pada kolom entri log pertama dan jenisnya.
Ketidakcocokan skema terjadi saat entri log ditulis ke tabel tujuan dan salah satu error berikut terjadi:
Entri log berikutnya akan mengubah jenis kolom untuk kolom yang ada di tabel.
Misalnya, jika kolom
jsonPayload.user_id
entri log awal adalahstring
, entri log tersebut akan menghasilkan tabel dengan jenis string untuk kolom tersebut. Jika nanti Anda mulai mencatatjsonPayload.user_id
sebagaiarray
ke dalam log, hal tersebut akan menyebabkan ketidakcocokan skema.Entri log baru berisi kolom yang tidak ada dalam skema saat ini dan menyisipkan kolom tersebut ke dalam tabel tujuan akan melampaui batas kolom BigQuery.
Tabel tujuan dapat menerima kolom baru jika tidak menyebabkan batas kolom terlampaui.
Saat mengidentifikasi ketidakcocokan skema, BigQuery akan membuat tabel dalam set data yang sesuai untuk menyimpan informasi error. Jenis tabel menentukan nama tabel. Untuk tabel dengan sharding tanggal, format penamaannya adalah export_errors_YYYYMMDD
. Untuk tabel yang dipartisi, format penamaannya adalah
export_errors
. Untuk mengetahui informasi selengkapnya, lihat Pengaturan tabel.
Saat mengarahkan entri log, Logging akan mengirimkan pesan sebagai batch ke BigQuery. BigQuery menggunakan aturan berikut untuk menentukan tabel mana yang digunakan untuk menulis entri log dalam batch pesan saat ini:
Saat terjadi perubahan jenis kolom, hanya entri log yang menyebabkan ketidakcocokan skema yang akan dituliskan ke tabel error. Entri log dalam batch pesan saat ini yang tidak menyebabkan ketidakcocokan skema akan ditulis ke tabel tujuan asli.
Jika batas kolom terlampaui, semua entri log dalam batch pesan saat ini akan ditulis ke tabel error.
Skema tabel error
Tabel error berisi data dari LogEntry
dan informasi
tentang ketidakcocokan tersebut:
logEntry
: Berisi entri log lengkap; tetapi, entri log dikonversi dari JSON menjadi string.schemaErrorDetail
: Berisi pesan error lengkap yang ditampilkan oleh BigQuery.sink
: Berisi jalur resource lengkap untuk sink log.logName
: Diekstrak dariLogEntry
.timestamp
: Diekstrak dariLogEntry
.receiveTimestamp
: Diekstrak dariLogEntry
.severity
: Diekstrak dariLogEntry
.insertId
: Diekstrak dariLogEntry
.trace
: Diekstrak dariLogEntry
.resourceType
: Diekstrak dariLogEntry
.
Logging mengomunikasikan ketidakcocokan skema ke project Google Cloud yang berisi sink perutean dengan cara berikut:
- Pemilik Project akan menerima email. Detailnya mencakup: ID project, nama sink, dan tujuan Google Cloud.
- Halaman Aktivitas konsol Google Cloud menampilkan error,
Stackdriver Config error
. Detailnya mencakup nama dan tujuan sink, serta link ke contoh entri log yang menyebabkan error.
Mencegah ketidakcocokan jenis kolom di masa mendatang
Guna memperbaiki ketidakcocokan jenis kolom untuk entri log berikutnya, perbaiki jenis kolom tersebut agar cocok dengan skema saat ini. Untuk mengetahui informasi tentang cara memperbaiki jenis kolom, lihat Mengubah jenis data kolom.
Terkadang, jenis kolom tidak dapat diubah. Misalnya, Anda tidak dapat mengubah jenis kolom untuk log yang dibuat secara otomatis oleh layanan Google Cloud. Untuk mencegah ketidakcocokan skema saat Anda tidak dapat mengubah jenis kolom, ganti nama tabel atau ubah parameter sink, sehingga Logging membuat ulang tabel dalam set data yang berbeda. Untuk mengetahui petunjuknya, lihat Mengelola sink.
Pemecahan masalah
Jika log tampaknya tidak ada di tujuan sink atau Anda mencurigai bahwa sink Anda tidak merutekan log dengan benar, lihat Memecahkan masalah log perutean.
Harga
Cloud Logging tidak mengenakan biaya untuk merutekan log ke tujuan yang didukung; tetapi tujuan tersebut mungkin dikenai biaya.
Dengan pengecualian bucket log _Required
, Cloud Logging mengenakan biaya untuk mengalirkan log ke dalam bucket log dan untuk penyimpanan yang lebih lama dari periode retensi default bucket log.
Cloud Logging tidak mengenakan biaya untuk menyalin log, atau untuk kueri yang dikeluarkan melalui halaman Logs Explorer atau melalui halaman Log Analytics.
Untuk informasi selengkapnya, baca dokumen berikut:
- Ringkasan harga Cloud Logging
Biaya tujuan:
- Biaya pembuatan log alur VPC berlaku saat Anda mengirim, lalu mengecualikan log aliran Virtual Private Cloud Anda dari Cloud Logging.