Anda dapat melihat dan mengambil entri log yang dirutekan dari Cloud Logging ke bucket Cloud Storage untuk mendukung audit keamanan, pengarsipan kepatuhan, atau analisis eksternal. Entri log disimpan ke bucket Cloud Storage dalam batch per jam, dan biasanya muncul dalam waktu 2 hingga 3 jam setelah ekspor.
Sink log tidak dapat merutekan entri log ke bucket Cloud Storage yang dikonfigurasi untuk Rapid storage.
Sebelum memulai
Untuk pembahasan konseptual tentang sink, lihat Ringkasan model perutean dan penyimpanan: Sink.
Untuk mengetahui petunjuk tentang cara merutekan log, lihat Merutekan log ke tujuan yang didukung.
Melihat log
Untuk melihat log yang dirutekan ke Cloud Storage, lakukan hal berikut:
-
Di konsol Google Cloud , buka halaman Buckets:
Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Cloud Storage.
Pilih bucket Cloud Storage yang Anda gunakan sebagai tujuan perutean.
Organisasi log
Saat Anda merutekan log ke bucket Cloud Storage, Logging menulis sekumpulan file ke bucket.
File diatur dalam hierarki direktori berdasarkan jenis dan tanggal log. Jenis log, yang disebut sebagai [LOG_ID] dalam referensi LogEntry, dapat berupa nama seperti syslog atau nama gabungan seperti appengine.googleapis.com/request_log. Jika log ini disimpan dalam bucket bernama my-gcs-bucket, direktori akan diberi nama seperti dalam contoh berikut:
my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/
Satu bucket Cloud Storage dapat berisi log dari beberapa jenis resource. Ukuran file maksimum adalah 3,5 GiB.
Logging tidak menjamin penghapusan duplikat entri log dari sink yang berisi kueri yang identik atau tumpang-tindih; entri log dari sink tersebut mungkin ditulis beberapa kali ke bucket Cloud Storage.
Direktori leaf (DD/) berisi beberapa file, yang masing-masing menyimpan entri log yang dirutekan untuk jangka waktu yang ditentukan dalam nama file. File-file tersebut di-sharding dan namanya diakhiri dengan nomor shard, Sn atau An (n=0, 1, 2, ...). Misalnya, berikut adalah dua file yang mungkin disimpan dalam direktori my-gcs-bucket/syslog/2015/01/13/:
08:00:00_08:59:59_S0.json 08:00:00_08:59:59_S1.json
Kedua file ini bersama-sama berisi entri log syslog
untuk semua instance selama jam yang dimulai pukul 08.00.00 UTC dan berakhir
pukul 08.59.59 UTC. Stempel waktu entri log dinyatakan dalam UTC (Coordinated Universal Time).
Entri log yang tiba dengan receiveTimestamp
dalam periode selaras 60 menit dari timestamp-nya akan ditulis ke
file shard utama. Misalnya, entri log dengan timestamp 08.00.00
dan receiveTimestamp 08.10.00 disimpan dalam file shard utama.
File ini menyertakan shard utama bernomor di akhiran:
_Sn.json.
Entri log yang tiba dengan timestamp dalam periode selaras 60 menit yang berbeda dari receiveTimestamp-nya akan ditulis ke file shard adendum. Misalnya, Entri log dengan timestamp 08.00.00 dan
receiveTimestamp 09.10.00 disimpan dalam file shard adendum.
File ini menyertakan shard adendum bernomor dengan
akhiran: _An:Unix_timestamp.json.
Misalnya, entri log yang memiliki timestamp antara pukul 08.00.00 dan
08.59.59, tetapi receiveTimestamp di jendela berbeda yang selaras 60 menit
ditulis ke file dengan akhiran _An:Unix_timestamp.json,
dengan stempel waktu Unix mengidentifikasi waktu file dirutekan ke
Cloud Storage. Jika entri log memiliki timestamp
08:50:00 dan receiveTimestamp 09:10:00, dan dirutekan pada
09:15:00 pada 25 Maret 2021, file adendum akan ditulis sebagai berikut:
08:00:00_08:59:59_A0:1616681700.json
Untuk mendapatkan semua entri log, Anda harus membaca semua shard untuk setiap jangka waktu—dalam hal ini, shard file 0 dan 1. Jumlah shard file yang ditulis dapat berubah untuk setiap jangka waktu.
Dalam setiap file yang di-sharding, entri log disimpan sebagai daftar objek LogEntry. Untuk contoh entri syslog, lihat
Organisasi entri log.
Perhatikan bahwa tata urutan entri log dalam file tidak seragam atau tidak dijamin.
Batasan
Kolom LogEntry.errorGroups tidak tersedia untuk tujuan ini.
Sink log merutekan entri log yang dikirim ke project Anda, tetapi entri log tersebut tidak berisi grup error.
Entri log yang terlambat masuk
Entri log yang dirutekan disimpan ke bucket Cloud Storage dalam batch per jam.
Mungkin perlu waktu 2 hingga
3 jam sebelum entri pertama mulai
muncul. Shard file log yang dirutekan dengan akhiran An
("Append") menyimpan entri log yang terlambat tiba.
Jika tujuan mengalami pemadaman layanan, Cloud Logging akan menyangga data hingga pemadaman layanan berakhir.
Jika tidak ada log di tujuan sink, periksa metrik sistem ekspor. Metrik sistem ekspor menunjukkan jumlah entri log yang dirutekan dan jumlah entri log yang dihapus karena error. Jika metrik sistem ekspor menunjukkan bahwa tidak ada entri log yang dirutekan ke tujuan, periksa [filter][export-query] Anda untuk memverifikasi bahwa entri log yang cocok dengan filter Anda baru saja tiba di Logging.
Di konsol Google Cloud , buka halaman Log Router:
Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Logging.
Entri log App Engine
App Engine menggabungkan beberapa sub-entri jenis
google.appengine.logging.v1.LogLine (juga disebut AppLog atau
AppLogLine) di bawah entri log utama jenis
google.appengine.logging.v1.RequestLog untuk permintaan
yang menyebabkan aktivitas log. Setiap baris log memiliki "ID permintaan" yang
mengidentifikasi entri utama. Logs Explorer menampilkan baris log dengan
entri log permintaan. Logging mencoba memasukkan semua baris log ke dalam batch dengan permintaan asli, meskipun stempel waktunya akan menempatkannya di batch berikutnya. Jika tidak memungkinkan, entri log permintaan
mungkin tidak memiliki beberapa baris log, dan mungkin ada baris log "orphan" tanpa
permintaan di batch berikutnya. Jika kemungkinan ini penting bagi Anda, bersiaplah
untuk menghubungkan kembali bagian-bagian permintaan saat Anda memproses log.
Pemecahan masalah
Jika log tampaknya tidak ada di tujuan sink atau Anda menduga bahwa sink tidak merutekan log dengan benar, lihat Memecahkan masalah log perutean.