Memahami kuota dan batas burst

Didukung di:

Google secops

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

Definisi batas burst

Batas burst 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.

Catatan: Untuk mengetahui 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 diharapkan dan lonjakan traffic log yang tidak direncanakan, batas burst 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 Anda beli dibagi 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 burst yang disediakan akan 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 korespondensi batas burst dengan jumlah kapasitas yang dibeli yang berbeda:

Contoh kapasitas yang dibeli	Rentang batas burst	Batas burst 5 menit	Penyerapan pada batas burst maksimum (per jam)	Penyerapan pada batas burst maksimum (per hari)	Penyerapan pada batas burst maksimum (per tahun)
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. 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 yang sangat tinggi, lihat Perencanaan kapasitas kustom untuk throughput yang sangat tinggi.

Penerapan batas burst untuk feed berbasis pull

Google SecOps juga membatasi penyerapan berbasis pull menjadi sepertiga (33%) dari batas burst keseluruhan per jenis log (di semua feed). Batas ini diterapkan untuk memastikan bahwa penyerapan berbasis pull (biasanya dari sumber cloud) tidak menghabiskan batas burst keseluruhan tenant Anda dan tidak menghambat 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 (yang merupakan 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 burst yang ditetapkan.

Pengecualian untuk batas tingkat jenis log untuk metode penyerapan berbasis pull

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

• Webhook HTTPS: ini adalah metode berbasis push dengan batas tingkat jenis log.
• Azure Event Hub: ini adalah metode berbasis pull tanpa batas tingkat jenis log.

Cara penerapan batas burst

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

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

Yang terjadi pada data Anda jika Anda melampaui batas burst

Jika Anda melampaui 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 berbasis push:

• Menggunakan metode berbasis pull: penyerapan akan di-buffer secara otomatis dan tidak memerlukan konfigurasi tambahan dari Anda, pelanggan. Data akan tetap disimpan di penyimpanan buffer hingga batas direset dan Google SecOps melanjutkan penyerapan data.
• Menggunakan metode berbasis push: Google SecOps akan menolak penyerapan data untuk sementara dengan error HTTP 429 "Terlalu Banyak Permintaan". Hal ini akan memberi sinyal kepada mekanisme penyerapan Anda untuk menjeda, melakukan buffering, dan mencoba lagi, sehingga memastikan 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 data dan mencoba lagi).

Penolakan batas burst bukan merupakan kehilangan data

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

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

Kehilangan data hanya terjadi jika sistem pengiriman (misalnya, agen Bindplane, penerus, atau skrip) mengabaikan error penolakan batas burst dan menghapus entri log, bukan menyimpannya untuk dicoba lagi.

Tanggung jawab pelanggan untuk buffering data dan mencoba lagi

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

Perhatian: Penerus tidak digunakan lagi. Komponen penerus sedang dihentikan dari platform Google SecOps dan akan mencapai akhir masa pakainya (EOL) pada Januari 2027. 1 April 2026: Pelanggan Google SecOps baru tidak dapat menggunakan komponen penerus. 1 Januari 2027: Penerus secara resmi EOL. Tidak ada patch lebih lanjut, termasuk patch keamanan, yang akan dirilis. 1 April 2027: Data tidak lagi diizinkan untuk diserap dari komponen penerus. Google merekomendasikan penggunaan Bindplane untuk Google SecOps sebagai solusi utama untuk pengumpulan log. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Bindplane dengan Google SecOps.

Anda harus mengonfigurasi sistem untuk melakukan buffering dan mengirim ulang data secara otomatis saat batas burst tercapai guna menangani overflow 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 untuk buffering data dan mencoba lagi	Google SecOps mengelola buffering secara otomatis. Saat batas burst tercapai, Google SecOps akan menjeda penyerapan data tambahan. Data akan 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 ditetapkan ke "hapus jika gagal", 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.	Penerus Google SecOps, 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 mencoba lagi. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi buffering dan coba lagi untuk sistem berbasis push.

Kapan data yang di-buffer untuk feed berbasis pull diisi ulang

Untuk feed yang menggunakan metode penyerapan berbasis pull, saat periode batas burst direset, Google SecOps akan mengisi ulang data yang di-buffer, dengan memprioritaskan data live 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 Anda.

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 dan Kesehatan Data.
2. Lihat Grafik Batas Burst - Batas Kuota. Grafik ini menampilkan batas yang ditetapkan (garis datar) relatif terhadap kecepatan penyerapan aktual Anda.

Melacak apakah Anda mendekati atau melampaui batas burst

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

Menggunakan dasbor Google SecOps untuk melacak apakah Anda mendekati atau melampaui batas burst

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

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

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

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

Metrik yang relevan mencakup hal berikut:

• 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 Google Cloud konsol, 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 burst

• Untuk melihat penggunaan batas burst, 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 melampaui 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 burst

• Untuk memicu pemberitahuan saat Anda mencapai 70% 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.

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

Menangani penolakan batas burst yang disebabkan oleh metode berbasis push

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

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

Untuk beberapa contoh konfigurasi, lihat Konfigurasi buffering dan coba lagi untuk sistem berbasis push.

Perencanaan kapasitas kustom untuk throughput yang sangat tinggi

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

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

Pertanyaan umum (FAQ)

Bagian berikut memberikan jawaban atas pertanyaan umum (FAQ).

Dapatkah saya meningkatkan batas burst?

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

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

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

Meningkatkan batas tingkat jenis log untuk satu jenis log tidak akan mengubah batas yang diterapkan ke jenis log lain atau batas burst keseluruhan Anda.

Apakah backlog data saya dapat dilacak?

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 akan 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, proses ini dapat memerlukan waktu beberapa menit hingga beberapa jam.

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

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

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

• Menggunakan metode berbasis pull: penyerapan akan di-buffer secara otomatis dan tidak memerlukan konfigurasi tambahan.
• Menggunakan metode berbasis push: Google SecOps akan menolak data untuk sementara dengan error HTTP 429 "Terlalu Banyak Permintaan".

Data apa pun yang telah diubah setelah batas burst dipicu akan di-buffer sementara dalam antrean internal hingga batas direset dalam periode lima menit berikutnya.

Apa yang harus saya lakukan jika batas burst 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.