[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eBurst limits control the maximum data ingestion rate for each customer in Google Security Operations (SecOps) over a five-minute period, ensuring no single customer's data surge affects others.\u003c/p\u003e\n"],["\u003cp\u003eCustomers can request burst limit increases by contacting Google SecOps Technical Support, especially when anticipating rapid ingestion rate growth.\u003c/p\u003e\n"],["\u003cp\u003eGoogle SecOps offers tools like the Data Ingestion and Health dashboard, as well as Cloud Monitoring, to view real-time burst limit usage and track data ingestion rates.\u003c/p\u003e\n"],["\u003cp\u003eProperly configured ingestion sources should buffer, not drop, data when burst limits are reached, with specific buffering guidelines varying by ingestion method, such as automatic buffering for Google Cloud and API feeds versus manual configuration for forwarders and webhooks.\u003c/p\u003e\n"],["\u003cp\u003eIf you exceed the burst limit you will receive the HTTP 429 error, to resolve this you should retry the request after five minutes, and if you expect your ingestion to be 4x above normal you should contact Google SecOps Technical support.\u003c/p\u003e\n"]]],[],null,["# Burst limits\n============\n\nThis document describes the burst limits that apply to Google Security Operations resources, specifically the volume of data which can be ingested into Google SecOps by a single customer.\nBurst limits restrict the use resources shared by all customers:\n\n- Upper limit on the amount of data ingestion which can be used by a single customer. This ensures that a sudden influx of data from a single customer does not impact others.\n- Monitors the use of shared resources for each customer.\n- Maintains configurations that automatically enforce the burst limits.\n- Provides a means to request or make changes to burst limits.\n\nFor surge protection, the burst limit is measured over periods of 5 minutes. It is not a daily ingestion limit.\n\nBurst limit increase per customer\n---------------------------------\n\nIf you intend to rapidly increase your ingestion rate, we can help you pre-plan and ensure that your data ingestion remains stable. To request an increase in your burst limit, contact [Google SecOps Technical Support](/chronicle/docs/getting-support) in advance.\n\nBurst limits overview\n---------------------\n\nBurst limits restrict how much data one customer can send\nto Google SecOps. This ensures fairness and prevents impacts to other\ncustomers due to ingestion spikes from any single customer. Burst limits\nensure that customer data ingestion works smoothly and can be adjusted proactively using a support ticket.\nTo apply burst limits, Google SecOps uses the following classifications\nbased on ingestion volume:\n\nThe following guidelines apply to burst limits:\n\n- When your burst limit is reached, properly configured ingestion sources should be set to [buffer](#ingestion-buffer) the additional data. They shouldn't be configured to drop the data.\n\n - For pull-based ingestion such as Google Cloud and API feeds, ingestion is buffered automatically and requires no additional configuration.\n - For push-based ingestion methods, such as forwarders, webhooks, and API ingestion, configure the systems to automatically resend data when the burst limit is reached. For systems like Bindplane and Cribl, set up buffering to handle data overflow efficiently.\n- Before you reach your burst limit, you can increase it.\n\n- To determine if you are near your burst limit, see [View burst limit usage](#view-limit-usage).\n\nView burst limit usage\n----------------------\n\nYou can view your burst limit usage using Google SecOps or Cloud Monitoring.\n\n### Use Google SecOps dashboard to view your burst limits\n\nTo view the limit usage, use the following visualizations in the Google SecOps\n**Data Ingestion and Health** dashboard:\n\n- **Burst Limit Graph - Ingestion Rate**: displays the ingestion rate.\n- **Burst Limit Graph - Quota Limit**: displays the quota limit.\n- **Burst Rejection Graph**: displays the volume of the logs that were rejected due to exceeding the burst limit.\n\nTo view the visualizations, do the following:\n\n1. From the Google SecOps menu, select **Dashboards**.\n2. From the **Default dashboards** section, select **Data Ingestion and Health**.\n\n In the **Data Ingestion and Health** dashboard, you can view the visualizations.\n\n### Use Cloud Monitoring to view burst limits\n\nTo view Google SecOps burst limits in the Google Cloud console, you need\nthe same permissions as for any Google Cloud limit. For more information, see [Grant access to Cloud Monitoring](/monitoring/access-control#grant-monitoring-access).\n\nFor information about how to view metrics using charts, see [Create charts with Metrics Explorer](/monitoring/charts/metrics-explorer).\n\nTo view your burst limit usage, use the following PromQL query: \n\n 100 * sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count\n {monitored_resource=\"chronicle.googleapis.com/Collector\"}[10m]))/min(min_over_time(chronicle_googleapis_com:ingestion_quota_limit{monitored_resource=\"chronicle.googleapis.com/Collector\"}[10m]))\n\nTo view the number of bytes that were rejected after exceeding\nthe burst limit, use the following PromQL query: \n\n sum(rate(chronicle_googleapis_com:ingestion_log_quota_rejected_bytes_count{monitored_resource=\"chronicle.googleapis.com/Collector\"}[15m]))\n\nTo [create an alert](/monitoring/alerts/using-alerting-ui) when the ingested bytes\nexceed 70% of the burst limit, use the following PromQL query: \n\n 100 * sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count\n {monitored_resource=\"chronicle.googleapis.com/Collector\"}[10m]))/\n min(min_over_time(chronicle_googleapis_com:ingestion_quota_limit{monitored_resource=\"chronicle.googleapis.com/Collector\"}[10m])) \u003e 70\n\nBuffer data at ingestion source\n-------------------------------\n\nThe following table describes the configuration needed to buffer (rather than drop) data from your enterprise depending on your ingestion source.\n\nTroubleshooting\n---------------\n\n### Strategies to avoid exceeding limits\n\nThe following guidelines help you avoid exceeding your burst limit:\n\n- Create an ingestion alert that notifies you when the volume of the bytes ingested exceeds the burst limit threshold. For more information about setting up ingestion alerts, see [Using Cloud Monitoring for ingestion notifications](/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics).\n- To identify the ingestion sources and volume, create a monitoring alert with\n `collector_id`, and `log_type` along with the metric `chronicle.googleapis.com/ingestion/log/bytes_count`. To identify the ingestion sources and volume,\n use the following PromQL query:\n\n sum by (collector_id,log_type)(rate(chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource=\"chronicle.googleapis.com/Collector\"}[5m]))\n\n- If you expect your ingestion volume to increase more than four times your normal ingestion\n volume, contact [Google SecOps Technical Support](/chronicle/docs/getting-support)\n ahead of time to increase your burst limit.\n\n- If you use a Google SecOps forwarder to ingest data, you can use\n [disk buffers](/chronicle/docs/install/forwarder-management-configurations#disk-buffering)\n to buffer data when you exceed your burst limit. For more information, see [Using disk buffers for forwarders](#disk-buffers).\n\n### Handle burst limit events\n\nIf you reach the burst limit, take the following actions for your ingestion method:\n\n### Using disk buffers for forwarders\n\nIf you use Google SecOps SIEM forwarder, we recommend that you start\nusing [disk buffers](/chronicle/docs/install/forwarder-management-configurations#disk-buffering)\nto buffer data when you exceed your burst limit. The maximum RAM size used by the collector is 4 GB.\nYou can set this limit using the **max_file_buffer_bytes** setting in the collector\nconfiguration. To buffer data that is more than 4 GB, use disk buffers. To decide the disk buffer size,\nidentify the rate at which forwarders are ingesting by using the following MQL query: \n\n sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count\n {monitored_resource=\"chronicle.googleapis.com/Collector\", collector_id!~ \"\n (aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa\n |bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb\n |cccccccc-cccc-cccc-cccc-cccccccccccc\n |dddddddd-dddd-dddd-dddd-dddddddddddd\n |aaaa2222-aaaa-2222-aaaa-2222aaaa2222)\"}[5m]))\n\nFor example, if the rate of ingestion from the forwarder is 415 Kbps and the buffer\ncompression efficiency is 70%, then the buffer fill-up rate is calculated as\n415 Kbps x (100% - 70%) = 124.5 Kbps. At this rate, a buffer size of 1 GB, which is\nthe default in-memory buffer value, fills up in 2 hours and 20 minutes. The calculation is\n1024 x 1024 / 124.5 = 8422.297 seconds = 2 hours and 20 minutes. If you have exceeded your burst limit,\nyou need a 100 GB disk to buffer data for a day.\n\nFrequently asked questions\n--------------------------\n\n**What error is triggered when you exceed the burst limit?**\n\nWhen you exceed the burst limit, you get the HTTP 429 error.\n\n**How do you resolve the HTTP 429 error?**\n\nRetry the request after five minutes.\n\n**How often are burst limits refreshed?**\n\nBurst limits are refreshed after every five minutes."]]
