Melihat log yang dirutekan ke BigQuery

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:

  1. Di panel navigasi konsol Google Cloud, pilih BigQuery:

    Buka BigQuery

  2. 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 dan apache-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 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 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 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 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 timestamp1 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:

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 adalah string, entri log tersebut akan menghasilkan tabel dengan jenis string untuk kolom tersebut. Jika nanti Anda mulai mencatat jsonPayload.user_id sebagai array 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 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 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: