Comprendre les quotas et les limites de pics

Compatible avec :

Google SecOps

Attention : L'API Ingestion est obsolète et sera abandonnée le 20 juillet 2027. Pour ingérer des journaux dans Google SecOps, utilisez plutôt l'API Chronicle. Pour savoir comment migrer, consultez Migrer de l'ancienne API SIEM vers l'API Chronicle.

Ce document décrit les quotas et les limites de pics 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.

Remarque : Pour connaître la définition du terme service et d'autres termes, consultez les Conditions spécifiques aux services SecOps.

Calcul des limites de rafale

Google SecOps attribue des limites de pics à 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 pics quotidiens est définie sous la forme d'une plage spécifique. Elle vous permet d'ingérer entre une et trois fois (1x à 3x) votre moyenne quotidienne attendue (calculée en divisant votre capacité annuelle achetée par 365 jours). Cette marge 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 sera strictement comprise entre 1 To et 3 To par jour (ce qui correspond à une plage de débit d'environ 12 MBps à 36 MBps). 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 pics 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 la limite de rafale	Limite de 5 minutes	Ingestion à la limite de rafale maximale (par heure)	Ingestion à la limite maximale de rafale (quotidienne)	Ingestion à la limite maximale de rafale (annuelle)
100 To	3 à 10 Mbit/s	0,9 à 3 Go	~34 Go	~822 Go	300 To
500 To	16 à 48 Mbit/s	4,8 à 14,4 Go	~171 Go	~4 To	1,5 Po
1 Po	32 à 97 Mbit/s	9,6 à 29 Go	~343 Go	~8 To	3 Po
5 Po	158 à 476 Mbit/s	47,4 à 143 Go	~1,7 To	~41 To	15 Po
30 Po	0,96 à 2,86 Gbit/s	288 à 858 Go	~10,3 To	~247 To	90 Po

Remarque : Une allocation de volume quotidienne reste soumise aux contraintes de débit physique dans la région. Bien que Google SecOps accepte les pics de volume quotidiens jusqu'à la limite de x3, les débits de transfert de données instantanés (débit) sont gérés activement pour assurer une haute disponibilité et éviter la pénurie de ressources dans l'environnement régional partagé.

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

Pendant ces périodes, les données peuvent être ingérées avec un certain retard 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 (pour 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 globales de rafale de votre locataire et n'empêche pas l'ingestion de données à l'aide de méthodes basées sur l'envoi (par exemple, à l'aide d'agents Bindplane, de transmetteurs ou de l'ingestion directe dans les API Google SecOps).

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

Les méthodes de type Pull incluent les méthodes d'ingestion (appelées types de sources dans Google SecOps) où Google SecOps contacte activement l'API source pour extraire les données. Cela inclut les types de sources suivants compatibles avec Google SecOps :

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

Par exemple, si la limite de rafale pour votre locataire est définie sur 150 Mbit/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 Mbit/s. Cette limite supplémentaire s'applique même si votre taux global d'ingestion de données respecte la limite de rafale qui vous a été 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 le push et n'est pas soumise à des limites au niveau du type de journal. Toutefois, il est soumis à 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 des limites d'utilisation intensive par intervalles de cinq minutes. Par exemple, si votre limite de rafale est définie sur 50 Mbit/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 période. Cette limite se réinitialise automatiquement au début de l'intervalle de cinq minutes suivant.

Les limites au niveau des types de journaux sont appliquées de la même manière, mais s'appliquent 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 type de journal donné dépasse 5 Go au cours des deux premières minutes, l'ingestion est suspendue pendant les trois minutes restantes de cette période. La limite se réinitialise automatiquement au début de l'intervalle de cinq minutes suivant.

Que se passe-t-il pour vos données si vous dépassez vos limites de pics ?

Si vous dépassez votre limite de pics, Google SecOps suspend 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 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. 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 des données.
• Utilisation de méthodes de type Push : Google SecOps refuse temporairement l'ingestion de données avec une erreur HTTP 429 "Too Many Requests" (Trop de requêtes). Cela indique à votre mécanisme d'ingestion de mettre en pause, de mettre en mémoire tampon et de réessayer, ce qui garantit qu'aucune donnée n'est perdue.

Lorsque vous utilisez des méthodes d'ingestion basées sur le push, il vous incombe, en tant que client, de mettre en mémoire tampon et de réessayer (voir Responsabilités du client concernant la mise en mémoire tampon et la réinitialisation des données).

Les refus liés à la limite de pics ne sont pas considérés comme une perte de données

Il est important de comprendre que les refus dus à une limite de rafale (HTTP 429) ne sont pas des événements de perte de données. Un refus de limite de rafale (erreur HTTP 429) correspond à une pause dans l'ingestion de données.

En vous assurant que vos systèmes basés sur le push disposent d'une mise en mémoire tampon de disque et d'une logique de réessai adéquates, le dépassement d'une limite de rafale n'entraîne qu'un léger retard (décalage d'ingestion), et 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 transmetteur ou le script) ignore l'erreur de refus de limite de rafale et supprime l'entrée de journal au lieu de la stocker pour une nouvelle tentative.

Responsabilités du client concernant la mise en mémoire tampon et la réessai des données

Bien que Google SecOps gère automatiquement la mise en mémoire tampon 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 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 transmetteurs ou Cribl).

