Melihat log yang dirutekan ke BigQuery

Dokumen ini menjelaskan cara menemukan entri log yang Anda arahkan dari Cloud Logging ke tabel BigQuery. Sink logging mengalirkan data logging ke BigQuery dalam batch kecil, yang memungkinkan Anda 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.

Cloud Logging menggunakan legacy streaming API untuk melakukan streaming entri log ke BigQuery. Biasanya, entri log terlihat di BigQuery dalam satu menit. Namun, saat tabel baru dibuat, mungkin perlu waktu beberapa menit sebelum entri log pertama tersedia.

Catatan: Meskipun Anda dapat melakukan streaming entri log ke BigQuery, sebaiknya simpan entri log di bucket log, upgrade bucket untuk menggunakan Log Analytics, lalu buat set data tertaut. Anda dapat menggunakan BigQuery untuk membuat kueri set data tertaut.

Sebelum memulai

Untuk diskusi konseptual tentang sink, lihat Ringkasan model perutean dan penyimpanan: Sink.

Untuk mendapatkan petunjuk tentang cara merutekan log, lihat Merutekan log ke tujuan yang didukung.

Untuk mempelajari cara penamaan kolom entri log yang dirutekan, lihat Skema BigQuery untuk log yang dirutekan.

Lihat log

Untuk melihat log yang dirutekan ke BigQuery, lakukan hal berikut:

1. Di konsol Google Cloud, buka halaman BigQuery:

   Buka BigQuery Studio

   Anda juga dapat menemukan halaman ini menggunakan kotak penelusuran.

2. Di panel Explorer, luaskan project Anda dan pilih set data.

   Entri log terlihat di tab Details, atau Anda dapat membuat kueri tabel untuk menampilkan data.

Sampel kueri

Untuk informasi tentang sintaksis kueri BigQuery, lihat Referensi kueri. Yang sangat berguna adalah fungsi karakter pengganti tabel, yang memungkinkan Anda membuat kueri di beberapa tabel, dan operator meratakan, yang memungkinkan Anda menampilkan data dari kolom berulang.

Contoh kueri Compute Engine

Kueri BigQuery berikut mengambil entri log dari beberapa hari dan beberapa jenis log:

• Kueri menelusuri tiga hari terakhir dari log syslog dan apache-access. Kueri dibuat pada 23-Feb-2020 dan mencakup semua entri log yang diterima pada 21-Feb dan 22-Feb, serta entri log yang diterima pada 23-Feb hingga saat kueri dikeluarkan.

• Kueri 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 tidak berhasil 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 yang berisi entri log yang dirutekan di antarmuka BigQuery.

Catatan: Skema tabel BigQuery yang digunakan untuk merepresentasikan payload entri log yang kompleks dapat membingungkan dan, dalam kasus log audit yang dirutekan, beberapa aturan penamaan khusus digunakan. Untuk informasi selengkapnya, lihat bagian Kolom log audit di halaman ini.

Konvensi penamaan kolom

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 boleh terdiri dari karakter alfanumerik. Semua karakter yang tidak didukung akan dihapus dari nama kolom dan diganti dengan karakter garis bawah. Misalnya, jsonPayload.foo%% akan diubah menjadi jsonPayload.foo__.

  Nama kolom entri log harus diawali dengan karakter alfanumerik, bahkan setelah transformasi; 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 dinormalisasi ke huruf kecil, tetapi penamaannya akan dipertahankan.

• Untuk kolom dalam payload terstruktur, selama penentu @type tidak ada, nama kolom BigQuery yang sesuai akan dinormalisasi ke huruf kecil, tetapi penamaan akan dipertahankan.

  Untuk informasi tentang payload terstruktur yang berisi penentu @type, lihat Kolom payload dengan @type di halaman ini.

Contoh berikut menunjukkan cara penerapan konvensi penamaan ini:

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 @type penentu. 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 mengapa kolom protoPayload entri log audit mungkin dipetakan ke kolom skema BigQuery protopayload_auditlog.

