Memahami kuota dan batas burst

Didukung di:

Google SecOps

Perhatian: Ingestion API tidak digunakan lagi dan akan dihentikan pada 20 Juli 2027. Untuk menyerap log ke Google SecOps, gunakan Chronicle API. Untuk mengetahui detail cara bermigrasi, lihat Bermigrasi dari SIEM API lama ke Chronicle API.

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

Definisi batas burst

Batas burst adalah bentuk batasan 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 masif. Batas burst membatasi kecepatan penyerapan (diukur dalam megabyte per detik—MBps, atau gigabyte per detik—GBps) dalam periode lima menit yang bergulir.

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

Cara penghitungan batas burst

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 diperkirakan dan lonjakan yang tidak direncanakan dalam traffic log, batas burst harian Anda disediakan sebagai rentang tertentu, sehingga Anda dapat menyerap antara satu hingga tiga kali (1× hingga 3×) perkiraan rata-rata harian (dihitung sebagai kapasitas tahunan yang dibeli dibagi 365 hari). Tunjangan 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 burst yang disediakan akan benar-benar berada dalam rentang 1 TB hingga 3 TB per hari (yang berarti 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 burst diterapkan per tenant pelanggan Google SecOps.

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

Contoh kapasitas yang dibeli	Rentang batas burst	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 region tersebut. Meskipun Google SecOps mengakomodasi lonjakan volume harian hingga batas 3×, 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 kecepatan dinamis atau pembatasan sementara untuk melindungi stabilitas regional.

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

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

Pemberlakuan batas burst untuk feed berbasis pull

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, forwarder, 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 menjangkau 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 jika rasio penyerapan data Anda secara keseluruhan berada dalam batas burst yang ditetapkan.

Pengecualian untuk batas tingkat jenis log

Meskipun batas tingkat jenis log umumnya berlaku untuk feed berbasis pull, pengecualian berikut berlaku:

• Webhook HTTPS: Metode penyerapan ini berbasis push dan tidak tunduk pada batas tingkat jenis log. Namun, hal ini tunduk pada batas lonjakan keseluruhan tenant pelanggan dan menampilkan kode status HTTP 429 jika feed melebihi batas tersebut.
• Azure Event Hub: Ini adalah metode penyerapan berbasis pull yang tidak tunduk pada batas tingkat jenis log.

Cara penerapan batas lonjakan

Sistem menerapkan batas burst dalam interval lima menit. Misalnya, jika batas lonjakan 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 yang tersisa dari periode tersebut. Batas ini direset secara otomatis pada 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 penarikan 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 periode tersebut. Batas ini akan otomatis direset pada awal interval lima menit berikutnya.

Yang akan terjadi pada data Anda jika Anda melampaui batas lonjakan

Jika Anda melebihi batas burst, Google SecOps akan menjeda penyerapan data tambahan, dan mekanisme berikut akan dipicu—bergantung pada apakah data Anda diserap menggunakan metode berbasis pull atau 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 sementara penyerapan data dengan error HTTP 429 "Too Many Requests". Hal ini memberi sinyal pada mekanisme penyerapan Anda untuk menjeda, melakukan buffering, dan mencoba lagi, sehingga memastikan tidak ada data yang hilang.

Saat menggunakan metode penyerapan berbasis push, tanggung jawab untuk melakukan buffering dan mencoba ulang ada pada 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 buffering disk dan logika percobaan ulang 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, forwarder, atau skrip) mengabaikan error penolakan batas burst dan menghapus entri log, bukan menyimpannya untuk dicoba lagi.

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: Forwarder tidak digunakan lagi. Komponen forwarder akan dihentikan secara bertahap dari 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 Jan 2027: Forwarder resmi mencapai akhir siklus proses (EOL). Tidak akan ada patch lebih lanjut, termasuk patch keamanan, yang akan dirilis. 1 April 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 burst 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 mengirim data ke Google.
Tanggung jawab atas 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 pengirim 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 live.

Cara melihat batas burst yang ditetapkan

Untuk memastikan batas burst yang ditetapkan ke tenant Google SecOps Anda, lakukan hal berikut:

1. Di konsol Google SecOps, buka Dasbor > Penyerapan Data dan Health.
2. Lihat Burst Limit Graph - Quota Limit. Grafik menampilkan batas yang ditetapkan (garis datar) relatif terhadap rasio penyerapan 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 Data dan Health dan lihat hal berikut:

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