Attention : Le transitaire est obsolète. Le composant de transfert est progressivement supprimé de la plate-forme Google SecOps et arrivera en fin de vie en janvier 2027. 1er avril 2026 : les nouveaux clients Google SecOps ne pourront pas utiliser le composant de transfert. 1er janvier 2027 : le transitaire est officiellement en fin de vie. Aucun autre correctif, y compris de sécurité, ne sera publié. 1er avril 2027 : l'ingestion de données à partir du composant de transfert n'est plus autorisée. Google recommande d'utiliser Bindplane pour Google SecOps comme solution principale pour la collecte des journaux. Pour en savoir plus, consultez Utiliser Bindplane avec Google SecOps.

Vous devez configurer vos systèmes pour qu'ils mettent automatiquement en mémoire tampon et renvoient les données lorsque votre limite de pics est atteinte, afin de gérer efficacement le trop-plein 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 pics est atteinte pour les deux types de méthodes d'ingestion :

Fonctionnalité	Ingestion basée sur l'extraction	Ingestion basée sur le push
Fonctionnement	Google SecOps contacte activement l'API source pour récupérer les données.	Vos systèmes initient la connexion et envoient des données à Google.
Responsabilité de la mise en mémoire tampon et de la nouvelle tentative de données	Google SecOps gère automatiquement la mise en mémoire tampon. Lorsque la limite de pics est atteinte, Google SecOps suspend l'ingestion de données supplémentaires. Les données restent stockées dans le stockage tampon jusqu'à ce que la limite soit réinitialisée et que Google SecOps reprenne la récupération. Le stockage 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 un code HTTP 429, votre système d'envoi doit détecter 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 "Déposer en cas d'échec", les données seront perdues.
Types de sources de données	API tierce, Azure Event Hub, ingestion directe depuis Google Workspace et Google Cloud, Cloud Storage, flux Cloud Storage (piloté par les événements), Amazon S3, Amazon SQS, Azure Blobstore, requête SFTP, requête HTTP.	Transférer vers Google SecOps, agent Bindplane, Pub/Sub, Amazon Kinesis Firehose, webhook HTTPS, directement vers l'API d'ingestion.
Action utilisateur	Prenez des mesures pour aligner le volume d'ingestion de données sur la capacité que vous avez achetée.	Assurez-vous également que vos sources d'ingestion sont configurées pour la conservation, la mise en mémoire tampon et la réinitialisation des données. Pour en savoir plus, consultez Configurations de mise en mémoire tampon et de réinitialisation pour les systèmes basés sur le push.

Lorsque les données mises en mémoire tampon pour les flux basés sur l'extraction sont complétées

Pour les flux utilisant des méthodes d'ingestion basées sur l'extraction, lorsque la période de votre limite de pics est réinitialisée, Google SecOps complète les données mises en mémoire tampon, en privilégiant les données en direct par rapport aux données mises en mémoire tampon. Ce mécanisme permet de s'assurer que votre backlog de données mises en mémoire tampon n'interfère pas avec le trafic de données en direct entrant (ce qui peut entraîner des retards de détection).

