Comprendre les quotas et les limites de rafale

Compatible avec :

Ce document décrit les quotas et les limites de rafale dans Google Security Operations.

Définition des limites de rafale

Les limites de rafale sont une forme de limites de service dans Google SecOps qui agissent comme une limite de vitesse pour l'ingestion de données. Elles sont conçues pour protéger l'infrastructure partagée de la plate-forme contre les pics de trafic soudains et massifs. Une limite de rafale restreint le taux d'ingestion (mesuré en mégaoctets par seconde (Mo/s) ou en gigaoctets par seconde (Go/s)) dans une fenêtre glissante de cinq minutes.

Calcul des limites de rafale

Google SecOps attribue des limites de rafale à vos locataires Google SecOps en fonction du volume d'ingestion annuel que vous avez acheté (capacité achetée) conformément à votre licence Google SecOps.

Pour tenir compte des variations attendues et des pics de trafic de journaux imprévus, votre limite de rafale quotidienne est provisionnée sous forme de plage spécifique, ce qui vous permet d'ingérer entre une et trois fois (1x à 3x) votre moyenne quotidienne attendue (calculée comme votre capacité annuelle achetée divisée par 365 jours). Cette allocation de volume flexible est conçue pour absorber les pics d'ingestion standards sans perturber vos opérations. Par exemple, si votre capacité annuelle achetée est de 365 To, votre moyenne quotidienne attendue est de 1 To. Votre limite de rafale provisionnée se situera strictement entre 1 To et 3 To par jour (ce qui se traduit par une plage de débit d'environ 12 Mo/s à 36 Mo/s). Si votre ingestion de données dépasse systématiquement cette plage provisionnée de 1x à 3x, vous devrez augmenter votre capacité annuelle achetée.

Les limites de rafale sont appliquées par locataire client Google SecOps.

Le tableau suivant montre comment les limites de rafale correspondent à différentes quantités de capacité achetée :

Exemple de capacité achetée Plage de limites de rafale Limite de rafale de 5 minutes Ingestion à la limite de rafale maximale (par heure) Ingestion à la limite de rafale maximale (par jour) Ingestion à la limite de rafale maximale (par an)
100 To 3 à 10 Mo/s 0,9 à 3 Go ~34 Go ~822 Go 300 To
500 To 16 à 48 Mo/s 4,8 à 14,4 Go ~171 Go ~4 To 1,5 Po
1 Po 32 à 97 Mo/s 9,6 à 29 Go ~343 Go ~8 To 3 Po
5 Po 158 à 476 Mo/s 47,4 à 143 Go ~1,7 To ~41 To 15 Po
30 Po 0,96 à 2,86 Go/s 288 à 858 Go ~10,3 To ~247 To 90 Po

Le trafic d'ingestion qui inclut des pics de vitesse extrêmes et soudains peut être soumis à une limitation dynamique du débit ou à une limitation temporaire pour protéger la stabilité régionale.

Pendant ces périodes, les données peuvent subir des retards d'ingestion jusqu'à ce que le pic diminue.

Pour les exigences de débit ultra-élevé, consultez Planification de la capacité personnalisée pour un débit ultra-élevé.

Applicabilité des limites de rafale pour les flux basés sur l'extraction

Google SecOps limite également l'ingestion basée sur l'extraction à un tiers (33%) de la limite de rafale globale par type de journal (sur tous les flux). Cette limite est en place pour s'assurer que l'ingestion basée sur l'extraction (généralement à partir de sources cloud) n'épuise pas les limites de rafale globales de votre locataire et ne sature pas l'ingestion de données à l'aide de méthodes basées sur l'envoi (par exemple, à l'aide d'agents Bindplane, de redirecteurs ou d'une ingestion directe dans les API Google SecOps).

Méthodes d'ingestion basées sur l'extraction

Les méthodes basées sur l'extraction incluent les méthodes d'ingestion (appelées types de sources dans Google SecOps) dans lesquelles Google SecOps contacte activement l'API source pour extraire des données. Cela inclut les types de sources suivants compatibles avec Google SecOps :

  • API tierces
  • Azure Event Hub
  • Ingestion directe à partir de Google Workspace et Google Cloud
  • Cloud Storage
  • Flux Cloud Storage (basé sur les événements)
  • Amazon S3
  • Amazon SQS
  • Azure Blobstore
  • Requête SFTP
  • Requête HTTP

Par exemple, si la limite de rafale de votre locataire est définie sur 150 Mo/s et que votre locataire ingère des journaux de contexte utilisateur Okta à l'aide d'un connecteur d'API tiers (qui est une méthode d'ingestion basée sur l'extraction), le système limite le taux d'ingestion de tous les flux Okta combinés à un maximum de [150/3 =] 50 Mo/s. Cette limite supplémentaire est appliquée même si votre taux d'ingestion de données global se situe dans la limite de rafale qui vous est attribuée.

Exceptions aux limites au niveau du type de journal

Bien que les limites au niveau du type de journal s'appliquent généralement aux flux basés sur l'extraction, les exceptions suivantes s'appliquent :

  • Webhooks HTTPS : cette méthode d'ingestion est basée sur l'envoi et n'est pas soumise à des limites au niveau du type de journal. Elle est toutefois soumise à la limite de rafale globale du locataire client et renvoie un code d'état HTTP 429 lorsqu'un flux dépasse cette limite.
  • Azure Event Hub : il s'agit d'une méthode d'ingestion basée sur l'extraction qui n'est pas soumise à des limites au niveau du type de journal.

Implémentation des limites de rafale

Le système applique les limites de rafale par intervalles de cinq minutes. Par exemple, si votre limite de rafale est définie sur 50 Mo/s, vous pouvez ingérer jusqu'à 15 Go toutes les cinq minutes. Si vous ingérez les 15 Go au cours des deux premières minutes, l'ingestion est bloquée pendant les trois minutes restantes de cette fenêtre. Cette limite est réinitialisée automatiquement au début de l'intervalle de cinq minutes suivant.

Les limites au niveau du type de journal sont appliquées de la même manière, mais au niveau des types de journaux individuels. Par exemple, si vous disposez de 5 Go pour les flux basés sur l'extraction toutes les cinq minutes et que le volume total de données ingérées pour un seul type de journal dépasse 5 Go au cours des deux premières minutes, l'ingestion est mise en pause pendant les trois minutes restantes de cette fenêtre. La limite est réinitialisée automatiquement au début de l'intervalle de cinq minutes suivant.

Que deviennent vos données si vous dépassez vos limites de rafale ?

Si vous dépassez votre limite de rafale, Google SecOps met en pause l'ingestion de données supplémentaires, et les mécanismes suivants sont déclenchés, selon que vos données sont ingérées à l'aide de méthodes basées sur l'extraction ou sur l'envoi :

  • Utilisation de méthodes basées sur l'extraction : l'ingestion est mise en mémoire tampon automatiquement et ne nécessite aucune configuration supplémentaire de votre part, en tant que client. Les données restent stockées dans la mémoire tampon jusqu'à ce que la limite soit réinitialisée et que Google SecOps reprenne l'ingestion de données.
  • Utilisation de méthodes basées sur l'envoi : Google SecOps rejette temporairement l'ingestion de données avec une erreur HTTP 429 "Too Many Requests" (Trop de requêtes). Cela signale à votre mécanisme d'ingestion de mettre en pause, de mettre en mémoire tampon et de réessayer, afin de garantir qu'aucune donnée n'est perdue.

Lorsque vous utilisez des méthodes d'ingestion basées sur l'envoi, il vous incombe, en tant que client, de mettre en tampon les données et de réessayer (voir Responsabilités du client en matière de mise en tampon des données et de nouvelle tentative).

Les rejets de limites de rafale ne sont pas des pertes de données

Il est important de comprendre que les rejets de limites de rafale (HTTP 429) ne sont pas des événements de perte de données. Un rejet de limite de rafale (erreur HTTP 429) est une mise en pause de l'ingestion de données.

