了解配额和突发限额

支持的服务：

Google SecOps

注意 ：注入 API 已弃用，将于 2027 年 7 月 20 日停用。如需将日志注入到 Google SecOps，请改用 Chronicle API。如需详细了解如何迁移，请参阅从旧版 SIEM API 迁移到 Chronicle API。

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

突发限额的定义

突发限额是 Google SecOps 中的一种服务限额，充当数据注入的速率限制，旨在保护平台的共享基础架构免受突发的大规模流量高峰的影响。突发限额会限制滚动五分钟窗口内的注入速率（以每秒兆字节 [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 事件中心：这是一种基于拉取的方法，没有日志类型级限制。

突发限额的实现方式

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

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

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

如果您超出突发限额，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 发送大量批次数据。如果可以，请分散历史数据上传。使用数据处理流水线功能过滤掉冗余数据。
• 等待：对于临时高峰，通常只需等待五分钟窗口重置，然后重试即可。

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

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

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

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

常见问题解答

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

我可以提高突发限额吗？

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

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

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

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

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

目前不行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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