Remarque : Lors du remplissage des données mises en mémoire tampon, vous pouvez observer que vos données mises en mémoire tampon sont diffusées en parallèle de vos données en direct.

Afficher votre limite de rafale attribuée

Pour connaître la limite de pics attribuée à votre locataire Google SecOps, procédez comme suit :

1. Dans la console Google SecOps, accédez à Tableaux de bord > Ingestion et état des données.
2. Consultez le graphique sur 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.

Suivre 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 savoir si vous approchez ou dépassez votre limite d'utilisation intensive

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

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

Utiliser Cloud Monitoring pour savoir 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.

Voici quelques exemples de métriques pertinentes :

• Volume ingéré : chronicle.googleapis.com/ingestion/log/bytes_count
• Volume refusé : 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 console Google Cloud , accédez à Monitoring > Intégrations.
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 "Limite de quota d'ingestion de données bientôt atteinte" : détecte si le 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 pics, 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 refusés après avoir dépassé la limite de rafale

• Pour afficher le nombre d'octets refusé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

Remarque : La syntaxe exacte de la requête peut varier en fonction de la configuration spécifique de votre ressource surveillée.

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

Gérer les rejets de limite de rafale causés par les méthodes basées sur le push

Si vous rencontrez des erreurs de refus (HTTP 429) parce que vous avez atteint votre limite de rafale pour les données entrantes à l'aide de méthodes basées sur le push, nous vous recommandons de procéder comme suit :

• Vérifiez la mise en mémoire tampon : assurez-vous que vos sources d'ingestion mettent en mémoire tampon les données et réessayent.
• Optimisez l'ingestion : examinez les scripts d'ingestion et assurez-vous qu'ils n'envoient pas de données inutiles ni ne submergent l'API avec des lots volumineux en même temps. Si possible, échelonnez les importations de données historiques. Filtrez les données redondantes à l'aide de la fonctionnalité de pipeline de traitement des données.
• Patientez : en cas de pics temporaires, il suffit souvent d'attendre que la fenêtre de cinq minutes se réinitialise, 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 le push.

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

Nonobstant toute autre information décrite dans les autres sections de ce document, un débit d'ingestion de données supérieur à 3 Gbit/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 pics d'ingestion massifs, vous devez contacter votre équipe chargée du compte pour un provisionnement de capacité personnalisé.

Étant donné que l'expansion de la capacité régionale dédiée peut prendre plusieurs semaines, veuillez informer l'assistance Google Cloud au moins 90 jours avant les événements d'ingestion extrême prévus pour vous assurer que vos besoins en débit peuvent être satisfaits.

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 du 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 journaux pour les flux basés sur l'extraction ?

Vous pouvez augmenter les 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 n'a aucune incidence sur la limite appliquée aux autres types de journaux ni sur votre limite de pics globale.

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

Pas pour le moment.

Comment puis-je résorber mon backlog de données ?

Si vous avez accumulé un très grand nombre de données en attente et que vous souhaitez les effacer pour libérer votre quota de limite de pics, vous pouvez procéder comme suit :

• Achetez de la 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 demandes de réessai pour les données complétées soient traitées avec succès. Pendant cette période, vous ne pourrez pas ingérer de nouvelles données.

  Une fois votre backlog effacé, votre flux est réactivé et de nouvelles données commencent à être collectées. 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 sur une valeur supérieure à la limite de rafale de votre locataire.

Si vous dépassez votre limite de pics, le pipeline de traitement des données cesse d'accepter les demandes supplémentaires, selon les règles suivantes :

• 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 de type Push : Google SecOps refuse 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 pics sont temporairement mises en mémoire tampon dans une file d'attente interne jusqu'à ce que la limite soit réinitialisée au cours de la période de cinq minutes suivante.

Que dois-je faire si ma limite de rafale est inférieure à celle prévue dans mon contrat ?

Si votre limite de rafale est inférieure à celle prévue dans votre contrat, contactez l'assistance Google (voir Assistance Google SecOps) et indiquez la limite de rafale attendue.

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