En vous assurant que vos systèmes basés sur l'envoi disposent d'une mémoire tampon de disque et d'une logique de nouvelle tentative adéquates, le fait d'atteindre une limite de rafale n'entraîne qu'un léger délai (retard d'ingestion), jamais la perte permanente de la télémétrie de sécurité.

Une perte de données ne se produit que si le système d'envoi (par exemple, l'agent Bindplane, le redirecteur ou le script) ignore l'erreur de rejet de limite de rafale et supprime l'entrée de journal au lieu de la stocker pour une nouvelle tentative.

Responsabilités du client en matière de mise en mémoire tampon des données et de nouvelle tentative

Bien que Google SecOps gère automatiquement la mise en mémoire tampon des données et les nouvelles tentatives pour les données ingérées à l'aide de méthodes d'ingestion basées sur l'extraction, vous êtes responsable de la mise en mémoire tampon des données et des nouvelles tentatives d'ingestion de données à l'aide de méthodes d'ingestion basées sur l'envoi (telles que les webhooks HTTPS, Bindplane, les redirecteurs ou Cribl).

Vous devez configurer vos systèmes pour qu'ils mettent automatiquement en mémoire tampon et renvoient les données lorsque votre limite de rafale est atteinte afin de gérer efficacement le dépassement de données.

Le tableau suivant met en évidence les principales différences dans la façon dont Google SecOps gère l'ingestion de données lorsque votre limite de rafale est atteinte pour les deux types de méthodes d'ingestion :

