Kontingente und Burst-Limits

Unterstützt in:

In diesem Dokument werden Kontingente und Burst-Limits in Google Security Operations beschrieben.

Definition von Burst-Limits

Burst-Limits sind eine Form von Dienstlimits in Google SecOps, die als Geschwindigkeitsbegrenzung für die Datenaufnahme dienen und die gemeinsame Infrastruktur der Plattform vor plötzlichen, massiven Verkehrsspitzen schützen sollen. Ein Burst-Limit beschränkt die Aufnahmerate (gemessen in Megabyte pro Sekunde – MBps oder Gigabyte pro Sekunde – GBps) innerhalb eines gleitenden 5‑Minuten-Zeitraums.

Berechnung von Burst-Limits

In Google SecOps werden Ihren Google SecOps-Tenants Burst-Limits basierend auf dem von Ihnen erworbenen jährlichen Aufnahmevolumen (erworbene Kapazität) gemäß Ihrer Google SecOps-Lizenz zugewiesen.

Um erwartete Schwankungen und ungeplante Spitzen beim Log-Traffic zu berücksichtigen, wird Ihr tägliches Burst-Limit als bestimmter Bereich bereitgestellt. So können Sie zwischen dem Ein- und Dreifachen (1- bis 3-Fache) Ihres erwarteten täglichen Durchschnitts aufnehmen. Dieser wird als Ihre gekaufte Jahreskapazität geteilt durch 365 Tage berechnet. Dieses flexible Volumenkontingent soll Standardspitzen bei der Aufnahme abfangen, ohne Ihren Betrieb zu stören. Wenn Sie beispielsweise eine jährliche Kapazität von 365 TB erworben haben, beträgt der erwartete Tagesdurchschnitt 1 TB. Ihr bereitgestelltes Burst-Limit liegt streng im Bereich von 1 TB bis 3 TB pro Tag (was einem Durchsatzbereich von etwa 12 MB/s bis 36 MB/s entspricht). Wenn Ihre Datenaufnahme diesen bereitgestellten Bereich von 1- bis 3-mal regelmäßig überschreitet, ist eine Erhöhung Ihrer gekauften Jahreskapazität erforderlich.

Burst-Limits werden pro Google SecOps-Kundentenant durchgesetzt.

In der folgenden Tabelle sehen Sie, wie Burst-Limits mit verschiedenen Mengen an gekaufter Kapazität zusammenhängen:

Beispiel für gekaufte Kapazität Bereich für Burst-Limit 5-Minuten-Burst-Limit Aufnahme am maximalen Burst-Limit (stündlich) Aufnahme am maximalen Burst-Limit (täglich) Aufnahme am maximalen Burst-Limit (jährlich)
100 TB 3–10 Mbit/s 0,9 bis 3 GB ~34 GB ~822 GB 300 TB
500 TB 16–48 Mbit/s 4,8–14,4 GB ~171 GB ~4 TB 1,5 PB
1 PB 32–97 Mbit/s 9,6–29 GB ~343 GB ~8 TB 3 PB
5 PB 158–476 Mbit/s 47,4–143 GB ~1,7 TB ~41 TB 15 PB
30 PB 0,96 bis 2,86 GB/s 288–858 GB ~10,3 TB ~247 TB 90 PB

Bei Ingestion-Traffic mit extremen, plötzlichen Geschwindigkeitsspitzen kann es zum Schutz der regionalen Stabilität zu dynamischen Ratenbegrenzungen oder vorübergehenden Drosselungen kommen.

In diesen Zeiträumen kann es zu Verzögerungen bei der Aufnahme von Daten kommen, bis der Anstieg nachlässt.

Informationen zu Anforderungen an den Durchsatz für sehr hohe Durchsätze finden Sie unter Benutzerdefinierte Kapazitätsplanung für sehr hohe Durchsätze.

Anwendbarkeit von Burst-Limits für Pull-basierte Feeds

Google SecOps beschränkt die Pull-basierte Aufnahme außerdem auf ein Drittel (33%) des gesamten Burst-Limits pro Logtyp (für alle Feeds). Dieses Limit soll sicherstellen, dass die Pull-basierte Datenaufnahme (in der Regel aus Cloud-Quellen) die allgemeinen Burst-Limits Ihres Mandanten nicht überschreitet und die Datenerfassung mit Push-basierten Methoden (z. B. mit Bindplane-Agents, Forwardern oder der direkten Datenaufnahme in Google SecOps-APIs) nicht beeinträchtigt.

Pull-basierte Methoden zur Datenaufnahme

Pull-basierte Methoden umfassen Erfassungsmethoden (in Google SecOps als Quelltypen bezeichnet), bei denen Google SecOps aktiv auf die Quell-API zugreift, um Daten abzurufen. Dazu gehören die folgenden Quelltypen, die in Google SecOps unterstützt werden:

  • Drittanbieter-APIs
  • Azure Event Hub
  • Direkte Aufnahme aus Google Workspace und Google Cloud
  • Cloud Storage
  • Cloud Storage-Feed (ereignisgesteuert)
  • Amazon S3
  • Amazon SQS
  • Azure Blobstore
  • SFTP-Anfrage
  • HTTP-Anfrage

Wenn das Burst-Limit für Ihren Mandanten beispielsweise auf 150 MBps festgelegt ist und Ihr Mandant Okta-Nutzerkontextprotokolle über einen API-Connector eines Drittanbieters (d. h. eine Pull-basierte Erfassungsmethode) erfasst, begrenzt das System die Erfassungsrate aller Okta-Feeds zusammen auf maximal [150/3 =] 50 MBps. Dieses zusätzliche Limit wird auch dann angewendet, wenn Ihre gesamte Datenaufnahmerate innerhalb des zugewiesenen Burst-Limits liegt.

Ausnahmen von Limits auf Logtyp-Ebene

Obwohl Grenzwerte auf Protokolltyp-Ebene in der Regel für Pull-basierte Feeds gelten, gibt es die folgenden Ausnahmen:

  • HTTPS-Webhooks: Diese Methode der Datenaufnahme basiert auf Push und unterliegt keinen Beschränkungen auf Logtyp-Ebene. Sie unterliegt jedoch dem allgemeinen Burst-Limit des Kundentenants und gibt einen HTTP 429-Statuscode zurück, wenn ein Feed dieses Limit überschreitet.
  • Azure Event Hub: Dies ist eine Pull-basierte Aufnahmemethode, die keinen Einschränkungen auf Protokolltypebene unterliegt.

So werden Burst-Limits implementiert

Das System erzwingt Burst-Limits in Fünf-Minuten-Intervallen. Wenn Ihr Burst-Limit beispielsweise auf 50 MB/s festgelegt ist, können Sie alle fünf Minuten bis zu 15 GB aufnehmen. Wenn Sie alle 15 GB in den ersten zwei Minuten aufnehmen, wird die Aufnahme für die verbleibenden drei Minuten dieses Zeitfensters blockiert. Dieses Limit wird zu Beginn des nächsten 5‑Minuten-Intervalls automatisch zurückgesetzt.

Grenzwerte auf Logtyp-Ebene werden auf dieselbe Weise erzwungen, gelten aber auf der Ebene einzelner Logtypen. Wenn Ihnen beispielsweise alle fünf Minuten 5 GB für Pull-basierte Feeds zugewiesen werden und das gesamte aufgenommene Datenvolumen für einen einzelnen Logtyp in den ersten zwei Minuten 5 GB überschreitet, wird die Aufnahme für die verbleibenden drei Minuten dieses Zeitfensters pausiert. Das Limit wird zu Beginn des nächsten 5‑Minuten-Intervalls automatisch zurückgesetzt.

Was passiert mit Ihren Daten, wenn Sie Ihre Burst-Limits überschreiten?

Wenn Sie Ihr Burst-Limit überschreiten, pausiert Google SecOps die Aufnahme zusätzlicher Daten. Je nachdem, ob Ihre Daten mit Pull- oder Push-Methoden aufgenommen werden, werden die folgenden Mechanismen ausgelöst:

  • Pullbasierte Methoden verwenden: Die Aufnahme wird automatisch gepuffert und erfordert keine zusätzliche Konfiguration durch Sie als Kunden. Die Daten bleiben im Pufferspeicher, bis das Limit zurückgesetzt wird und Google SecOps die Datenaufnahme fortsetzt.
  • Push-basierte Methoden verwenden: Google SecOps lehnt die Datenaufnahme vorübergehend mit dem HTTP-Fehler 429 „Too Many Requests“ (Zu viele Anfragen) ab. Dadurch wird der Aufnahmemechanismus angewiesen, die Daten zu pausieren, zu puffern und noch einmal zu versuchen, damit keine Daten verloren gehen.

Bei Push-basierten Erfassungsmethoden liegt die Verantwortung für das Puffern und Wiederholen bei Ihnen, dem Kunden (siehe Verantwortlichkeiten des Kunden für das Puffern und Wiederholen von Daten).

Abgelehnte Burst-Anfragen führen nicht zu Datenverlust

Es ist wichtig zu wissen, dass Ablehnungen aufgrund von Burst-Limits (HTTP 429) keine Datenverlustereignisse sind. Eine Ablehnung aufgrund eines Burst-Limits (HTTP-Fehler 429) führt zu einer Pause bei der Datenaufnahme.

Wenn Sie dafür sorgen, dass Ihre Push-basierten Systeme über ausreichend Festplattenpufferung und Wiederholungslogik verfügen, führt das Erreichen eines Burst-Limits nur zu einer geringen Verzögerung (Erfassungsverzögerung), aber niemals zum dauerhaften Verlust von Sicherheitstelemetrie.

Datenverlust tritt nur auf, wenn das sendende System (z. B. der Bindplane-Agent, der Forwarder oder das Skript) den Fehler „Burst limit rejection“ ignoriert und den Logeintrag löscht, anstatt ihn für einen erneuten Versuch zu speichern.

Verantwortlichkeiten des Kunden für das Zwischenspeichern von Daten und Wiederholungsversuche

Obwohl Google SecOps die Datenpufferung und Wiederholungsversuche für Daten, die mit pullbasierten Erfassungsmethoden aufgenommen werden, automatisch verwaltet, sind Sie für die Datenpufferung und Wiederholungsversuche bei der Datenerfassung mit pushbasierten Erfassungsmethoden (z. B. HTTPS-Webhooks, Bindplane, Forwarder oder Cribl) verantwortlich.

Sie müssen Ihre Systeme so konfigurieren, dass Daten automatisch gepuffert und noch einmal gesendet werden, wenn das Burst-Limit erreicht ist, um Datenüberlauf effizient zu verarbeiten.

In der folgenden Tabelle sind die wichtigsten Unterschiede bei der Datenaufnahme durch Google SecOps zusammengefasst, wenn das Burst-Limit für beide Arten von Aufnahmemethoden erreicht ist:

Funktion Pull-basierte Aufnahme Push-basierte Aufnahme
Funktionsweise Google SecOps greift aktiv auf die Quell-API zu, um Daten abzurufen. Ihre Systeme stellen die Verbindung her und senden Daten an Google.
Verantwortung für das Puffern von Daten und Wiederholungsversuche Google SecOps verwaltet das Buffering automatisch. Wenn das Burst-Limit erreicht ist, pausiert Google SecOps die Aufnahme zusätzlicher Daten. Die Daten werden im Pufferspeicher gespeichert, bis das Limit zurückgesetzt wird und Google SecOps wieder Daten abruft.
Im Pufferspeicher werden Daten nur bis zu 90 Tage lang gespeichert. Danach werden sie gelöscht.		 Der Kunde muss das Puffern verwalten. Wenn Google SecOps mit HTTP 429 antwortet, muss Ihr Sendesystem diesen Fehler abfangen, die Daten in einer lokalen Warteschlange (Festplatte oder Arbeitsspeicher) speichern und den Sendevorgang später noch einmal versuchen. Wenn der Absender auf „drop on failure“ (bei Fehler verwerfen) eingestellt ist, gehen Daten verloren.
Typen von Datenquellen Drittanbieter-API, Azure Event Hub, direkte Aufnahme aus Google Workspace und Google Cloud, Cloud Storage, Cloud Storage-Feed (ereignisgesteuert), Amazon S3, Amazon SQS, Azure Blobstore, SFTP-Anfrage, HTTP-Anfrage. Google SecOps Forwarder, Bindplane-Agent, Pub/Sub, Amazon Kinesis Firehose, HTTPS-Webhook, direkt an die Ingestion API.
Nutzeraktion Sorgen Sie dafür, dass das Volumen der Datenaufnahme mit der von Ihnen erworbenen Kapazität übereinstimmt. Außerdem müssen Ihre Erfassungsquellen für die Datenaufbewahrung, das Puffern und das Wiederholen konfiguriert sein.
Weitere Informationen finden Sie unter Pufferungs- und Wiederholungskonfigurationen für Push-basierte Systeme.

Wann werden gepufferte Daten für Pull-basierte Feeds nachgetragen?

Bei Feeds, für die Pull-basierte Erfassungsmethoden verwendet werden, füllt Google SecOps nach dem Zurücksetzen des Zeitraums für das Burst-Limit gepufferte Daten nach. Dabei werden Live-Daten gegenüber gepufferten Daten priorisiert. Dieser Mechanismus sorgt dafür, dass Ihr Backlog an gepufferten Daten nicht mit Ihrem eingehenden Live-Datenverkehr interferiert, was zu zusätzlichen Verzögerungen bei der Erkennung führen kann.

Zugewiesenes Burst-Limit ansehen

So ermitteln Sie das Ihrem Google SecOps-Mandanten zugewiesene Burst-Limit:

  1. Rufen Sie in der Google SecOps Console Dashboards > Data Ingestion and Health auf.
  2. Diagramm für das Burst-Limit – Kontingentlimit Im Diagramm wird das zugewiesene Limit (die horizontale Linie) im Verhältnis zur tatsächlichen Aufnahmerate dargestellt.

Prüfen, ob Sie sich dem Burst-Limit nähern oder es überschreiten

Sie können die Nutzung mit den integrierten Dashboards oder mit Cloud Monitoring verfolgen.

Mit Google SecOps-Dashboards können Sie nachvollziehen, ob Sie sich Ihrem Burst-Limit nähern oder es überschreiten.

  • Rufen Sie Dashboards > Data Ingestion and Health auf und sehen Sie sich Folgendes an:

    • Diagramm zur Erfassungsrate: Hier sehen Sie Ihren aktuellen Durchsatz.
    • Diagramm zu Ablehnungen aufgrund von Stoßverkehr: Hier sehen Sie das Volumen der aufgrund von Überschreitung des Stoßverkehrlimits abgelehnten Logs (HTTP 429-Fehler).

Mit Cloud Monitoring prüfen, ob Sie sich Ihrem Burst-Limit nähern oder es überschreiten

Mit dem Metrics Explorer in Google Cloud können Sie benutzerdefinierte Benachrichtigungen erstellen. Wir empfehlen, eine Erfassungsbenachrichtigung zu erstellen, die Sie benachrichtigt, wenn das Volumen der erfassten Byte den Grenzwert für das Burst-Limit überschreitet.

Zu den relevanten Messwerten gehören:

  • Aufgenommene Menge: chronicle.googleapis.com/ingestion/log/bytes_count
  • Abgelehnte Datenmenge: `chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

Standardmäßige Benachrichtigungsrichtlinien

Google SecOps bietet sofort einsatzbereite Benachrichtigungsrichtlinien in Cloud Monitoring, die Sie aktivieren können, um Ihr Aufnahmekontingent zu überwachen.

So finden und aktivieren Sie diese Richtlinien:

  1. Rufen Sie in der Google Cloud Console Monitoring > Integrationen auf.
  2. Wählen Sie Chronicle Security aus der Liste der Integrationen aus.
  3. Klicken Sie auf den Tab Benachrichtigungen.
  4. Prüfen und aktivieren Sie die folgenden Beispielbenachrichtigungsrichtlinien:
    • Benachrichtigungsrichtlinie für das Erreichen des Kontingentlimits für die Aufnahme: Erkennt, ob sich das Volumen der Datenaufnahme dem Kontingentlimit nähert.
    • Benachrichtigungsrichtlinie für Ablehnung des Aufnahmekontingents: Erkennt, ob Aufnahmeanfragen aufgrund eines unzureichenden Aufnahmekontingents abgelehnt werden (HTTP 429-Fehler).

Beispiele

Die folgenden Abschnitte enthalten Beispiel-PromQL-Abfragen für Monitoring und Benachrichtigungen.

Nutzung des Burst-Limits ansehen

  • Verwenden Sie die folgende PromQL-Abfrage, um die Nutzung Ihres Burst-Limits aufzurufen:

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

Anzahl der Byte ansehen, die nach Überschreiten des Burst-Limits abgelehnt wurden

  • Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Byte zu sehen, die nach Überschreiten des Burst-Limits abgelehnt wurden:

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

Benachrichtigung auslösen, wenn 70% des Burst-Limits erreicht sind

  • Verwenden Sie die folgende PromQL-Abfrage, um eine Benachrichtigung auszulösen, wenn Sie 70% Ihres Burst-Limits erreicht haben:

    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

Weitere Informationen zum Einrichten von Aufnahmebenachrichtigungen finden Sie unter Cloud Monitoring für Aufnahme verwenden.

Ablehnungen aufgrund von Burst-Limits bei Push-basierten Methoden verarbeiten

Wenn Sie aufgrund des Erreichens des Burst-Limits für eingehende Daten mit Push-basierten Methoden Ablehnungsfehler (HTTP 429) erhalten, empfehlen wir Ihnen, die folgenden Schritte auszuführen:

  • Pufferung prüfen: Achten Sie darauf, dass Ihre Erfassungsquellen Daten puffern und es noch einmal versuchen.
  • Aufnahme optimieren: Überprüfen Sie die Aufnahmeskripts und achten Sie darauf, dass keine unnötigen Daten gesendet werden oder die API durch massive Batches auf einmal überlastet wird. Verlaufsdatenuploads nach Möglichkeit aufteilen Mit der Datenverarbeitungs-Pipeline können Sie redundante Daten herausfiltern.
  • Warten: Bei vorübergehenden Spitzen reicht es oft aus, zu warten, bis das Fünf-Minuten-Zeitfenster zurückgesetzt wird, und es dann noch einmal zu versuchen.

Beispielkonfigurationen finden Sie unter Konfigurationen für Pufferung und Wiederholung für Push-basierte Systeme.

Benutzerdefinierte Kapazitätsplanung für extrem hohen Durchsatz

Ungeachtet der in den anderen Abschnitten dieses Dokuments beschriebenen Aspekte gilt ein Datenerfassungsdurchsatz von mehr als 3 GBps als sehr hoher Durchsatz. Wenn Sie umfangreiche Datenmigrationen planen, einen dauerhaft extrem hohen Durchsatz erwarten oder Architekturen ausführen, die regelmäßig massive Ingest-Spitzen erzeugen, müssen Sie sich an Ihr Account-Management-Team wenden, um eine benutzerdefinierte Kapazitätsbereitstellung zu vereinbaren.

Da die Bereitstellung einer dedizierten regionalen Kapazitätserweiterung mehrere Wochen dauern kann, benachrichtigen Sie den Google Cloud Support bitte mindestens 90 Tage vor erwarteten extremen Aufnahmeereignissen, damit Ihre Durchsatzanforderungen erfüllt werden können.

Häufig gestellte Fragen

In den folgenden Abschnitten finden Sie Antworten auf häufig gestellte Fragen.

Kann ich das Burst-Limit erhöhen?

Wenn Sie davon ausgehen, dass das Volumen der Datenaufnahme dauerhaft zunimmt, können Sie die gekaufte Kapazität erhöhen. Wenden Sie sich dazu an Ihren Google SecOps-Vertriebsmitarbeiter.

Kann ich die Grenzwerte für die Protokollierungsebene für Pull-basierte Feeds erhöhen?

Sie können Ihre Grenzwerte auf Logtyp-Ebene für einen bestimmten Logtyp erhöhen, indem Sie im Voraus eine Anfrage über den technischen Support von Google SecOps stellen.

Wenn Sie das Limit auf Protokolltyp-Ebene für einen Protokolltyp erhöhen, ändert sich dadurch nicht das Limit für andere Protokolltypen oder Ihr allgemeines Burst-Limit.

Kann ich meinen Datenrückstand nachverfolgen?

Derzeit nicht.

Welche Möglichkeiten gibt es, meinen Datenrückstand zu beseitigen?

Wenn Sie einen sehr großen Datenrückstand haben und diesen löschen möchten, um Ihr Kontingent für das Burst-Limit freizugeben, können Sie Folgendes tun:

  • Sie können zusätzliche Kapazität erwerben, um Ihre Limits zu erhöhen.
  • Deaktivieren Sie bestimmte Feeds, bei denen das Volumen unerwartet gestiegen ist.

  • Fordern Sie technischen Support für Google SecOps an, um den Rückstand zu reduzieren.

    Wenn Sie Ihren Rückstand aufholen möchten, wird Ihr Datenfeed vorübergehend deaktiviert, bis alle Wiederholungsanfragen für nachgefüllte Daten erfolgreich verarbeitet wurden. Während dieser Zeit können Sie keine neuen Daten aufnehmen.

    Sobald der Rückstand aufgeholt ist, wird Ihr Feed wieder aktiviert und Sie sehen neue Daten. Je nach Größe des Backlogs kann dies einige Minuten bis einige Stunden dauern.

Gelten Burst-Limits auch für die Datenaufnahme in die Datenverarbeitungs-Pipeline?

Die Ratenlimits für die Aufnahme von Daten, die für Datenfeeds gelten, mit denen Rohlogdaten in die Datenverarbeitungs-Pipeline von Google SecOps gesendet werden, sind höher als das Burst-Limit Ihres Mandanten.

Wenn Sie Ihr Burst-Limit überschreiten, werden in der Datenverarbeitungs-Pipeline keine zusätzlichen Anfragen mehr akzeptiert. Das funktioniert so:

  • Pull-basierte Methoden verwenden: Die Aufnahme wird automatisch gepuffert und erfordert keine zusätzliche Konfiguration.
  • Push-basierte Methoden verwenden: Google SecOps lehnt die Daten vorübergehend mit dem HTTP-Fehler 429 „Zu viele Anfragen“ ab.

Alle Daten, die nach dem Auslösen des Burst-Limits transformiert wurden, werden vorübergehend in einer internen Warteschlange gepuffert, bis das Limit im nachfolgenden 5‑Minuten-Zeitraum zurückgesetzt wird.

Was kann ich tun, wenn mein Burst-Limit niedriger ist als vertraglich vereinbart?

Wenn Ihr Burst-Limit niedriger ist als das, was Sie vertraglich vereinbart haben, wenden Sie sich an den Google-Support (siehe Google SecOps-Support) und geben Sie Ihr erwartetes Burst-Limit an.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten