了解配额和突发限制

支持的服务：

Google SecOps

本文档介绍了 Google Security Operations 中的配额和突发限制。

突发限制的定义

突发限制是 Google SecOps 中的一种服务限制，充当数据注入的速率限制，旨在保护平台的共享基础架构免受突发流量峰值的冲击。突发限制会限制滚动 5 分钟窗口内注入速率（以每秒兆字节 [MBps] 或每秒千兆字节 [GBps] 为单位）。

**注意**： 如需了解服务和其他术语的定义，请参阅SecOps 服务专用条款。

突发限制的计算方式

Google SecOps 会根据您的 Google SecOps 许可，基于您购买的年度注入量（购买的容量）为您的 Google SecOps 租户分配突发限制。

为了应对日志流量的预期变化和意外峰值，您的每日突发限制将预配为特定范围，让您可以注入的量介于预期每日平均值（计算方式为购买的年度容量除以 365 天）的 1 倍到 3 倍之间。这种灵活的容量配额旨在吸收标准注入峰值，而不会中断您的运营。例如，如果您购买的年度容量为 365 TB，则预期每日平均值为 1 TB。预配的突发限制将严格控制在每天 1 TB 到 3 TB 的范围内（这相当于大约 12 MBps 到 36 MBps 的吞吐量范围）。如果您的数据注入量始终超出此预配的 1 倍到 3 倍范围，则需要增加购买的年度容量。

突发限制是针对每个 Google SecOps 客户租户强制执行的。

下表显示了突发限制与不同购买容量之间的对应关系：

购买的容量示例	突发限制范围	5 分钟突发限制	最大突发限制下的注入量（每小时）	最大突发限制下的注入量（每天）	最大突发限制下的注入量（每年）
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

注意： 每日容量配额仍受区域中的物理吞吐量限制。虽然 Google SecOps 允许每日容量突发量达到 3 倍的限制，但系统会主动管理瞬时数据传输速率（吞吐量），以提供高可用性并防止共享区域环境中的资源不足。

如果注入流量包含极端、突然的速度峰值，则可能会受到动态速率限制或临时限制，以保护区域稳定性。

在此期间，数据可能会出现注入延迟，直到峰值消退。

如需了解超高吞吐量要求，请参阅针对超高吞吐量的自定义容量规划。

突发限制对基于拉取的数据 Feed 的适用性

Google SecOps 还将基于拉取的注入限制为每个日志类型（跨所有 Feed）的总体突发限制的三分之一 (33%)。此限制旨在确保基于拉取的注入（通常来自云来源）不会耗尽租户的总体突发限制，也不会导致使用基于推送的方法（例如使用 Bindplane 代理、转发器或直接注入到 Google SecOps API）的数据注入不足。

基于拉取的注入方法

基于拉取的方法包括注入方法（在 Google SecOps 中称为来源类型），其中 Google SecOps 会主动访问来源 API 以提取数据。 这包括 Google SecOps 支持的以下来源类型：

• 第三方 API
• Azure 事件中心
• 直接从 Google Workspace 和 Google Cloud
• Cloud Storage 注入
• Cloud Storage Feed（事件驱动型）
• Amazon S3
• Amazon SQS
• Azure Blobstore
• SFTP 请求
• HTTP 请求

例如，如果您的租户的突发限制设置为 150 MBps，并且您的租户使用第三方 API 连接器（即基于拉取的注入方法）注入 Okta 用户上下文日志，则系统会将所有 Okta Feed 的总注入速率限制为最多 [150/3 =] 50 MBps。即使您的总体数据注入速率在分配的突发限制范围内，也会应用此额外限制。

基于拉取的注入方法的日志类型级限制的例外情况

虽然日志类型级限制通常适用于基于拉取的数据 Feed，但以下例外情况适用：

• HTTPS Webhook：这是一种基于推送的方法，具有日志类型级限制。
• Azure 事件中心：这是一种基于拉取的方法，没有日志类型级限制。

突发限制的实现方式

系统会以 5 分钟为间隔强制执行突发限制。例如，如果您的突发限制设置为 50 MBps，则每 5 分钟最多可以注入 15 GB。如果您在前 2 分钟内注入了所有 15 GB，则在该窗口的剩余 3 分钟内，注入将被阻止。此限制会在下一个 5 分钟间隔开始时自动重置。

日志类型级限制的强制执行方式相同，但适用于各个日志类型级别。例如，如果您每 5 分钟分配了 5 GB 的基于拉取的数据 Feed，并且在任何单个日志类型的前 2 分钟内注入的总数据量超过 5 GB，则在该窗口的剩余 3 分钟内，注入将暂停。此限制会在下一个 5 分钟间隔开始时自动重置。

超出突发限制后，您的数据会发生什么情况

如果您超出突发限制，Google SecOps 会暂停注入其他数据，并触发以下机制，具体取决于您的数据是使用基于拉取的方法还是基于推送的方法注入：

• 使用基于拉取的方法：注入会自动缓冲，无需您（客户）进行额外配置。数据将保留在缓冲存储空间中，直到限制重置且 Google SecOps 恢复数据注入。
• 使用基于推送的方法：Google SecOps 会暂时拒绝数据注入，并显示 HTTP 429“请求过多”错误。这会向您的注入机制发出信号，以暂停、缓冲和重试，确保不会丢失任何数据。

使用基于推送的注入方法时，缓冲和重试的责任在于您（客户）（请参阅客户在数据缓冲和重试方面的责任）。

突发限制拒绝不是数据丢失

务必了解，突发限制拒绝 (HTTP 429) 不是数据丢失事件。 突发限制拒绝（HTTP 429 错误）是指数据注入暂停。

通过确保基于推送的系统具有足够的磁盘缓冲和重试逻辑，达到突发限制只会导致少量延迟（注入延迟），而绝不会导致安全遥测数据永久丢失。

只有当发送系统（例如 Bindplane 代理、转发器或脚本）忽略突发限制拒绝错误并删除日志条目而不是存储该条目以进行重试时，才会发生数据丢失。

客户在数据缓冲和重试方面的责任

虽然 Google SecOps 会自动管理使用基于拉取的注入方法注入的数据的缓冲和重试，但您负责使用基于推送的注入方法（例如 HTTPS Webhook、Bindplane、转发器或 Cribl）数据注入的缓冲和重试。

注意 ：转发器已弃用。转发器组件将逐步从 Google SecOps 平台中淘汰，并于 2027 年 1 月终止服务 (EOL)。2026 年 4 月 1 日：新的 Google SecOps 客户无法使用转发器组件。2027 年 1 月 1 日：转发器正式终止服务。系统将不再发布任何补丁，包括安全补丁。2027 年 4 月 1 日：系统不再允许从转发器组件注入数据。 Google 建议使用 Bindplane for Google SecOps 作为日志收集的主要解决方案。如需了解详情，请参阅 将 Bindplane 与 Google SecOps 搭配使用。

您需要将系统配置为在达到突发限制时自动缓冲和重新发送数据，以便高效处理数据溢出。

下表重点介绍了当达到突发限制时，Google SecOps 如何处理这两种注入方法的数据注入：

功能	基于拉取的注入	基于推送的注入
运作方式	Google SecOps 会主动访问来源 API 以提取数据。	您的系统会发起连接并将数据发送给 Google。
数据缓冲和重试的责任	Google SecOps 会自动管理缓冲。达到突发限制后，Google SecOps 会暂停注入其他数据。数据将保留在缓冲存储空间中，直到限制重置且 Google SecOps 恢复提取。 缓冲存储空间最多只能存储 90 天的数据，之后数据将被丢弃。	客户必须管理缓冲。当 Google SecOps 回复 HTTP 429 时，您的发送系统必须捕获此错误，将数据保存到本地队列（磁盘或内存），并在稍后重试发送。如果您的发送方设置为“失败时丢弃”，则数据将会丢失。
数据源类型	第三方 API、Azure 事件中心、直接从 Google Workspace 和 Google Cloud注入、Cloud Storage Feed（事件驱动型）、Amazon S3、Amazon SQS、Azure Blobstore、SFTP 请求、HTTP 请求。	Google SecOps 转发器、Bindplane 代理、Pub/Sub、Amazon Kinesis Firehose、HTTPS Webhook、直接注入到注入 API。
用户操作	采取措施，使数据注入量与购买的容量保持一致。	此外，请确保您的注入来源已配置为数据保留、缓冲和重试。 如需了解详情，请参阅基于推送的系统的缓冲和重试配置。

基于拉取的数据 Feed 的缓冲数据何时回填

对于使用基于拉取的注入方法的 Feed，当突发限制窗口重置时，Google SecOps 会回填缓冲数据，并优先处理实时数据而非缓冲数据。此机制可确保缓冲数据的积压不会干扰传入的实时数据流量（这可能会导致检测延迟）。

注意： 在回填缓冲数据期间，您可能会观察到缓冲数据与实时数据并行流动。

如何查看分配的突发限制

如需确定分配给您的 Google SecOps 租户的突发限制，请执行以下操作：

1. 在 Google SecOps 控制台中，依次前往信息中心 > 数据注入和健康状况 。
2. 查看突发限制图表 - 配额限制 。该图表会显示分配的限制（平线）相对于实际注入速率。

跟踪是否接近或超出突发限制

您可以使用内置信息中心或 Cloud Monitoring 跟踪使用情况。

使用 Google SecOps 信息中心跟踪是否接近或超出突发限制

• 依次前往信息中心 > 数据注入和健康状况 ，然后查看以下内容：

  • 注入速率图表：显示当前吞吐量。
  • 突发拒绝图表：显示因超出突发限制而被拒绝的日志量（HTTP 429 错误）。

使用 Cloud Monitoring 跟踪是否接近或超出突发限制

您可以使用 Metrics Explorer 在 Google Cloud 创建自定义提醒。我们建议您创建一个注入提醒，以便在注入的字节数超出突发限制阈值时收到通知。

相关指标包括：

• 注入量: chronicle.googleapis.com/ingestion/log/bytes_count
• 拒绝量：`chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

开箱即用的提醒政策

Google SecOps 在 Cloud Monitoring 中提供了开箱即用的提醒政策，您可以启用这些政策来监控注入配额。

如需查找并启用这些政策，请执行以下步骤：

1. 在 Google Cloud 控制台中，依次前往 Monitoring > 集成。
2. 从集成列表中选择 Chronicle Security 。
3. 点击提醒 标签页。
4. 查看并启用以下示例提醒政策：
   • 注入配额限制接近提醒政策：检测数据注入量是否接近配额限制。
   • 注入配额拒绝提醒政策：检测是否因注入配额不足（HTTP 429 错误）而拒绝注入请求。

示例

以下部分包含用于监控和提醒的 PromQL 查询示例。

查看突发限制使用情况

• 如需查看突发限制使用情况，请使用以下 PromQL 查询：

  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]))

查看超出突发限制后被拒绝的字节数

• 如需查看超出突发限制后被拒绝的字节数，请使用以下 PromQL 查询：

  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% 时触发提醒

• 如需在达到突发限制的 70% 时触发提醒，请使用以下 PromQL 查询：

  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

注意： 确切的查询语法可能会因您的特定受监控的资源配置而异。

如需详细了解如何设置注入提醒，请参阅 使用 Cloud Monitoring 进行注入以获取注入洞见。

处理由基于推送的方法导致的突发限制拒绝

如果您因使用基于推送的方法注入传入数据而达到突发限制，并遇到拒绝错误 (HTTP 429)，我们建议您采取以下步骤：

• 验证缓冲：确保您的注入来源正在缓冲数据并重试。
• 优化注入：查看注入脚本，确保它们不会发送不必要的数据，也不会一次性向 API 发送大量批次。如果可以，请分散历史数据上传。使用数据处理流水线功能过滤掉冗余数据。
• 等待：对于临时峰值，通常只需等待 5 分钟窗口重置，然后重试即可。

如需查看一些示例配置，请参阅基于推送的系统的缓冲和重试配置。

针对超高吞吐量的自定义容量规划

无论本文档其他部分描述了什么，超过 3 GBps 的数据注入吞吐量都被视为超高吞吐量。 如果您计划进行大规模数据迁移、预计持续超高吞吐量，或者运行始终生成大量注入爆发期的架构，则必须与您的客户支持团队联系以进行自定义容量预配。

由于专用区域容量扩容可能需要数周时间才能部署，因此请至少提前 90 天将预计的极端注入事件通知 Google Cloud 支持团队，以确保满足您的吞吐量要求。

常见问题解答

以下部分提供了常见问题的解答。

我可以提高突发限制吗？

如果您预计数据注入量会永久增加，可以与您的 Google SecOps 销售代表联系，以增加购买的容量。

我可以提高基于拉取的数据 Feed 的日志类型级限制吗？

您可以提前使用 Google SecOps 技术支持提出请求，以提高特定日志类型的日志类型级限制。

提高一个日志类型的日志类型级限制不会改变应用于其他日志类型的限制或总体突发限制。

是否可以跟踪我的数据积压？

目前不行。

有哪些方法可以清除我的数据积压？

如果您积累了大量数据积压，并且想要清除这些积压以释放突发限制配额，可以执行以下操作：

• 购买额外容量以提高限制。
• 停用特定 Feed，这些 Feed 的量意外飙升。

• 请求 Google SecOps 技术支持丢弃您的积压。

  如需丢弃积压，您的数据 Feed 将暂时停用，直到成功处理所有回填数据的重试请求。在此期间，您将无法注入任何新数据。

  清除积压后，您的 Feed 将重新启用，届时您将看到新数据流入。根据积压的大小，这可能需要几分钟到几小时不等。

突发限制是否也适用于注入到数据处理流水线的数据？

适用于将原始日志数据发送到 Google SecOps 数据处理流水线的数据 Feed 的注入速率限制将设置为高于租户的突发限制。

如果您超出突发限制，数据处理流水线将停止接受其他请求，具体如下：

• 使用基于拉取的方法：注入会自动缓冲，无需进行额外配置。
• 使用基于推送的方法：Google SecOps 会暂时拒绝数据，并显示 HTTP 429“请求过多”错误。

在触发突发限制后转换的任何数据都会暂时缓冲在内部队列中，直到在后续 5 分钟窗口中重置限制。

如果我的突发限制低于我签订的合同中的限制，该怎么办？

如果您的突发限制低于您签订的合同中的限制，请与 Google 支持团队联系（请参阅 Google SecOps 支持团队），并提供您预期的突发限制。

需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。