Menggunakan Cloud Monitoring untuk melacak apakah Anda mendekati atau melebihi batas burst

Anda dapat menggunakan Metrics Explorer di Google Cloud untuk membuat notifikasi kustom. Sebaiknya buat pemberitahuan penyerapan yang memberi tahu Anda saat volume byte yang diserap melebihi batas burst.

Metrik yang relevan mencakup:

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

Kebijakan pemberitahuan siap pakai

Google SecOps menyediakan kebijakan pemberitahuan siap pakai di Cloud Monitoring yang dapat Anda aktifkan untuk memantau kuota penyerapan.

Untuk menemukan dan mengaktifkan kebijakan ini, lakukan langkah-langkah berikut:

1. Di konsol Google Cloud , buka Monitoring > Integrations.
2. Pilih Chronicle Security dari daftar integrasi.
3. Klik tab Alerts.
4. Tinjau dan aktifkan contoh kebijakan pemberitahuan berikut:
   • Kebijakan Pemberitahuan Mendekati Batas Kuota Penyerapan: Mendeteksi apakah volume penyerapan data Anda mendekati batas kuota.
   • Kebijakan Pemberitahuan Penolakan Kuota Penyerapan: Mendeteksi apakah permintaan penyerapan ditolak karena kuota penyerapan tidak mencukupi (error HTTP 429).

Contoh

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 melebihi 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% dari batas burst

• Untuk memicu pemberitahuan saat Anda mencapai 70% dari batas burst, 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 dimonitor tertentu.

Untuk memantau volume penyerapan harian terhadap batas kontraktual, gunakan metrik Total ukuran log yang diserap (chronicle.googleapis.com/ingestion/log/bytes_count).

Catatan: Jangan gunakan metrik chronicle.googleapis.com/ingestion/quota_limit untuk melacak volume penyerapan harian sesuai kontrak, karena alasan berikut:

• Metrik quota_limit mengukur kedekatan dengan batas backend dinamis, bukan volume data yang sebenarnya diserap.
• Menggunakan quota_limit untuk pemberitahuan volume harian dapat menyebabkan alarm palsu saat nilai minimum backend disesuaikan.

Untuk mengetahui petunjuk cara menyiapkan kebijakan pemberitahuan volume harian, lihat Menyiapkan contoh kebijakan untuk memantau volume penyerapan harian. Untuk petunjuk tentang cara menyiapkan pemberitahuan penyerapan lainnya, lihat Menganalisis penyerapan dengan Cloud Monitoring.

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.
• Optimalkan penyerapan: tinjau skrip penyerapan dan pastikan skrip tersebut tidak mengirimkan data yang tidak diperlukan atau membanjiri API dengan batch besar sekaligus. Sebarkan upload data historis jika memungkinkan. Memfilter data redundan menggunakan fitur pipeline pemrosesan data.
• Menunggu: untuk lonjakan sementara, sering kali cukup dengan menunggu jendela lima menit direset, lalu mencoba 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 sangat tinggi yang berkelanjutan, atau menjalankan arsitektur yang secara konsisten menghasilkan burst penyerapan yang sangat besar, Anda harus menghubungi tim akun Anda untuk penyediaan kapasitas kustom.

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

Pertanyaan umum (FAQ)

Bagian berikut memberikan jawaban atas pertanyaan umum (FAQ).

Dapatkah saya meningkatkan batas lonjakan?

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

Dapatkah saya meningkatkan batas tingkat jenis log untuk feed berbasis pull?

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 burst, Anda dapat melakukan hal berikut:

• Beli kapasitas tambahan untuk meningkatkan batas Anda.
• Nonaktifkan feed tertentu yang mengalami lonjakan volume yang tidak terduga.

• Minta dukungan teknis Google SecOps untuk menghapus 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 masuk. Bergantung pada ukuran backlog Anda, proses ini dapat memerlukan waktu beberapa menit hingga beberapa jam.

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

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

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

• Menggunakan metode berbasis pull: 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".

Data apa pun 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 burst Anda lebih rendah dari yang Anda kontrakkan, hubungi Dukungan Google (lihat Dukungan Google SecOps), dan sertakan batas burst yang Anda harapkan.

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