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. 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 gekauften jährlichen Aufnahmevolumen (gekaufte 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 gekaufte jährliche Kapazität geteilt durch 365 Tage). Dieses flexible Volumenkontingent soll Standardspitzen bei der Aufnahme abfangen, ohne Ihren Betrieb zu stören. Wenn Ihre gekaufte 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 gekaufte 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 gekaufter Kapazität entsprechen:

Beispiel für gekaufte 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

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

In diesen Zeiträumen kann es zu Verzögerungen bei der Datenaufnahme 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 pullbasierte Feeds

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

Pullbasierte Aufnahmemethoden

Zu den pullbasierten 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 (eventgesteuert)
  • 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-Logs zum Nutzerkontext mit einem Drittanbieter-API-Connector aufnimmt (eine pullbasierte 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

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

  • HTTPS-Webhooks: Diese Aufnahmemethode ist pushbasiert und unterliegt keinen Limits auf Logtype-Ebene. Sie unterliegt jedoch dem gesamten Burst-Limit des Kundenmandanten und gibt den Statuscode HTTP 429 zurück, wenn ein Feed dieses Limit überschreitet.
  • Azure Event Hub: Dies ist eine pullbasierte Aufnahmemethode, die keinen Limits auf Logtype-Ebene unterliegt.

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 pullbasierte 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 pullbasierten oder pushbasierten Methoden aufgenommen werden:

  • Pullbasierte 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.
  • Pushbasierte 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 zu wiederholen, damit keine Daten verloren gehen.

Bei pushbasierten 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 429-Fehler) ist eine Pause bei der Datenaufnahme.

Wenn Sie dafür sorgen, dass Ihre pushbasierten Systeme über eine angemessene Festplattenpufferung und Wiederholungslogik verfügen, führt das Überschreiten 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, die Weiterleitung oder das Skript) den Fehler bei 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 pullbasierten Aufnahmemethoden aufgenommen werden, automatisch verwaltet, sind Sie für das Puffern und Wiederholen der Datenaufnahme mit pushbasierten Aufnahmemethoden (z. B. HTTPS-Webhooks, Bindplane, Weiterleitungen 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überläufe effizient zu verarbeiten.

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

Funktion Pullbasierte Aufnahme Pushbasierte 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 (eventgesteuert), Amazon S3, Amazon SQS, Azure Blobstore, SFTP-Anfrage, HTTP-Anfrage. Google SecOps-Weiterleitung, Bindplane-Agent, Pub/Sub, Amazon Kinesis Firehose, HTTPS-Webhook, direkt an die Ingestion API.
Nutzeraktion Sorgen Sie dafür, dass Ihr Datenaufnahmevolumen mit Ihrer gekauften 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 Pufferungs- und Wiederholungskonfigurationen für pushbasierte Systeme.

Wann werden gepufferte Daten für pullbasierte Feeds nachgefüllt?

Wenn das Burst-Limit-Fenster für Feeds mit pullbasierten Aufnahmemethoden zurückgesetzt wird, füllt Google SecOps gepufferte Daten nach. Dabei werden Livedaten gegenüber gepufferten Daten priorisiert. Dieser Mechanismus sorgt dafür, dass Ihr Rückstand an gepufferten Daten den eingehenden Livedaten-Traffic nicht beeinträchtigt (was zu zusätzlichen Verzögerungen bei der Erkennung führen kann).

Zugewiesenes Burst-Limit ansehen

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

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

Überprü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.

Google SecOps-Dashboards verwenden, um zu überprüfen, ob Sie sich dem 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 einer Überschreitung des Burst-Limits abgelehnt wurden (HTTP 429-Fehler).

Cloud Monitoring verwenden, um zu überprüfen, ob Sie sich dem Burst-Limit nähern oder es überschreiten

Mit dem Metrics Explorer Google Cloud können Sie benutzerdefinierte Benachrichtigungen erstellen. 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

Standardmäßige Benachrichtigungsrichtlinien

Google SecOps bietet standardmäßige Benachrichtigungsrichtlinien in Cloud Monitoring, die Sie aktivieren können, um Ihr Aufnahmekontingent zu überwachen.

So suchen und aktivieren Sie diese Richtlinien:

  1. Rufen Sie in der Google Cloud Console Monitoring > Integrations auf.
  2. Wählen Sie in der Liste der Integrationen Chronicle Security aus.
  3. Klicken Sie auf den Tab Alerts.
  4. Prüfen und aktivieren Sie die folgenden Beispielbenachrichtigungsrichtlinien:
    • Benachrichtigungsrichtlinie für die Annäherung an das Ingestion-Kontingentlimit: Erkennt, ob sich Ihr Datenaufnahmevolumen dem Kontingentlimit nähert.
    • Benachrichtigungsrichtlinie für die Ablehnung von Aufnahmekontingenten: Erkennt, ob Aufnahmeanfragen aufgrund eines unzureichenden Aufnahmekontingents abgelehnt werden (HTTP 429-Fehler).

Beispiele

In den folgenden Abschnitten finden Sie PromQL-Beispielabfragen für das Monitoring und die Benachrichtigung.

Nutzung des Burst-Limits ansehen

  • Verwenden Sie die folgende PromQL-Abfrage, um die Nutzung des Burst-Limits zu sehen:

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

Verwenden Sie den Messwert Total ingested log size (chronicle.googleapis.com/ingestion/log/bytes_count), um Ihr tägliches Aufnahmevolumen mit den vertraglichen Limits zu vergleichen.

Eine Anleitung zum Einrichten einer Benachrichtigungsrichtlinie für das tägliche Volumen finden Sie unter Beispielrichtlinie zum Überwachen des täglichen Aufnahmevolumens einrichten. Eine Anleitung zum Einrichten anderer Aufnahmebenachrichtigungen finden Sie unter Aufnahme mit Cloud Monitoring analysieren.

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

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

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

  • Pufferung überprüfen: Achten Sie darauf, dass Ihre Aufnahmequellen Daten puffern und Wiederholungsversuche durchführen.
  • Aufnahme optimieren: Überprüfen Sie die Aufnahmeskripts und achten Sie darauf, dass keine unnötigen Daten gesendet werden oder die API nicht mit massiven Batches auf einmal überlastet wird. 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 Pufferungs- und Wiederholungskonfigurationen für pushbasierte Systeme.

Benutzerdefinierte Kapazitätsplanung für extrem hohen Durchsatz

Ungeachtet der anderen Abschnitte in diesem Dokument 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 verwenden, die regelmäßig massive Aufnahmespitzen 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, müssen Sie den Support Google Cloud mindestens 90 Tage im Voraus über erwartete extreme Aufnahmeereignisse informieren, 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 gekaufte Kapazität erhöhen. Wenden Sie sich dazu an Ihren Google SecOps-Vertriebsmitarbeiter.

Kann ich die Limits auf Logtype-Ebene für pullbasierte 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 einreichen.

Das Erhöhen des Limits auf Logtype-Ebene für einen Logtyp ändert nicht das Limit, das für andere Logtypen oder Ihr gesamtes Burst-Limit gilt.

Kann ich meinen Datenrückstand verfolgen?

Derzeit nicht.

Welche Möglichkeiten gibt es, meinen Datenrückstand zu 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 beseitigen.

    Wenn Sie Ihren Rückstand beseitigen 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 in 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. Dabei gilt Folgendes:

  • Pullbasierte Methoden: Die Aufnahme wird automatisch gepuffert und erfordert keine zusätzliche Konfiguration.
  • Pushbasierte 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 vertraglich vereinbart?

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