Informationen zu Kontingenten und Burst-Limits

Unterstützt in:

Google SecOps

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. Sie sollen die gemeinsame Infrastruktur der Plattform vor plötzlichen, massiven Trafficspitzen schützen. Ein Burst-Limit beschränkt die Aufnahmerate (gemessen in Megabyte pro Sekunde – MB/s oder Gigabyte pro Sekunde – GB/s) innerhalb eines gleitenden 5-Minuten-Fensters.

Berechnung von Burst-Limits

Google SecOps weist Ihren Google SecOps-Mandanten Burst-Limits basierend auf dem von Ihnen erworbenen jährlichen Aufnahmevolumen (erworbene Kapazität) gemäß Ihrer Google SecOps-Lizenz zu.

Um erwarteten Schwankungen und ungeplanten Spitzen im Log-Traffic Rechnung zu tragen, wird Ihr tägliches Burst-Limit als bestimmter Bereich bereitgestellt. So können Sie das ein- bis dreifache (1× bis 3×) Ihres erwarteten täglichen Durchschnitts aufnehmen (berechnet als Ihre erworbene jährliche Kapazität geteilt durch 365 Tage). Diese flexible Volumenzulage soll Standardspitzen bei der Aufnahme abfangen, ohne Ihren Betrieb zu stören. Wenn Ihre erworbene jährliche Kapazität beispielsweise 365 TB beträgt, liegt Ihr erwarteter täglicher Durchschnitt bei 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× konstant überschreitet, muss Ihre erworbene jährliche Kapazität erhöht werden.

Burst-Limits werden pro Google SecOps-Kundenmandant erzwungen.

In der folgenden Tabelle sehen Sie, wie Burst-Limits verschiedenen Mengen an erworbener Kapazität entsprechen:

Beispiel für erworbene Kapazität	Bereich für Burst-Limit	5-Minuten-Burst-Limit	Aufnahme bei maximalem Burst-Limit (pro Stunde)	Aufnahme bei maximalem Burst-Limit (pro Tag)	Aufnahme bei maximalem Burst-Limit (pro Jahr)
100 TB	3–10 MB/s	0,9–3 GB	~34 GB	~822 GB	300 TB
500 TB	16–48 MB/s	4,8–14,4 GB	~171 GB	~4 TB	1,5 PB
1 PB	32–97 MB/s	9,6–29 GB	~343 GB	~8 TB	3 PB
5 PB	158–476 MB/s	47,4–143 GB	~1,7 TB	~41 TB	15 PB
30 PB	0,96–2,86 GB/s	288–858 GB	~10,3 TB	~247 TB	90 PB

Bei Aufnahmetraffic mit extremen, plötzlichen Geschwindigkeitsspitzen kann eine dynamische Ratenbegrenzung oder eine vorübergehende Drosselung angewendet werden, um die regionale Stabilität zu schützen.

In diesen Zeiträumen kann es zu Verzögerungen bei der Aufnahme von Daten kommen, bis die Spitze abklingt.

Informationen zu Anforderungen an einen extrem hohen Durchsatz finden Sie unter Benutzerdefinierte Kapazitätsplanung für extrem hohen Durchsatz.

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

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

Pull-basierte Aufnahmemethoden

Zu den Pull-basierten Methoden gehören Aufnahmemethoden (in Google SecOps als Quelltypen bezeichnet), bei denen Google SecOps aktiv die Quell-API kontaktiert, 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 MB/s festgelegt ist und Ihr Mandant Okta-Nutzerkontextlogs mit einem Drittanbieter-API-Connector aufnimmt (eine Pull-basierte Aufnahmemethode), beschränkt das System die Aufnahmerate aller Okta-Feeds zusammen auf maximal [150/3 =] 50 MB/s. Dieses zusätzliche Limit wird auch dann angewendet, wenn Ihre gesamte Datenaufnahmerate innerhalb des zugewiesenen Burst-Limits liegt.

Ausnahmen von Limits auf Logtype-Ebene für Pull-basierte Aufnahmemethoden

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

HTTPS-Webhooks: Dies ist eine Push-basierte Methode mit Limits auf Logtype-Ebene.
Azure Event Hub: Dies ist eine Pull-basierte Methode ohne Limits auf Logtype-Ebene.

Implementierung von Burst-Limits

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

Limits auf Logtype-Ebene werden auf dieselbe Weise erzwungen, gelten aber auf der Ebene einzelner Logtypen. Wenn Ihnen beispielsweise alle 5 Minuten 5 GB für Pull-basierte Feeds zugewiesen werden und Ihr gesamtes aufgenommenes Datenvolumen für einen einzelnen Logtyp in den ersten 2 Minuten 5 GB überschreitet, wird die Aufnahme für die restlichen 3 Minuten dieses Fensters 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 und die folgenden Mechanismen werden ausgelöst. Das hängt davon ab, ob Ihre Daten mit Pull-basierten oder Push-basierten Methoden aufgenommen werden:

Pull-basierte Methoden: 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: Google SecOps lehnt die Datenaufnahme vorübergehend mit dem HTTP-Fehler 429 „Too Many Requests“ ab. Dadurch wird Ihr Aufnahmemechanismus angewiesen, die Aufnahme zu pausieren, zu puffern und noch einmal zu versuchen, damit keine Daten verloren gehen.

Bei Push-basierten Aufnahmemethoden liegt die Verantwortung für das Puffern und Wiederholen beim Kunden (siehe Kundenverantwortlichkeiten für das Puffern und Wiederholen von Daten).

Ablehnungen aufgrund von Burst-Limits führen nicht zu Datenverlust

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

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

Datenverlust tritt nur auf, wenn das sendende System (z. B. der Bindplane-Agent, der Weiterleiter oder das Skript) den Fehler aufgrund der Ablehnung aufgrund von Burst-Limits ignoriert und den Logeintrag löscht, anstatt ihn für einen Wiederholungsversuch zu speichern.

Kundenverantwortlichkeiten für das Puffern und Wiederholen von Daten

Obwohl Google SecOps das Puffern und Wiederholen von Daten, die mit Pull-basierten Aufnahmemethoden aufgenommen werden, automatisch verwaltet, sind Sie für das Puffern und Wiederholen der Datenaufnahme mit Push-basierten Aufnahmemethoden (z. B. HTTPS-Webhooks, Bindplane, Weiterleiter oder Cribl) verantwortlich.

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

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

Funktion	Pull-basierte Aufnahme	Push-basierte Aufnahme
Funktionsweise	Google SecOps kontaktiert aktiv die Quell-API, um Daten abzurufen.	Ihre Systeme initiieren die Verbindung und senden Daten an Google.
Verantwortung für das Puffern und Wiederholen von Daten	Google SecOps verwaltet das Puffern automatisch. Wenn das Burst-Limit erreicht ist, pausiert Google SecOps die Aufnahme zusätzlicher Daten. Die Daten bleiben im Pufferspeicher, bis das Limit zurückgesetzt wird und Google SecOps den Abruf fortsetzt. 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 sendendes System diesen Fehler abfangen, die Daten in einer lokalen Warteschlange (Festplatte oder Arbeitsspeicher) speichern und später noch einmal senden. Wenn Ihr Absender auf „Bei Fehler löschen“ festgelegt 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-Weiterleiter, Bindplane-Agent, Pub/Sub, Amazon Kinesis Firehose, HTTPS-Webhook, direkt an die Aufnahme-API.
Nutzeraktion	Sorgen Sie dafür, dass Ihr Datenaufnahmevolumen mit Ihrer erworbenen Kapazität übereinstimmt.	Achten Sie außerdem darauf, dass Ihre Aufnahmequellen für die Datenaufbewahrung, das Puffern und das Wiederholen konfiguriert sind. Weitere Informationen finden Sie unter Konfigurationen für das Puffern und Wiederholen für Push-basierte Systeme.

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

Bei Feeds, die Pull-basierte Aufnahmemethoden verwenden, füllt Google SecOps gepufferte Daten nach, wenn das Fenster für das Burst-Limit zurückgesetzt wird. Dabei werden Live-Daten gegenüber gepufferten Daten priorisiert. Dieser Mechanismus sorgt dafür, dass Ihr Rückstand an gepufferten Daten den eingehenden Live-Datentraffic nicht beeinträchtigt (was zu längeren Erkennungsverzögerungen führen kann).

Zugewiesenes Burst-Limit ansehen

So ermitteln Sie das Burst-Limit, das Ihrem Google SecOps-Mandanten zugewiesen ist:

Rufen Sie in der Google SecOps-Konsole Dashboards > Data Ingestion and Health auf.
Sehen Sie sich das Burst Limit Graph - Quota Limit an. Das Diagramm zeigt Ihr zugewiesenes Limit (die flache Linie) im Verhältnis zu Ihrer tatsächlichen Aufnahmerate.

Nachverfolgen, ob Sie sich Ihrem Burst-Limit nähern oder es überschreiten

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

Google SecOps-Dashboards verwenden, um nachzuverfolgen, 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:
- Ingestion rate graph: zeigt Ihren aktuellen Durchsatz.
- Burst rejection graph: zeigt das Volumen der Logs, die aufgrund der Überschreitung des Burst-Limits abgelehnt wurden (HTTP-Fehler 429).

Cloud Monitoring verwenden, um nachzuverfolgen, ob Sie sich Ihrem Burst-Limit nähern oder es überschreiten

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

Relevante Messwerte sind:

Aufgenommenes Volumen: chronicle.googleapis.com/ingestion/log/bytes_count
Abgelehntes Volumen: chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

In den folgenden Abschnitten finden Sie Beispielabfragen in PromQL für die Überwachung und Benachrichtigung.

Nutzung des Burst-Limits ansehen

Verwenden Sie die folgende PromQL-Abfrage, um die Nutzung des 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 aufzurufen, 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 70% des Burst-Limits erreicht sind:

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-Insights verwenden.

Ablehnungen aufgrund von Burst-Limits verarbeiten, die durch Push-basierte Methoden verursacht werden

Wenn Sie aufgrund des Erreichens Ihres 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 Aufnahmequellen Daten puffern und es noch einmal versuchen.
Aufnahme optimieren: Überprüfen Sie die Aufnahmeskripts und achten Sie darauf, dass sie keine unnötigen Daten senden oder die API nicht mit massiven Batches auf einmal überlasten. Verteilen Sie Uploads von Verlaufsdaten nach Möglichkeit. Filtern Sie redundante Daten mit der Datenverarbeitungspipeline heraus.
Warten: Bei vorübergehenden Spitzen reicht es oft aus, zu warten, bis das 5-Minuten-Fenster zurückgesetzt wird, und es dann noch einmal zu versuchen.

Einige Beispielkonfigurationen finden Sie unter Konfigurationen für das Puffern und Wiederholen für Push-basierte Systeme.

Benutzerdefinierte Kapazitätsplanung für extrem hohen Durchsatz

Ungeachtet der anderen in diesem Dokument beschriebenen Punkte gilt ein Datenaufnahmedurchsatz von mehr als 3 GB/s als extrem hoher Durchsatz. Wenn Sie umfangreiche Datenmigrationen planen, mit einem dauerhaft extrem hohen Durchsatz rechnen oder Architekturen ausführen, die regelmäßig massive Aufnahmespitzen erzeugen, müssen Sie sich an Ihr Kontoteam wenden, um eine benutzerdefinierte Kapazitätsbereitstellung zu erhalten.

Da die Bereitstellung einer dedizierten regionalen Kapazitätserweiterung mehrere Wochen dauern kann, benachrichtigen Sie den Google Cloud Support mindestens 90 Tage im Voraus über erwartete extreme Aufnahmeereignisse, 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 mein Burst-Limit erhöhen?

Wenn Sie erwarten, dass Ihr Datenaufnahmevolumen dauerhaft steigt, können Sie Ihre erworbene Kapazität erhöhen. Wenden Sie sich dazu an Ihren Google SecOps-Vertriebsmitarbeiter.

Kann ich die Limits auf Logtype-Ebene für Pull-basierte Feeds erhöhen?

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

Wenn Sie das Limit auf Logtype-Ebene für einen Logtyp erhöhen, ändert sich das Limit für andere Logtypen oder Ihr gesamtes Burst-Limit nicht.

Kann ich meinen Datenrückstand nachverfolgen?

Derzeit nicht.

Wie kann ich meinen Datenrückstand beseitigen?

Wenn Sie einen sehr großen Datenrückstand haben und diesen beseitigen möchten, um Ihr Burst-Limit-Kontingent freizugeben, haben Sie folgende Möglichkeiten:

Kaufen Sie zusätzliche Kapazität, um Ihre Limits zu erhöhen.
Deaktivieren Sie bestimmte Feeds, bei denen das Volumen unerwartet gestiegen ist.
Bitten Sie den technischen Support von Google SecOps, Ihren Rückstand zu löschen.

Wenn Sie Ihren Rückstand löschen 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 Ihr Rückstand beseitigt ist, wird Ihr Feed wieder aktiviert und Sie sehen neue Daten. Je nach Größe Ihres Rückstands kann dies einige Minuten bis einige Stunden dauern.

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

Die Limits für die Aufnahmerate, die für Datenfeeds gelten, die Rohlogdaten an die Datenverarbeitungspipeline von Google SecOps senden, sind höher als das Burst-Limit Ihres Mandanten.

Wenn Sie Ihr Burst-Limit überschreiten, akzeptiert die Datenverarbeitungspipeline keine zusätzlichen Anfragen mehr. Das hängt davon ab, ob Ihre Daten mit Pull-basierten oder Push-basierten Methoden aufgenommen werden:

Pull-basierte Methoden: Die Aufnahme wird automatisch gepuffert und erfordert keine zusätzliche Konfiguration.
Push-basierte Methoden: Google SecOps lehnt die Daten vorübergehend mit dem HTTP-Fehler 429 „Too Many Requests“ 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 folgenden 5-Minuten-Fenster zurückgesetzt wird.

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

Wenn Ihr Burst-Limit niedriger ist als vereinbart, 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