Mengimpor log dari Cloud Storage ke Cloud Logging

Last reviewed 2025-02-19 UTC

Arsitektur referensi ini menjelaskan cara mengimpor log yang sebelumnya diekspor ke Cloud Storage kembali ke Cloud Logging.

Arsitektur referensi ini ditujukan untuk engineer dan developer, termasuk DevOps, site reliability engineer (SRE), dan investigator keamanan, yang ingin mengonfigurasi dan menjalankan tugas impor log. Dokumen ini mengasumsikan bahwa Anda sudah memahami cara menjalankan tugas Cloud Run, dan cara menggunakan Cloud Storage dan Cloud Logging.

Arsitektur

Diagram berikut menunjukkan cara Google Cloud layanan digunakan dalam arsitektur referensi ini:

Diagram alur kerja impor log dari Cloud Storage ke Cloud Logging.

Alur kerja ini mencakup komponen berikut:

  • Bucket Cloud Storage: Berisi log yang sebelumnya diekspor yang ingin Anda impor kembali ke Cloud Logging. Karena log ini sebelumnya diekspor, log tersebut diatur dalam format ekspor yang diharapkan.
  • Cloud Run tugas: Menjalankan proses impor log:
    • Membaca objek yang menyimpan entri log dari Cloud Storage.
    • Menemukan log yang diekspor untuk ID log yang ditentukan, dalam rentang waktu yang diminta, berdasarkan organisasi log yang diekspor di bucket Cloud Storage.
    • Mengonversi objek menjadi struktur LogEntry Cloud Logging API. Beberapa struktur LogEntry digabungkan ke dalam batch, untuk mengurangi penggunaan kuota Cloud Logging API. Arsitektur ini menangani error kuota jika diperlukan.
    • Menulis entri log yang dikonversi ke Cloud Logging. Jika Anda menjalankan kembali tugas yang sama beberapa kali, entri duplikat dapat terjadi. Untuk mengetahui informasi selengkapnya, lihat Menjalankan tugas impor.
  • Cloud Logging: Menyerap dan menyimpan entri log yang dikonversi. Entri log diproses seperti yang dijelaskan dalam Ringkasan perutean dan penyimpanan.
    • Kuota dan batasan Logging berlaku, termasuk kuota dan batasan Cloud Logging API serta periode retensi 30 hari. Arsitektur referensi ini dirancang untuk berfungsi dengan kuota tulis default, dengan mekanisme percobaan ulang dasar. Jika kuota tulis Anda lebih rendah dari default, penerapan mungkin akan gagal.
    • Log yang diimpor tidak disertakan dalam metrik berbasis log, karena stempel waktunya berada di masa lalu. Namun, jika Anda memilih untuk menggunakan label, stempel waktu akan mencatat waktu impor, dan log akan disertakan dalam data metrik.
  • BigQuery: Menggunakan SQL untuk menjalankan kueri analisis pada log yang diimpor (opsional). Untuk mengimpor log audit dari Cloud Storage, arsitektur ini mengubah ID log; Anda harus memperhitungkan penggantian nama ini saat membuat kueri log yang diimpor.

Kasus penggunaan

Anda dapat memilih untuk men-deploy arsitektur ini jika organisasi Anda memerlukan analisis log tambahan untuk investigasi insiden atau audit peristiwa masa lalu lainnya. Misalnya, Anda mungkin ingin menganalisis koneksi ke database Anda untuk kuartal pertama tahun lalu, sebagai bagian dari audit akses database.

Alternatif desain

Bagian ini menjelaskan alternatif untuk desain default yang ditampilkan dalam dokumen arsitektur referensi ini.

Periode retensi dan log yang diimpor

Cloud Logging mengharuskan entri log masuk memiliki stempel waktu yang tidak melebihi periode retensi 30 hari . Entri log yang diimpor dengan stempel waktu yang lebih lama dari 30 hari sejak waktu impor tidak akan disimpan.

Arsitektur ini memvalidasi rentang tanggal yang ditetapkan dalam tugas Cloud Run untuk menghindari impor log yang lebih lama dari 29 hari, sehingga menyisakan margin keamanan satu hari.

Untuk mengimpor log yang lebih lama dari 29 hari, Anda harus melakukan perubahan berikut pada kode implementasi, lalu membuat image container baru untuk digunakan dalam konfigurasi tugas Cloud Run.

  • Menghapus validasi rentang tanggal 30 hari
  • Menambahkan stempel waktu asli sebagai label pengguna ke entri log
  • Mengreset label stempel waktu entri log agar dapat diserap dengan stempel waktu saat ini

Saat menggunakan modifikasi ini, Anda harus menggunakan kolom labels bukan kolom timestamp dalam kueri Observability Analytics. Untuk mengetahui informasi selengkapnya tentang kueri dan contoh Observability Analytics, lihat Contoh kueri SQL.

Pertimbangan desain

Panduan berikut dapat membantu Anda mengembangkan arsitektur yang memenuhi persyaratan organisasi Anda.

Pengoptimalan biaya

Biaya untuk mengimpor log menggunakan arsitektur referensi ini memiliki beberapa faktor kontribusi.

Anda menggunakan komponen yang dapat ditagih sebagai berikut: Google Cloud

Pertimbangkan faktor-faktor berikut yang dapat meningkatkan biaya:

  • Duplikasi log: Untuk menghindari biaya penyimpanan log tambahan, jangan jalankan tugas impor dengan konfigurasi yang sama beberapa kali.
  • Penyimpanan di tujuan tambahan: Untuk menghindari biaya penyimpanan log tambahan, nonaktifkan kebijakan perutean di project tujuan untuk mencegah penyimpanan log di lokasi tambahan atau meneruskan log ke tujuan lain seperti Pub/Sub atau BigQuery.
  • CPU dan memori tambahan: Jika tugas impor Anda mengalami error waktu tunggu, Anda mungkin perlu meningkatkan CPU dan memori tugas impor dalam konfigurasi tugas impor. Meningkatkan nilai ini dapat meningkatkan biaya Cloud Run yang timbul.
  • Tugas tambahan: Jika jumlah log yang diharapkan untuk diimpor setiap hari dalam rentang waktu tinggi, Anda mungkin perlu meningkatkan jumlah tugas dalam konfigurasi tugas impor. Tugas akan membagi rentang waktu secara merata di antara tugas, sehingga setiap tugas akan memproses jumlah hari yang serupa dari rentang secara serentak. Meningkatkan jumlah tugas dapat meningkatkan biaya Cloud Run yang timbul.
  • Kelas penyimpanan: Jika kelas penyimpanan bucket Cloud Storage Anda bukan Standar, seperti Nearline, Durable Reduced Availability (DRA), atau Coldline, Anda mungkin akan dikenai biaya tambahan.
  • Traffic data antar-lokasi yang berbeda: Konfigurasi tugas impor untuk dijalankan di lokasi yang sama dengan bucket Cloud Storage tempat Anda mengimpor log. Jika tidak, biaya traffic keluar jaringan mungkin akan dikenakan.

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, termasuk tugas Cloud Run, gunakan kalkulator harga.

Efisiensi operasional

Bagian ini menjelaskan pertimbangan untuk mengelola kueri analisis setelah solusi di-deploy.

Nama dan kueri log

Log disimpan ke project yang ditentukan di logName kolom entri log. Untuk mengimpor log ke project yang dipilih, arsitektur ini mengubah kolom logName setiap log yang diimpor. Log impor disimpan di bucket log default project yang dipilih yang memiliki ID log imported_logs (kecuali jika project memiliki kebijakan perutean log yang mengubah tujuan penyimpanan). Nilai asli kolom logName dipertahankan di kolom labels dengan kunci original_logName.

Anda harus memperhitungkan lokasi nilai logName asli saat membuat kueri log yang diimpor. Untuk mengetahui informasi selengkapnya tentang kueri dan contoh Observability Analytics, lihat Contoh kueri SQL.

Pengoptimalan performa

Jika volume log yang Anda impor melebihi batas kapasitas Cloud Run, tugas mungkin akan mengalami error waktu tunggu sebelum impor selesai. Untuk mencegah impor data yang tidak lengkap, pertimbangkan untuk meningkatkan nilai tasks dalam tugas impor. Meningkatkan CPU dan memori resource juga dapat membantu meningkatkan performa tugas saat Anda meningkatkan jumlah tugas.

Deployment

Untuk men-deploy arsitektur ini, lihat Men-deploy tugas untuk mengimpor log dari Cloud Storage ke Cloud Logging.

Langkah Berikutnya

Kontributor

Penulis: Leonid Yankulin | Developer Relations Engineer

Kontributor lainnya: