Memahami kuota dan batas lonjakan

Didukung di:

Google secops

Dokumen ini menjelaskan kuota dan batas lonjakan di Google Security Operations.

Definisi batas burst

Batas lonjakan adalah bentuk batas layanan di Google SecOps yang berfungsi sebagai batas kecepatan untuk penyerapan data, yang dirancang untuk melindungi infrastruktur bersama platform dari lonjakan traffic yang tiba-tiba dan besar. Batas burst membatasi kecepatan penyerapan (diukur dalam megabyte per detik—MBps, atau gigabyte per detik—GBps) dalam periode lima menit bergulir.

Catatan: Untuk definisi layanan dan istilah lainnya, lihat Persyaratan Khusus Layanan SecOps.

Cara penghitungan batas lonjakan

Google SecOps menetapkan batas burst ke tenant Google SecOps Anda berdasarkan volume penyerapan tahunan yang Anda beli (kapasitas yang dibeli) sesuai dengan lisensi Google SecOps Anda.

Untuk mengakomodasi variasi yang diharapkan dan lonjakan traffic log yang tidak direncanakan, batas lonjakan harian Anda disediakan sebagai rentang tertentu, sehingga Anda dapat menyerap antara satu hingga tiga kali (1× hingga 3×) rata-rata harian yang diharapkan (dihitung sebagai kapasitas tahunan yang dibeli dibagi dengan 365 hari). Alokasi volume yang fleksibel ini dirancang untuk menyerap lonjakan penyerapan standar tanpa mengganggu operasi Anda. Misalnya, jika kapasitas tahunan yang Anda beli adalah 365 TB, rata-rata harian yang diharapkan adalah 1 TB. Batas lonjakan yang disediakan akan berada dalam rentang 1 TB hingga 3 TB per hari (yang diterjemahkan ke rentang throughput sekitar 12 MBps hingga 36 MBps). Jika penyerapan data Anda secara konsisten melebihi rentang 1×–3× yang disediakan ini, Anda harus meningkatkan kapasitas tahunan yang dibeli.

Batas lonjakan diberlakukan per tenant pelanggan Google SecOps.

Tabel berikut menunjukkan korespondensi batas burst dengan berbagai jumlah kapasitas yang dibeli:

Contoh kapasitas yang dibeli	Rentang batas lonjakan	Batas burst 5 menit	Penyerapan pada batas burst maksimum (per jam)	Penyerapan pada batas burst maksimum (harian)	Penyerapan pada batas burst maksimum (tahunan)
100 TB	3 - 10 MBps	0,9 - 3 GB	~34 GB	~822 GB	300 TB
500 TB	16 - 48 MBps	4,8 - 14,4 GB	~171 GB	~4 TB	1,5 PB
1 PB	32 - 97 MBps	9,6 - 29 GB	~343 GB	~8 TB	3 PB
5 PB	158 - 476 MBps	47,4 - 143 GB	~1,7 TB	~41 TB	15 PB
30 PB	0,96 - 2,86 GBps	288 - 858 GB	~10,3 TB	~247 TB	90 PB

Catatan: Alokasi volume harian masih tunduk pada batasan throughput fisik di wilayah tersebut. Meskipun Google SecOps mengakomodasi lonjakan volume harian hingga batas 3x, kecepatan transfer data instan (throughput) dikelola secara aktif untuk memberikan ketersediaan tinggi dan mencegah kekurangan resource di seluruh lingkungan regional bersama.

Traffic penyerapan yang mencakup lonjakan kecepatan ekstrem dan tiba-tiba dapat dikenai pembatasan frekuensi pengiriman dinamis atau pembatasan sementara untuk melindungi stabilitas regional.

Selama periode ini, data mungkin mengalami keterlambatan penyerapan hingga lonjakan mereda.

Untuk persyaratan throughput sangat tinggi, lihat Perencanaan kapasitas kustom untuk throughput sangat tinggi.

Penerapan batas burst untuk feed berbasis penarikan

Google SecOps juga membatasi penyerapan berbasis penarikan hingga sepertiga (33%) dari batas lonjakan keseluruhan per jenis log (di semua feed). Batasan ini diterapkan untuk memastikan bahwa penyerapan berbasis pull (biasanya dari sumber cloud) tidak menghabiskan batas burst keseluruhan tenant Anda dan menghentikan penyerapan data menggunakan metode berbasis push (seperti menggunakan agen Bindplane, penerus, atau penyerapan langsung ke Google SecOps API).

Metode penyerapan berbasis pull

Metode berbasis pull mencakup metode penyerapan (disebut sebagai jenis sumber di Google SecOps) tempat Google SecOps secara aktif menghubungi API sumber untuk mengambil data. Hal ini mencakup jenis sumber berikut yang didukung di Google SecOps:

• API pihak ketiga
• Azure Event Hub
• Penyerapan langsung dari Google Workspace dan Google Cloud
• Cloud Storage
• Feed Cloud Storage (berbasis peristiwa)
• Amazon S3
• Amazon SQS
• Azure Blobstore
• Permintaan SFTP
• Permintaan HTTP

Misalnya, jika batas burst untuk tenant Anda ditetapkan ke 150 MBps, dan tenant Anda menyerap log konteks pengguna Okta menggunakan konektor API pihak ketiga (yaitu, metode penyerapan berbasis pull), sistem akan membatasi kecepatan penyerapan semua feed Okta yang digabungkan hingga maksimum [150/3 =] 50 MBps. Batas tambahan ini diterapkan meskipun kecepatan penyerapan data keseluruhan Anda berada dalam batas lonjakan yang ditetapkan.

Pengecualian terhadap batas tingkat logtype untuk metode penyerapan berbasis penarikan

Meskipun batas tingkat logtype umumnya berlaku untuk feed berbasis penarikan, pengecualian berikut berlaku:

• Webhook HTTPS: ini adalah metode berbasis push dengan batas tingkat logtype.
• Azure Event Hub: ini adalah metode berbasis penarikan tanpa batas tingkat logtype.

Cara penerapan batas burst

Sistem menerapkan batas burst dalam interval lima menit. Misalnya, jika batas burst Anda ditetapkan ke 50 MBps, Anda dapat melakukan penyerapan hingga 15 GB setiap lima menit. Jika Anda menyerap semua 15 GB dalam dua menit pertama, penyerapan akan diblokir selama tiga menit berikutnya dalam jangka waktu tersebut. Batas ini akan otomatis direset di awal interval lima menit berikutnya.

Batas tingkat logtype diterapkan dengan cara yang sama, tetapi berlaku di tingkat setiap logtype. Misalnya, jika Anda dialokasikan 5 GB untuk feed berbasis pull setiap lima menit, dan total volume data yang di-ingest untuk satu jenis log melebihi 5 GB dalam dua menit pertama, penyerapan akan dijeda selama tiga menit yang tersisa dalam jangka waktu tersebut. Batas akan otomatis direset pada awal interval lima menit berikutnya.

Yang terjadi pada data Anda jika Anda melampaui batas lonjakan

Jika Anda melampaui batas lonjakan, Google SecOps akan menjeda penyerapan data tambahan, dan mekanisme berikut akan dipicu—bergantung pada apakah data Anda diserap menggunakan metode berbasis pull atau berbasis push:

• Menggunakan metode berbasis pull: penyerapan data di-buffer secara otomatis dan tidak memerlukan konfigurasi tambahan dari Anda, pelanggan. Data tetap disimpan di penyimpanan buffer hingga batas direset dan Google SecOps melanjutkan penyerapan data.
• Menggunakan metode berbasis push: Google SecOps menolak penyerapan data untuk sementara dengan error HTTP 429 "Too Many Requests". Hal ini memberi sinyal pada mekanisme penyerapan Anda untuk menjeda, melakukan buffering, dan mencoba lagi, sehingga tidak ada data yang hilang.

Dengan menggunakan metode penyerapan berbasis push, tanggung jawab untuk melakukan buffering dan mencoba lagi berada di tangan Anda, pelanggan (lihat Tanggung jawab pelanggan untuk buffering dan percobaan ulang data).

Penolakan batas lonjakan tidak menyebabkan kehilangan data

Penting untuk dipahami bahwa penolakan batas lonjakan (HTTP 429) bukan peristiwa kehilangan data. Penolakan batas lonjakan (error HTTP 429) adalah jeda dalam penyerapan data.

Dengan memastikan sistem berbasis push Anda memiliki logika percobaan ulang dan buffering disk yang memadai, mencapai batas burst hanya akan menyebabkan sedikit penundaan (keterlambatan penyerapan), bukan kehilangan telemetri keamanan secara permanen.

Kehilangan data hanya terjadi jika sistem pengirim (misalnya, agen Bindplane, penerus, atau skrip) mengabaikan error penolakan batas lonjakan dan menghapus entri log, bukan menyimpannya untuk percobaan ulang.

Tanggung jawab pelanggan untuk buffering dan percobaan ulang data

Meskipun Google SecOps secara otomatis mengelola buffering data dan percobaan ulang untuk data yang diserap menggunakan metode penyerapan berbasis pull, Anda bertanggung jawab atas buffering data dan percobaan ulang penyerapan data menggunakan metode penyerapan berbasis push (seperti webhook HTTPS, Bindplane, forwarder, atau Cribl).

Perhatian: Penerusan tidak digunakan lagi. Komponen penerusan tidak digunakan lagi di platform Google SecOps dan akan mencapai akhir siklus proses (EOL) pada Januari 2027. 1 Apr 2026: Pelanggan baru Google SecOps tidak dapat menggunakan komponen penerusan. 1 Januari 2027: Penerusan email resmi dihentikan. Patch lebih lanjut, termasuk patch keamanan, tidak akan dirilis. 1 Apr 2027: Data tidak lagi diizinkan untuk di-ingest dari komponen penerusan. Google merekomendasikan penggunaan BindPlane untuk Google SecOps sebagai solusi utama untuk pengumpulan log. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Bindplane dengan Google SecOps.

Anda perlu mengonfigurasi sistem untuk secara otomatis melakukan buffering dan mengirim ulang data saat batas lonjakan tercapai untuk menangani luapan data secara efisien.

Tabel berikut menyoroti perbedaan utama dalam cara Google SecOps menangani penyerapan data saat batas lonjakan Anda tercapai untuk kedua jenis metode penyerapan:

Fitur	Penyerapan berbasis pull	Penyerapan berbasis push
Cara kerjanya	Google SecOps secara aktif menghubungi API sumber untuk mengambil data.	Sistem Anda memulai koneksi dan mengirimkan data ke Google.
Tanggung jawab untuk buffering dan percobaan ulang data	Google SecOps mengelola buffering secara otomatis. Saat batas lonjakan tercapai, Google SecOps akan menjeda penyerapan data tambahan. Data tetap disimpan di penyimpanan buffer hingga batas direset dan Google SecOps melanjutkan pengambilan. Penyimpanan buffer hanya menyimpan data hingga 90 hari, setelah itu data akan dihapus.	Pelanggan harus mengelola buffering. Saat Google SecOps membalas dengan HTTP 429, sistem pengiriman Anda harus menangkap error ini, menyimpan data ke antrean lokal (disk atau memori), dan mencoba mengirimkannya lagi nanti. Jika pengirim Anda disetel ke "drop on failure", data akan hilang.
Jenis sumber data	API pihak ketiga, Azure Event Hub, penyerapan langsung dari Google Workspace dan Google Cloud, Cloud Storage, feed Cloud Storage (berbasis peristiwa), Amazon S3, Amazon SQS, Azure Blobstore, permintaan SFTP, permintaan HTTP.	Penerusan SecOps Google, agen Bindplane, Pub/Sub, Amazon Kinesis Firehose, webhook HTTPS, langsung ke API penyerapan.
Tindakan pengguna	Lakukan langkah-langkah untuk menyelaraskan volume penyerapan data dengan kapasitas yang Anda beli.	Selain itu, pastikan sumber penyerapan Anda dikonfigurasi untuk retensi data, buffering, dan percobaan ulang. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi buffering dan percobaan ulang untuk sistem berbasis push.

Saat data yang di-buffer untuk feed berbasis tarik diisi ulang

Untuk feed yang menggunakan metode penyerapan berbasis penarikan, saat periode batas lonjakan Anda direset, Google SecOps akan mengisi kembali data yang di-buffer, dengan memprioritaskan data langsung daripada data yang di-buffer. Mekanisme ini memastikan bahwa backlog data yang di-buffer tidak mengganggu traffic data live yang masuk (yang dapat memperparah penundaan deteksi).

Catatan: Selama pengisian ulang data yang di-buffer, Anda mungkin melihat data yang di-buffer mengalir secara paralel dengan data real time.

Cara melihat batas lonjakan yang ditetapkan untuk Anda

Untuk mengetahui batas lonjakan yang ditetapkan ke tenant Google SecOps Anda, lakukan hal berikut:

1. Di konsol Google SecOps, buka Dasbor > Penyerapan Data dan Kesehatan.
2. Lihat Grafik Batas Burst - Batas Kuota. Grafik menampilkan batas yang ditetapkan (garis datar) relatif terhadap kecepatan penyerapan data Anda yang sebenarnya.

Melacak apakah Anda mendekati atau melampaui batas lonjakan

Anda dapat melacak pemanfaatan menggunakan dasbor bawaan atau menggunakan Cloud Monitoring.

Gunakan dasbor Google SecOps untuk melacak apakah Anda mendekati atau melebihi batas lonjakan

• Buka Dasbor > Penyerapan dan Kondisi Data, lalu lihat hal berikut:

  • Grafik kecepatan penyerapan: menampilkan throughput Anda saat ini.
  • Grafik penolakan lonjakan: menampilkan volume log yang ditolak (error HTTP 429) karena melampaui batas lonjakan.

Gunakan Cloud Monitoring untuk melacak apakah Anda mendekati atau melampaui batas lonjakan

Anda dapat menggunakan Penjelajah Metrik di Google Cloud untuk membuat pemberitahuan kustom. Sebaiknya buat pemberitahuan penyerapan yang memberi tahu Anda saat volume byte yang diserap melebihi nilai minimum batas lonjakan.

Metrik yang relevan mencakup:

• Volume yang diproses: chronicle.googleapis.com/ingestion/log/bytes_count
• Volume yang ditolak: chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

Bagian berikut berisi contoh kueri PromQL untuk pemantauan dan pemberitahuan.

Melihat penggunaan batas lonjakan

• Untuk melihat penggunaan batas lonjakan, gunakan kueri PromQL berikut:

  100 * sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))/min(min_over_time(chronicle_googleapis_com:ingestion_quota_limit{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))

Melihat jumlah byte yang ditolak setelah melebihi batas burst

• Untuk melihat jumlah byte yang ditolak setelah melampaui batas burst, gunakan kueri PromQL berikut:

  topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}])))

Memicu pemberitahuan saat Anda mencapai 70% batas lonjakan

• Untuk memicu pemberitahuan saat Anda mencapai 70% batas lonjakan, gunakan kueri PromQL berikut:

  100 * topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}]))) > 70

Catatan: Sintaksis kueri yang tepat dapat bervariasi berdasarkan konfigurasi resource yang dipantau tertentu.

Untuk mengetahui informasi selengkapnya tentang cara menyiapkan pemberitahuan penyerapan, lihat Menggunakan Cloud Monitoring untuk mendapatkan insight penyerapan.

Menangani penolakan batas lonjakan yang disebabkan oleh metode berbasis push

Jika Anda mengalami error penolakan (HTTP 429) karena mencapai batas lonjakan untuk data masuk menggunakan metode berbasis push, sebaiknya lakukan langkah-langkah berikut:

• Verifikasi buffering: pastikan sumber penyerapan data Anda melakukan buffering data dan mencoba lagi.
• Mengoptimalkan penyerapan: tinjau skrip penyerapan dan pastikan skrip tersebut tidak mengirimkan data yang tidak perlu atau membanjiri API dengan batch besar sekaligus. Sebarkan upload data historis jika memungkinkan. Menyaring data yang berlebihan menggunakan fitur pipeline pemrosesan data.
• Tunggu: untuk lonjakan sementara, sering kali cukup menunggu hingga periode lima menit direset, lalu coba lagi.