Aturan penamaan untuk @type

Kolom terstruktur yang memiliki penentu jenis biasanya diberi nama kolom BigQuery yang memiliki [TYPE] yang ditambahkan ke nama kolomnya. Nilai [TYPE] dapat berupa string apa pun.

Aturan penamaan untuk @type hanya berlaku untuk tingkat teratas jsonPayload atau protoPayload; kolom bertingkat diabaikan. Saat menangani kolom payload terstruktur tingkat teratas, Logging akan menghapus awalan type.googleapis.com.

Misalnya, tabel berikut menunjukkan pemetaan kolom payload terstruktur level teratas ke 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:

• Dalam log permintaan App Engine, nama payload dalam log yang dirutekan ke BigQuery adalah protoPayload, meskipun payload menyertakan penentu jenis.

• Cloud Logging menerapkan beberapa aturan khusus untuk mempersingkat nama kolom skema BigQuery untuk log audit. Hal ini dibahas di bagian Bidang log audit di halaman ini.

Contoh

Contoh ini menunjukkan cara kolom payload terstruktur diberi nama dan digunakan saat diterima oleh BigQuery.

Anggaplah payload entri log disusun 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 adalah jsonpayload_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 tidak menggunakan log audit yang telah dirutekan ke BigQuery, Anda dapat melewati bagian ini.

Kolom payload log audit protoPayload.request, protoPayload.response, dan protoPayload.metadata memiliki pengidentifikasi @type, tetapi diperlakukan sebagai data JSON. Artinya, nama skema BigQuery-nya adalah nama kolomnya dengan Json ditambahkan, dan berisi data string dalam format JSON.

Dua 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 khusus untuk log audit yang dihasilkan oleh BigQuery, lalu dirutekan dari Cloud Logging ke BigQuery. Entri log audit tersebut berisi kolom serviceData yang memiliki penentu @type type.googleapis.com/google.cloud.bigquery.logging.v1.auditdata.

Contoh

Entri log audit yang dihasilkan oleh BigQuery memiliki kolom dengan nama berikut:

protoPayload.serviceData.tableInsertRequest

Jika entri log ini kemudian dirutekan ke BigQuery, bagaimana kolom tableInsertRequest akan direferensikan? Sebelum nama dipersingkat, nama kolom yang sesuai di BigQuery akan menjadi:

protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest

Setelah nama dipersingkat, kolom yang sama akan dirujuk di tabel BigQuery seperti ini:

protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest

Pengaturan tabel

Bagian ini memberikan ringkasan tentang tabel berpartisi 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 menanganinya, lihat Ketidakcocokan dalam skema.

Ada dua jenis tabel yang digunakan logging untuk mengatur data yang dirutekannya: tabel yang di-shard tanggal dan tabel yang dipartisi. Kedua jenis tabel mempartisi data log berdasarkan kolom timestamp entri log. Namun, ada dua perbedaan utama antara jenis tabel sebagai berikut:

• Performa: Tabel berpartisi membagi tabel besar menjadi partisi yang lebih kecil, sehingga Anda dapat meningkatkan performa kueri dan, dengan demikian, mengontrol biaya BigQuery dengan 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.

Pengaturan tabel

Entri log di-shard ke dalam tabel BigQuery yang pengaturannya dan namanya didasarkan pada nama log dan stempel waktu entri.

Nama tabel diakhiri dengan tanggal kalender stempel waktu UTC entri log, menggunakan format dasar ISO 8601 (YYYYMMDD).

Tabel berikut menunjukkan contoh cara nama log dan stempel waktu contoh dipetakan ke nama tabel di BigQuery:

Nama log	Entri log timestamp^1	Nama tabel BigQuery (dengan sharding 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

¹ Stempel waktu entri log dinyatakan dalam UTC (Coordinated Universal Time).

Membuat tabel berpartisi

Saat membuat sink untuk merutekan log ke BigQuery, Anda dapat menggunakan tabel yang di-shard tanggal atau tabel berpartisi. Pilihan defaultnya adalah tabel yang di-shard berdasarkan 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 mengubah jenis kolom untuk kolom yang ada dalam tabel.

  Misalnya, jika kolom jsonPayload.user_id entri log awal adalah string, entri log tersebut akan menghasilkan tabel dengan jenis string untuk kolom tersebut. Jika nanti Anda mulai mencatat jsonPayload.user_id sebagai array, hal itu akan menyebabkan ketidakcocokan skema.

• Entri log baru berisi kolom yang tidak ada dalam skema saat ini dan memasukkan kolom tersebut ke dalam tabel tujuan akan melebihi batas kolom BigQuery.

  Tabel tujuan dapat menerima kolom baru jika tidak menyebabkan batas kolom dilampaui.

Saat mengidentifikasi ketidakcocokan skema, BigQuery akan membuat tabel dalam set data yang sesuai untuk menyimpan informasi error. Jenis tabel menentukan nama tabel. Untuk tabel yang di-shard berdasarkan tanggal, format penamaannya adalah export_errors_YYYYMMDD. Untuk tabel yang dipartisi, format penamaannya adalah export_errors. Untuk mengetahui informasi selengkapnya, lihat Organisasi tabel.

Saat merutekan entri log, Logging mengirimkan pesan sebagai batch ke BigQuery. BigQuery menggunakan aturan berikut untuk menentukan tabel tempat entri log dalam batch pesan saat ini ditulis:

• Saat perubahan jenis kolom terjadi, hanya entri log yang menyebabkan ketidakcocokan skema yang ditulis ke tabel error. Entri log dalam batch pesan saat ini yang tidak menyebabkan ketidakcocokan skema ditulis ke tabel tujuan asli.

• Jika batas kolom terlampaui, semua entri log dalam batch pesan saat ini akan ditulis ke tabel error.

  Catatan: BigQuery mendukung pemuatan data bertingkat ke dalam tabelnya. Namun, saat memuat data dari Logging, batas kedalaman bertingkat maksimum untuk kolom adalah 13 level.

Skema tabel error

Tabel error berisi data dari LogEntry dan informasi tentang ketidakcocokan:

• logEntry: Berisi entri log lengkap; namun, 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 dari LogEntry.
• timestamp: Diekstrak dari LogEntry.
• receiveTimestamp: Diekstrak dari LogEntry.
• severity: Diekstrak dari LogEntry.
• insertId: Diekstrak dari LogEntry.
• trace: Diekstrak dari LogEntry.
• resourceType: Diekstrak dari LogEntry.

Logging menyampaikan ketidakcocokan skema ke project Google Cloud yang berisi sink perutean dengan cara berikut:

• Pemilik Project akan menerima email. Detailnya meliputi: ID project Google Cloud, nama sink, dan tujuan.
• Halaman Aktivitas konsol Google Cloud menampilkan error, Stackdriver Config error. Detail mencakup nama dan tujuan sink, serta link ke contoh entri log yang menyebabkan error.

Mencegah ketidakcocokan jenis kolom di masa mendatang

Untuk memperbaiki ketidakcocokan jenis kolom untuk entri log berikutnya, perbaiki jenis kolom 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 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 mengenakan biaya. Dengan pengecualian bucket log _Required, Cloud Logging mengenakan biaya untuk melakukan streaming log ke bucket log dan untuk penyimpanan yang lebih lama dari periode retensi data default bucket log.

Cloud Logging tidak mengenakan biaya untuk menyalin log, menentukan cakupan log, atau untuk kueri yang dikeluarkan melalui halaman Logs Explorer atau Log Analytics.

Untuk informasi selengkapnya, baca dokumen berikut:

• Ringkasan harga Cloud Logging

• Biaya tujuan:

  • Harga Cloud Storage
  • Harga BigQuery
  • Harga Pub/Sub
  • Harga Cloud Logging
• Biaya pembuatan log alur VPC berlaku saat Anda mengirim, lalu mengecualikan log alur Virtual Private Cloud dari Cloud Logging.