Fonctionnalité Ingestion basée sur l'extraction Ingestion basée sur l'envoi
Fonctionnement Google SecOps contacte activement l'API source pour extraire des données. Vos systèmes initient la connexion et envoient des données à Google.
Responsabilité en matière de mise en mémoire tampon des données et de nouvelle tentative Google SecOps gère automatiquement la mise en mémoire tampon. Lorsque la limite de rafale est atteinte, Google SecOps met en pause l'ingestion de données supplémentaires. Les données restent stockées dans la mémoire tampon jusqu'à ce que la limite soit réinitialisée et que Google SecOps reprenne l'extraction.
La mémoire tampon ne stocke les données que pendant 90 jours maximum, après quoi elles sont supprimées.		 Le client doit gérer la mise en mémoire tampon. Lorsque Google SecOps répond avec HTTP 429, votre système d'envoi doit intercepter cette erreur, enregistrer les données dans une file d'attente locale (disque ou mémoire) et réessayer de les envoyer ultérieurement. Si votre expéditeur est défini sur "drop on failure" (supprimer en cas d'échec), les données seront perdues.
Types de sources de données API tierce, Azure Event Hub, ingestion directe à partir de Google Workspace et Google Cloud, Cloud Storage, flux Cloud Storage (basé sur les événements), Amazon S3, Amazon SQS, Azure Blobstore, requête SFTP, requête HTTP. Redirecteur Google SecOps, agent Bindplane, Pub/Sub, Amazon Kinesis Firehose, webhook HTTPS, direct vers l'API d'ingestion.
Action utilisateur Prenez des mesures pour aligner votre volume d'ingestion de données sur votre capacité achetée. Assurez-vous également que vos sources d'ingestion sont configurées pour la conservation des données, la mise en mémoire tampon et la nouvelle tentative.
Pour en savoir plus, consultez Configurations de mise en mémoire tampon et de nouvelle tentative pour les systèmes basés sur l'envoi.

Quand les données mises en mémoire tampon pour les flux basés sur l'extraction sont-elles remplies ?

Pour les flux utilisant des méthodes d'ingestion basées sur l'extraction, lorsque la fenêtre de limite de rafale est réinitialisée, Google SecOps remplit les données mises en mémoire tampon, en donnant la priorité aux données en direct par rapport aux données mises en mémoire tampon. Ce mécanisme garantit que votre backlog de données mises en mémoire tampon n'interfère pas avec votre trafic de données en direct entrant (ce qui peut entraîner des retards de détection).

Afficher votre limite de rafale attribuée

Pour déterminer la limite de rafale attribuée à votre locataire Google SecOps, procédez comme suit :

  1. Dans votre console Google SecOps, accédez à Tableaux de bord > Ingestion de données et état.
  2. Affichez le graphique de la limite de rafale – Limite de quota. Le graphique affiche votre limite attribuée (la ligne plate) par rapport à votre taux d'ingestion réel.

Vérifier si vous approchez ou dépassez votre limite de rafale

Vous pouvez suivre l'utilisation à l'aide des tableaux de bord intégrés ou de Cloud Monitoring.

Utiliser les tableaux de bord Google SecOps pour vérifier si vous approchez ou dépassez votre limite de rafale

  • Accédez à Tableaux de bord > Ingestion de données et état , puis consultez les éléments suivants :

    • Graphique du taux d'ingestion : affiche votre débit actuel.
    • Graphique des rejets de rafale : affiche le volume de journaux rejetés (erreurs HTTP 429) en raison du dépassement de la limite de rafale.

Utiliser Cloud Monitoring pour vérifier si vous approchez ou dépassez votre limite de rafale

Vous pouvez utiliser l'explorateur de métriques dans Google Cloud pour créer des alertes personnalisées. Nous vous recommandons de créer une alerte d'ingestion qui vous avertit lorsque le volume d'octets ingérés dépasse le seuil de limite de rafale.

Les métriques pertinentes incluent les suivantes :

  • Volume ingéré : chronicle.googleapis.com/ingestion/log/bytes_count
  • Volume rejeté : `chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

Règles d'alerte prêtes à l'emploi

Google SecOps fournit des règles d'alerte prêtes à l'emploi dans Cloud Monitoring que vous pouvez activer pour surveiller votre quota d'ingestion.

Pour trouver et activer ces règles, procédez comme suit :

  1. Dans la Google Cloud console, accédez à Monitoring > Integrations.
  2. Sélectionnez Chronicle Security dans la liste des intégrations.
  3. Cliquez sur l'onglet Alertes.
  4. Examinez et activez les exemples de règles d'alerte suivants :
    • Règle d'alerte d'approche de la limite de quota d'ingestion : détecte si votre volume d'ingestion de données approche de la limite de quota.
    • Règle d'alerte de rejet de quota d'ingestion : détecte si les requêtes d'ingestion sont rejetées en raison d'un quota d'ingestion insuffisant (erreurs HTTP 429).

Exemples

Les sections suivantes contiennent des exemples de requêtes PromQL pour la surveillance et les alertes.

Afficher votre utilisation de la limite de rafale

  • Pour afficher votre utilisation de la limite de rafale, utilisez la requête PromQL suivante :

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

Afficher le nombre d'octets rejetés après avoir dépassé la limite de rafale

  • Pour afficher le nombre d'octets rejetés après avoir dépassé la limite de rafale, utilisez la requête PromQL suivante :

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

Déclencher une alerte lorsque vous atteignez 70% de votre limite de rafale

  • Pour déclencher une alerte lorsque vous atteignez 70% de votre limite de rafale, utilisez la requête PromQL suivante :

    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

Pour surveiller votre volume d'ingestion quotidien par rapport aux limites contractuelles, utilisez la métrique Taille totale des journaux ingérés (chronicle.googleapis.com/ingestion/log/bytes_count).

Pour obtenir des instructions sur la configuration d'une règle d'alerte de volume quotidien, consultez Configurer un exemple de règle pour surveiller le volume d'ingestion quotidien. Pour obtenir des instructions sur la configuration d'autres alertes d'ingestion, consultez Analyser l'ingestion avec Cloud Monitoring.

Pour en savoir plus sur la configuration des alertes d'ingestion, consultez Utiliser Cloud Monitoring pour l'ingestion afin d'obtenir des insights sur l'ingestion.

Gérer les rejets de limites de rafale causés par des méthodes basées sur l'envoi

Si vous rencontrez des erreurs de rejet (HTTP 429) en raison de l'atteinte de votre limite de rafale pour les données entrantes à l'aide de méthodes basées sur l'envoi, nous vous recommandons de procéder comme suit :

  • Vérifier la mise en mémoire tampon : assurez-vous que vos sources d'ingestion mettent en mémoire tampon les données et réessayer.
  • Optimiser l'ingestion : examinez les scripts d'ingestion et assurez-vous qu'ils n'envoient pas de données inutiles ni ne saturent l'API avec des lots massifs en une seule fois. Si possible, répartissez les importations de données historiques. Filtrez les données redondantes à l'aide de la fonctionnalité de pipeline de traitement des données.
  • Attendre : pour les pics temporaires, il suffit souvent d'attendre la réinitialisation de la fenêtre de cinq minutes, puis de réessayer.

Pour obtenir des exemples de configurations, consultez Configurations de mise en mémoire tampon et de nouvelle tentative pour les systèmes basés sur l'envoi.

Planification de la capacité personnalisée pour un débit ultra-élevé

Nonobstant toute disposition décrite dans les autres sections de ce document, le débit d'ingestion de données supérieur à 3 Go/s est considéré comme un débit ultra-élevé. Si vous prévoyez des migrations de données à grande échelle, un débit ultra-élevé soutenu ou des architectures qui génèrent systématiquement des rafales d'ingestion massives, vous devez contacter votre équipe chargée du compte pour le provisionnement de capacité personnalisée.

Étant donné que le déploiement d'une extension de capacité régionale dédiée peut prendre plusieurs semaines, veuillez avertir Google Cloud l'assistance au moins 90 jours avant les événements d'ingestion extrêmes prévus pour vous assurer que vos exigences en matière de débit peuvent être satisfaites.

Questions fréquentes

Les sections suivantes répondent aux questions fréquentes.

Puis-je augmenter ma limite de rafale ?

Si vous prévoyez une augmentation permanente de votre volume d'ingestion de données, vous pouvez augmenter votre capacité achetée en contactant votre conseiller commercial Google SecOps.

Puis-je augmenter les limites au niveau du type de journal pour les flux basés sur l'extraction ?

Vous pouvez augmenter vos limites au niveau du type de journal pour un type de journal spécifique en envoyant une demande à l'assistance technique Google SecOps à l'avance.

L'augmentation de la limite au niveau du type de journal pour un type de journal ne modifie pas la limite appliquée aux autres types de journaux ni votre limite de rafale globale.

Est-il possible de suivre mon backlog de données ?

Pas pour le moment.

Quels sont les moyens possibles de supprimer mon backlog de données ?

Si vous avez accumulé un très grand backlog de données et que vous souhaitez le supprimer pour libérer votre quota de limite de rafale, vous pouvez procéder comme suit :

  • Achetez une capacité supplémentaire pour augmenter vos limites.
  • Désactivez les flux spécifiques dont le volume a augmenté de manière inattendue.

  • Demandez à l'assistance technique Google SecOps de supprimer votre backlog.

    Pour supprimer votre backlog, votre flux de données est temporairement désactivé jusqu'à ce que toutes les requêtes de nouvelle tentative pour les données remplies soient traitées. Pendant ce temps, vous ne pourrez pas ingérer de nouvelles données.

    Une fois votre backlog supprimé, votre flux est réactivé et vous verrez de nouvelles données arriver. Selon la taille de votre backlog, cela peut prendre de quelques minutes à quelques heures.

Les limites de rafale s'appliquent-elles également à l'ingestion de données dans le pipeline de traitement des données ?

Les limites de taux d'ingestion applicables aux flux de données qui envoient des données de journaux brutes dans le pipeline de traitement des données de Google SecOps sont définies comme étant supérieures à la limite de rafale de votre locataire.

Si vous dépassez votre limite de rafale, le pipeline de traitement des données cesse d'accepter les requêtes supplémentaires, comme suit :

  • Utilisation de méthodes basées sur l'extraction : l'ingestion est mise en mémoire tampon automatiquement et ne nécessite aucune configuration supplémentaire.
  • Utilisation de méthodes basées sur l'envoi : Google SecOps rejette temporairement les données avec une erreur HTTP 429 "Too Many Requests" (Trop de requêtes).

Toutes les données transformées après le déclenchement de la limite de rafale sont temporairement mises en mémoire tampon dans une file d'attente interne jusqu'à ce que la limite soit réinitialisée dans la fenêtre de cinq minutes suivante.

Que dois-je faire si ma limite de rafale est inférieure à celle pour laquelle j'ai signé un contrat ?

Si votre limite de rafale est inférieure à celle pour laquelle vous avez signé un contrat, contactez l'assistance Google (voir Assistance Google SecOps) et indiquez votre limite de rafale attendue.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.