Untuk beberapa contoh konfigurasi, lihat Konfigurasi buffering dan percobaan ulang untuk sistem berbasis push.

Perencanaan kapasitas kustom untuk throughput sangat tinggi

Terlepas dari apa pun yang dijelaskan di bagian lain dalam dokumen ini, throughput penyerapan data yang melebihi 3 GBps dianggap sebagai throughput sangat tinggi. Jika Anda merencanakan migrasi data berskala besar, mengantisipasi throughput ultra-tinggi yang berkelanjutan, atau menjalankan arsitektur yang secara konsisten menghasilkan lonjakan penyerapan data yang sangat besar, Anda harus menghubungi tim akun Anda untuk penyediaan kapasitas kustom.

Karena perlu waktu beberapa minggu untuk men-deploy perluasan kapasitas regional khusus, harap beri tahu Google Cloud dukungan setidaknya 90 hari sebelum peristiwa penyerapan ekstrem yang diperkirakan terjadi untuk memastikan persyaratan throughput Anda dapat dipenuhi.

Pertanyaan umum (FAQ)

Bagian berikut memberikan jawaban atas pertanyaan umum (FAQ).

Dapatkah saya meningkatkan batas lonjakan?

Jika Anda memperkirakan volume penyerapan data Anda akan meningkat secara permanen, Anda dapat meningkatkan kapasitas yang dibeli dengan menghubungi Sales Rep Google SecOps.

Dapatkah saya meningkatkan batas tingkat logtype untuk feed berbasis penarikan?

Anda dapat meningkatkan batas tingkat logtype untuk logtype tertentu dengan mengajukan permintaan menggunakan dukungan teknis Google SecOps terlebih dahulu.

Meningkatkan batas tingkat logtype untuk satu logtype tidak akan mengubah batas yang diterapkan pada logtype lain atau batas lonjakan keseluruhan Anda.

Apakah mungkin untuk melacak backlog data saya?

Saat ini, tidak.

Apa saja kemungkinan cara untuk menghapus backlog data saya?

Jika Anda telah mengumpulkan backlog data yang sangat besar, dan ingin menghapus backlog tersebut untuk mengosongkan kuota batas lonjakan, Anda dapat melakukan hal berikut:

• Beli kapasitas tambahan untuk meningkatkan batas Anda.
• Nonaktifkan feed tertentu yang volumenya tiba-tiba meningkat secara tidak terduga.

• Minta dukungan teknis Google SecOps untuk mengurangi backlog Anda.

  Untuk menghapus backlog, feed data Anda dinonaktifkan sementara hingga semua permintaan coba lagi untuk data yang diisi ulang berhasil diproses. Selama waktu ini, Anda tidak akan dapat menyerap data baru.

  Setelah backlog dihapus, feed Anda akan diaktifkan kembali, dan Anda akan melihat data baru mengalir. Bergantung pada ukuran backlog Anda, proses ini dapat memerlukan waktu beberapa menit hingga beberapa jam.

Apakah batas lonjakan juga berlaku untuk penyerapan data ke dalam pipeline pemrosesan data?

Batas kecepatan penyerapan yang berlaku untuk feed data yang mengirim data log mentah ke pipeline pemrosesan data Google SecOps ditetapkan lebih tinggi daripada batas lonjakan tenant Anda.

Jika Anda melampaui batas lonjakan, pipeline pemrosesan data akan berhenti menerima permintaan tambahan, sesuai dengan hal berikut:

• Menggunakan metode berbasis penarikan: penyerapan di-buffer secara otomatis dan tidak memerlukan konfigurasi tambahan.
• Menggunakan metode berbasis push: Google SecOps menolak data untuk sementara dengan error HTTP 429 "Too Many Requests".

Setiap data yang telah diubah setelah batas lonjakan dipicu akan di-buffer sementara dalam antrean internal hingga batas direset dalam periode lima menit berikutnya.

Apa yang harus saya lakukan jika batas lonjakan saya lebih rendah dari yang saya kontrakkan?

Jika batas lonjakan Anda lebih rendah dari yang Anda kontrakkan, hubungi Dukungan Google (lihat Dukungan SecOps Google), dan sertakan batas lonjakan yang Anda harapkan.

Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.