Melihat log yang dirutekan ke BigQuery

Dokumen ini menjelaskan cara menemukan entri log yang Anda teruskan dari Cloud Logging ke tabel BigQuery. Sink log 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 Anda ke BigQuery. Biasanya, entri log dapat dilihat di BigQuery dalam waktu 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 Anda menyimpan entri log di bucket log, mengupgrade bucket untuk menggunakan Log Analytics, lalu membuat set data tertaut. Anda dapat menggunakan BigQuery untuk membuat kueri set data tertaut.

Sebelum memulai

Untuk pembahasan 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.

Melihat log

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

1. Di Google Cloud konsol, buka halaman BigQuery:

   Buka BigQuery Studio

   Anda juga dapat menemukan halaman ini dengan menggunakan kotak penelusuran.

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

   Entri log dapat dilihat di tab Detail, atau Anda dapat membuat kueri tabel untuk menampilkan data Anda.

Sampel kueri

Untuk mengetahui 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 perataan, 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 log syslog dan apache-access dalam tiga hari terakhir. 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 waktu 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 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 isi payload log. Cloud Logging juga menerapkan aturan untuk memperpendek 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 mengetahui 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 dapat terdiri dari karakter alfanumerik. 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; 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 dinormalisasi ke huruf kecil, tetapi penamaan tetap dipertahankan.

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

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

Contoh berikut menunjukkan cara menerapkan 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 penentu @type. Untuk mengetahui informasi tentang aturan penamaan untuk log audit, lihat bagian Kolom log audit di halaman ini.

Payload dalam entri log dapat berisi data terstruktur. Kolom terstruktur apa pun dapat mencakup penentu jenis opsional dalam format berikut:

@type: type.googleapis.com/[TYPE]

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.

Jenis entri log menentukan aturan penamaan untuk kolom dengan penentu @type. Untuk entri log yang bukan log audit, aturan ini hanya berlaku untuk tingkat teratas jsonPayload atau protoPayload; kolom bertingkat diabaikan. Untuk mengetahui informasi tentang aturan penamaan untuk log audit, lihat bagian Kolom log audit di halaman ini.

Saat menangani kolom payload terstruktur tingkat teratas, Logging akan menghapus awalan type.googleapis.com.

Misalnya, tabel berikut menunjukkan pemetaan kolom payload terstruktur tingkat teratas ke nama kolom BigQuery untuk entri log yang bukan log audit:

Payload	Payload @type	Bidang 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 diarahkan ke BigQuery adalah protoPayload, meskipun payload menyertakan penentu jenis.

• Tabel sebelumnya tidak berlaku untuk log audit. Cloud Logging menerapkan beberapa aturan khusus untuk memperpendek nama kolom skema BigQuery untuk log audit. Hal ini dibahas di bagian Kolom log audit di halaman ini.

Contoh

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

Asumsikan bahwa 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 Anda tidak menggunakan log audit yang telah diarahkan ke BigQuery, Anda dapat melewati bagian ini.

Bagian ini berlaku untuk kolom terstruktur yang dapat mencakup penentu jenis opsional dalam format berikut:

@type: type.googleapis.com/[TYPE]

Modifikasi nama kolom

Jika log audit berisi payload dengan penentu @type, Cloud Logging dapat mengubah nilai [TYPE] yang ditambahkan ke penentu sebelum nama kolom BigQuery dibuat. Modifikasi ini menghasilkan nama kolom BigQuery yang lebih pendek.

Logging selalu menghapus awalan type.googleapis.com dari nilai [TYPE]. Tabel berikut menjelaskan kapan Logging memperpendek nama kolom:

Nilai [TYPE] asli	Nilai [TYPE] yang diubah
google.cloud.audit.AuditLog	AuditLog
google.appengine.legacy.AuditData	legacy.appengine
google.appengine.v1alpha.AuditData	v1alpha.appengine
google.appengine.v1beta.AuditData	v1beta.appengine
google.appengine.v1beta4.AuditData	v1beta4.appengine
google.appengine.v1beta5.AuditData	v1beta5.appengine
google.appengine.v1.AuditData	v1.appengine
google.cloud.bigquery.logging.v1.AuditData	v1.bigquery
google.iam.v1.logging.AuditData	v1.iam
google.iam.admin.v1.AuditData	v1.iam.admin
google.type.Money	money
google.appengine.logging.v1.RequestLog

Misalnya, anggaplah entri log audit berisi konten berikut:

{
  logName: "projects/REDACTED/logs/cloudaudit.googleapis.com%2Factivity"
  protoPayload: {
    @type: "type.googleapis.com/google.cloud.audit.AuditLog"
    serviceData: {
      @type: "type.googleapis.com/google.appengine.legacy.AuditData"
      eventData: {
        timezone: "UTC"
      }
    }
  }
}

Nama kolom BigQuery berasal dari entri log yang diubah, seperti berikut:

{
  logName: "projects/REDACTED/logs/cloudaudit.googleapis.com%2Factivity"
  protoPayload: {
    @type: "AuditLog"
    serviceData: {
      @type: "legacy.appengine"
      eventData: {
        timezone: "UTC"
      }
    }
  }
}

Aturan penamaan untuk @type

Dalam log audit, ada beberapa kolom yang dapat memiliki penentu @type:

• protoPayload
• protoPayload.serviceData
• protoPayload.request
• protoPayload.response
• protoPayload.metadata

Kolom request, response, dan metadata diperlakukan sebagai data JSON. Artinya, nama skema BigQuery mereka adalah nama kolom mereka dengan Json ditambahkan ke dalamnya, dan berisi data string dalam format JSON.

Dua set nama kolom payload log audit tercantum dalam tabel berikut:

Kolom entri log	Nama kolom BigQuery
protoPayload	protopayload_auditlog
protopayload.metadata	protopayload_auditlog.metadataJson
protoPayload.request	protopayload_auditlog.requestJson
protoPayload.response	protopayload_auditlog.responseJson
protoPayload.serviceData	protopayload_auditlog.servicedata_v1_bigquery Contoh: protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest
protoPayload.status.code	protoPayload_auditlog.statuscode

Perhatikan bahwa konvensi penamaan serviceData khusus untuk log audit yang dibuat oleh BigQuery dan kemudian 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 dibuat oleh BigQuery memiliki kolom dengan nama berikut:

protoPayload.serviceData.tableInsertRequest

Jika entri log ini kemudian dirutekan ke BigQuery, bagaimana cara merujuk kolom tableInsertRequest? Sebelum nama disingkat, nama kolom yang sesuai di BigQuery adalah:

protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest

Setelah nama dipersingkat, kolom yang sama dirujuk dalam 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 penanganannya, lihat Ketidakcocokan dalam skema.

Ada dua jenis tabel yang digunakan Logging untuk mengatur data yang dirutekannya: tabel yang di-shard menurut 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 berikut.

Pengaturan tabel

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

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

Tabel berikut menunjukkan contoh pemetaan nama log dan stempel waktu sampel 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 menurut tanggal atau tabel berpartisi. Pilihan default adalah tabel yang di-shard menurut tanggal:

Untuk mengetahui petunjuk tentang cara membuat sink, lihat referensi berikut:

• Google Cloud console: 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, maka entri log tersebut akan membuat tabel dengan jenis string untuk kolom tersebut. Jika Anda kemudian mulai mencatat jsonPayload.user_id sebagai array, maka 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 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 yang di-shard menurut tanggal, format penamaannya adalah export_errors_YYYYMMDD. Untuk tabel berpartisi, 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 mengomunikasikan ketidakcocokan skema ke projectGoogle Cloud yang berisi sink routing dengan cara berikut:

• Pemilik Project akan menerima email. Detailnya mencakup: Google Cloud project ID, 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 pada 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 di set data yang berbeda. Untuk mendapatkan petunjuk, 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 perutean log.

Harga

Cloud Logging tidak mengenakan biaya untuk merutekan log ke tujuan yang didukung; namun, tujuan mungkin mengenakan biaya. Dengan pengecualian bucket log _Required, Cloud Logging mengenakan biaya untuk 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, membuat cakupan log atau tampilan analisis, 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 jika Anda mengirim dan kemudian mengecualikan log alur Virtual Private Cloud dari Cloud Logging.