Informazioni su quote e limiti di burst
Questo documento descrive le quote e i limiti di burst in Google Security Operations.
Definizione dei limiti di burst
I limiti di burst sono una forma di limiti di servizio in Google SecOps che fungono da limite di velocità per l'importazione dati, progettati per proteggere l'infrastruttura condivisa della piattaforma da picchi improvvisi e massicci di traffico. Un limite di burst limita la velocità di importazione (misurata in megabyte al secondo, MBps, o gigabyte al secondo, GBps) in un intervallo di cinque minuti.
Come vengono calcolati i limiti di burst
Google SecOps assegna limiti di burst ai tuoi tenant Google SecOps in base al volume di importazione annuale acquistato (capacità acquistata) in base alla tua licenza Google SecOps.
Per tenere conto delle variazioni previste e dei picchi non pianificati nel traffico di log, il limite di burst giornaliero viene fornito come intervallo specifico, che consente di importare da una a tre volte (da 1× a 3×) la media giornaliera prevista (calcolata come la capacità annuale acquistata divisa per 365 giorni). Questa quota flessibile di volumi è progettata per assorbire i picchi di importazione standard senza interrompere le operazioni. Ad esempio, se la capacità annuale acquistata è di 365 TB, la media giornaliera prevista è di 1 TB. Il limite di burst di provisioning rientrerà rigorosamente nell'intervallo da 1 TB a 3 TB al giorno (che si traduce in un intervallo di velocità effettiva da circa 12 MBps a 36 MBps). Se l'importazione dati supera costantemente questo intervallo di provisioning da 1× a 3×, sarà necessario aumentare la capacità annuale acquistata.
I limiti di burst vengono applicati per tenant cliente di Google SecOps.
La tabella seguente mostra la corrispondenza tra i limiti di burst e le diverse quantità di capacità acquistata:
| Esempio di capacità acquistata | Intervallo del limite di burst | Limite di 5 minuti | Inserimento al limite massimo di burst (orario) | Importazione al limite massimo di burst (giornaliero) | Ingestione al limite massimo di burst (annuale) |
|---|---|---|---|---|---|
| 100 TB | 3 - 10 MBps | 0,9 - 3 GB | ~34 GB | ~822 GB | 300 TB |
| 500 TB | 16 - 48 MBps | 4,8 - 14,4 GB | ~171 GB | ~4 TB | 1,5 PB |
| 1 PB | 32 - 97 MBps | 9,6 - 29 GB | ~343 GB | ~8 TB | 3 PB |
| 5 PB | 158 - 476 MBps | 47,4 - 143 GB | ~1,7 TB | ~41 TB | 15 PB |
| 30 PB | 0,96 - 2,86 GBps | 288 - 858 GB | Circa 10,3 TB | ~247 TB | 90 PB |
Il traffico di importazione che include picchi di velocità estremi e improvvisi potrebbe essere soggetto a limitazione di frequenza dinamici o limitazione temporanea per proteggere la stabilità regionale.
Durante questi periodi, i dati potrebbero subire ritardi di importazione fino a quando il picco non si attenua.
Per requisiti di velocità effettiva molto elevata, consulta Pianificazione della capacità personalizzata per velocità effettiva molto elevata.
Applicabilità dei limiti di burst per i feed basati sul pull
Google SecOps limita anche l'importazione basata sul pull a un terzo (33%) del limite di burst complessivo per tipo di log (in tutti i feed). Questo limite è in vigore per garantire che l'acquisizione basata sul pull (di solito da origini cloud) non esaurisca i limiti di burst complessivi del tenant e non impedisca l'importazione dati utilizzando metodi basati sul push (ad esempio utilizzando agenti, agenti di inoltro o acquisizione diretta nelle API Google SecOps).
Metodi di importazione basati sul pull
I metodi basati sul pull includono metodi di importazione (denominati tipi di origine in Google SecOps) in cui Google SecOps contatta attivamente l'API di origine per recuperare i dati. Sono inclusi i seguenti tipi di origini supportati su Google SecOps:
- API di terze parti
- Hub eventi Azure
- Importazione diretta da Google Workspace e Google Cloud
- Cloud Storage
- Feed Cloud Storage (basato sugli eventi)
- Amazon S3
- Amazon SQS
- Archivio BLOB di Azure
- Richiesta SFTP
- Richiesta HTTP
Ad esempio, se il limite di burst per il tuo tenant è impostato su 150 MBps e il tuo tenant acquisisce i log del contesto utente Okta utilizzando un connettore API di terze parti (ovvero un metodo di acquisizione basato sul pull), il sistema limita la velocità di acquisizione di tutti i feed Okta combinati a un massimo di [150/3 =] 50 MBps. Questo limite aggiuntivo viene applicato anche se la velocità di importazione complessiva dei dati rientra nel limite di burst assegnato.
Eccezioni ai limiti a livello di tipo di log
Sebbene i limiti a livello di tipo di log si applichino generalmente ai feed basati sul pull, si applicano le seguenti eccezioni:
- Webhook HTTPS: questo metodo di importazione è basato sul push e non è soggetto a limiti a livello di tipo di log. Tuttavia, è soggetto al limite di burst complessivo del tenant cliente e restituisce un codice di stato
HTTP 429quando un feed supera questo limite. - Azure Event Hub: si tratta di un metodo di importazione basato sul pull che non è soggetto a limiti a livello di tipo di log.
Come vengono implementati i limiti di burst
Il sistema applica i limiti di burst a intervalli di cinque minuti. Ad esempio, se il limite di burst è impostato su 50 MBps, puoi importare fino a 15 GB ogni 5 minuti. Se inserisci tutti i 15 GB nei primi due minuti, l'inserimento viene bloccato per i tre minuti rimanenti della finestra. Questo limite viene azzerato automaticamente all'inizio dell'intervallo di cinque minuti successivo.
I limiti a livello di tipo di log vengono applicati allo stesso modo, ma a livello di singoli tipi di log. Ad esempio, se ti vengono assegnati 5 GB per i feed basati sul pull ogni 5 minuti e il volume totale dei dati importati per un singolo tipo di log supera i 5 GB nei primi due minuti, l'importazione viene sospesa per i tre minuti rimanenti della finestra. Il limite viene reimpostato automaticamente all'inizio dell'intervallo di cinque minuti successivo.
Cosa succede ai tuoi dati se superi i limiti di burst
Se superi il limite di burst, Google SecOps mette in pausa l'importazione di dati aggiuntivi e vengono attivati i seguenti meccanismi, a seconda che i dati vengano importati utilizzando metodi basati sul pull o sul push:
- Utilizzo di metodi basati sul pull: l'importazione viene memorizzata automaticamente nel buffer e non richiede alcuna configurazione aggiuntiva da parte tua, il cliente. I dati rimangono archiviati nello spazio di archiviazione buffer finché il limite non viene reimpostato e Google SecOps non riprende l'importazione dati.
- Utilizzo di metodi basati sul push: Google SecOps rifiuta temporaneamente l'importazione dati con un errore HTTP 429 "Troppe richieste". Questo indica al meccanismo di importazione di mettere in pausa, memorizzare nel buffer e riprovare, assicurando che non vengano persi dati.
Se utilizzi metodi di importazione basati sul push, la responsabilità di memorizzare nel buffer e riprovare è tua, in qualità di cliente (vedi Responsabilità del cliente per il buffering e il nuovo tentativo di invio dei dati).
I rifiuti del limite di burst non comportano la perdita di dati
È importante capire che i rifiuti del limite di burst (HTTP 429) non sono eventi di perdita di dati. Un rifiuto del limite di burst (errore HTTP 429) è una pausa nell'importazione dati.
Se i sistemi basati su push dispongono di un buffering del disco e di una logica di ripetizione adeguati, il raggiungimento di un limite di burst comporta solo un piccolo ritardo (ritardo di importazione), mai la perdita permanente della telemetria di sicurezza.
La perdita di dati si verifica solo se il sistema di invio (ad esempio l'agente Bindplane, il forwarder o lo script) ignora l'errore di rifiuto del limite di burst ed elimina la voce di log anziché memorizzarla per un nuovo tentativo.
Responsabilità del cliente per il buffering e il nuovo tentativo di invio dei dati
Sebbene Google SecOps gestisca automaticamente il buffering e i nuovi tentativi di acquisizione dei dati utilizzando metodi di acquisizione basati sul pull, sei responsabile del buffering e dei nuovi importazione dati utilizzando metodi di acquisizione basati sul push (come webhook HTTPS, Bindplane, agenti di inoltro o Cribl).
Devi configurare i tuoi sistemi in modo che memorizzino automaticamente i dati nel buffer e li inviino nuovamente quando viene raggiunto il limite di burst per gestire in modo efficiente l'overflow di dati.
La seguente tabella evidenzia le principali differenze nel modo in cui Google SecOps gestisce l'importazione dati quando viene raggiunto il limite di burst per entrambi i tipi di metodi di acquisizione dei dati:
| Funzionalità | Importazione basata sul pull | Importazione basata sul push |
|---|---|---|
| Come funziona | Google SecOps contatta attivamente l'API di origine per recuperare i dati. | I tuoi sistemi avviano la connessione e inviano i dati a Google. |
| Responsabilità per il buffering e il nuovo tentativo di invio dei dati | Google SecOps gestisce automaticamente il buffering. Quando viene raggiunto il limite di burst, Google SecOps mette in pausa l'importazione di dati aggiuntivi. I dati rimangono archiviati nello spazio di archiviazione buffer fino al ripristino del limite e alla ripresa del recupero da parte di Google SecOps. Lo spazio di archiviazione buffer memorizza i dati solo per un massimo di 90 giorni, dopodiché vengono eliminati. |
Il cliente deve gestire il buffering. Quando Google SecOps risponde con HTTP 429, il tuo sistema di invio deve rilevare questo errore, salvare i dati in una coda locale (disco o memoria) e riprovare a inviarli in un secondo momento. Se il mittente è impostato su "drop on failure", i dati andranno persi. |
| Tipi di origini dati | API di terze parti, Azure Event Hub, importazione diretta da Google Workspace e Google Cloud, Cloud Storage, feed Cloud Storage (basato su eventi), Amazon S3, Amazon SQS, Azure Blobstore, richiesta SFTP, richiesta HTTP. | Google SecOps Forwarder, agente Bindplane, Pub/Sub, Amazon Kinesis Firehose, webhook HTTPS, direttamente all'API di importazione. |
| Azione dell'utente | Intervieni per allineare il volume di importazione dati alla capacità acquistata. | Inoltre, assicurati che le origini di importazione siano configurate per la conservazione, il buffering e i nuovi tentativi dei dati. Per saperne di più, consulta Configurazioni di buffering e nuovi tentativi per i sistemi basati sul push. |
Quando i dati memorizzati nel buffer per i feed basati sul pull vengono riempiti
Per i feed che utilizzano metodi di importazione basati sul pull, quando la finestra del limite di burst viene reimpostata, Google SecOps esegue il backfill dei dati memorizzati nel buffer, dando la priorità ai dati live rispetto a quelli memorizzati nel buffer. Questo meccanismo garantisce che il backlog di dati memorizzati nel buffer non interferisca con il traffico di dati in tempo reale in entrata (il che può aumentare i ritardi di rilevamento).
Come visualizzare il limite di burst assegnato
Per determinare il limite di burst assegnato al tuo tenant Google SecOps:
- Nella console Google SecOps, vai a Dashboard > Inserimento e integrità dei dati.
- Visualizza il grafico del limite di burst - Limite di quota. Il grafico mostra il limite assegnato (la linea piatta) rispetto alla velocità di importazione effettiva.
Monitorare se stai per raggiungere o superare il limite di burst
Puoi monitorare l'utilizzo utilizzando le dashboard integrate o Cloud Monitoring.
Utilizza le dashboard di Google SecOps per monitorare se stai per raggiungere o superare il limite di burst
Vai a Dashboard > Inserimento e integrità dei dati e visualizza quanto segue:
- Grafico della velocità di inserimento: mostra la velocità effettiva attuale.
- Grafico dei rifiuti burst: mostra il volume dei log rifiutati (errori HTTP 429) a causa del superamento del limite burst.
Utilizza Cloud Monitoring per monitorare se ti stai avvicinando al limite di burst o lo stai superando
Puoi utilizzare Metrics Explorer in Google Cloud per creare avvisi personalizzati. Ti consigliamo di creare un avviso di importazione che ti avvisi quando il volume dei byte importati supera la soglia del limite di burst.
Le metriche pertinenti includono:
- Volume inserito:
chronicle.googleapis.com/ingestion/log/bytes_count - Volume rifiutato: `chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count
Policy di avviso predefinite
Google SecOps fornisce policy di avviso predefinite in Cloud Monitoring che puoi attivare per monitorare la quota di importazione.
Per trovare e attivare queste norme, segui questi passaggi:
- Nella console Google Cloud , vai a Monitoring > Integrazioni.
- Seleziona Chronicle Security dall'elenco delle integrazioni.
- Fai clic sulla scheda Avvisi.
- Esamina e attiva le seguenti policy di avviso di esempio:
- Policy di avviso per il limite di quota di acquisizione dei dati in avvicinamento: rileva se il volume di importazione dati si sta avvicinando al limite di quota.
- Policy di avviso di rifiuto della quota di importazione: rileva se le richieste di importazione vengono rifiutate a causa di una quota di importazione insufficiente (errori HTTP 429).
Esempi
Le sezioni seguenti contengono query PromQL di esempio per il monitoraggio e gli avvisi.
Visualizzare l'utilizzo del limite di burst
Per visualizzare l'utilizzo del limite di burst, utilizza la seguente query PromQL:
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]))
Visualizza il numero di byte rifiutati dopo il superamento del limite di burst
Per visualizzare il numero di byte rifiutati dopo aver superato il limite di burst, utilizza la seguente query PromQL:
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}])))
Attivare un avviso quando raggiungi il 70% del limite di burst
Per attivare un avviso quando raggiungi il 70% del limite di burst, utilizza la seguente query PromQL:
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
Per saperne di più sulla configurazione degli avvisi di importazione, consulta Utilizzare Cloud Monitoring per l'importazione per approfondimenti sull'importazione.
Gestire i rifiuti del limite di burst causati da metodi basati sul push
Se si verificano errori di rifiuto (HTTP 429) a causa del raggiungimento del limite di burst per i dati in entrata utilizzando metodi basati sul push, ti consigliamo di procedere nel seguente modo:
- Verifica il buffering: assicurati che le origini di importazione memorizzino i dati nel buffer e riprovino.
- Ottimizza l'importazione: esamina gli script di importazione e assicurati che non inviino dati non necessari o che non sovraccarichino l'API con batch massicci tutti in una volta. Se possibile, distribuisci i caricamenti dei dati storici. Filtra i dati ridondanti utilizzando la funzionalità della pipeline di trattamento dati.
- Attendi: per i picchi temporanei, spesso è sufficiente attendere il ripristino della finestra di cinque minuti e riprovare.
Per alcune configurazioni di esempio, consulta Configurazioni di buffering e nuovi tentativi per i sistemi basati su push.
Pianificazione della capacità personalizzata per una velocità effettiva ultra elevata
Nonostante quanto descritto nelle altre sezioni di questo documento, l'importazione dati con throughput superiore a 3 GBps è considerata throughput ultra elevato. Se prevedi migrazioni di dati su larga scala, prevedi una velocità effettiva ultra elevata e sostenuta o esegui architetture che generano costantemente burst di importazione massicci, devi contattare il team dedicato all'account per il provisioning della capacità personalizzata.
Poiché l'espansione della capacità regionale dedicata può richiedere diverse settimane per l'implementazione, ti invitiamo a comunicare Google Cloud all'assistenza almeno 90 giorni prima degli eventi di importazione estrema previsti per assicurarti che i tuoi requisiti di velocità effettiva possano essere soddisfatti.
Domande frequenti
Le sezioni seguenti forniscono le risposte alle domande frequenti.
Posso aumentare il limite di scatto a raffica?
Se prevedi un aumento permanente del volume di importazione dati, puoi aumentare la capacità acquistata contattando il tuo rappresentante di vendita Google SecOps.
Posso aumentare i limiti a livello di tipo di log per i feed basati sul pull?
Puoi aumentare i limiti a livello di tipo di log per un tipo di log specifico inviando in anticipo una richiesta tramite l'assistenza tecnica di Google SecOps.
L'aumento del limite a livello di tipo di log per un tipo di log non modifica il limite applicato ad altri tipi di log o il limite di burst complessivo.
È possibile monitorare il backlog dei dati?
Al momento non è possibile.
Quali sono i possibili modi per eliminare l'arretrato dei miei dati?
Se hai accumulato un backlog di dati molto grande e vuoi cancellarlo per liberare la quota del limite di burst, puoi procedere nel seguente modo:
- Acquista capacità aggiuntiva per aumentare i limiti.
- Disattivare feed specifici che hanno registrato un aumento inaspettato del volume.
Richiedi all'assistenza tecnica di Google SecOps di eliminare il backlog.
Per eliminare il backlog, il feed di dati viene temporaneamente disattivato finché tutte le richieste di ripetizione per i dati di riempimento non vengono elaborate correttamente. Durante questo periodo, non potrai importare nuovi dati.
Una volta eliminato il backlog, il feed viene riattivato e vedrai nuovi dati. A seconda delle dimensioni del backlog, l'operazione può richiedere da pochi minuti a qualche ora.
I limiti di burst si applicano anche all'importazione dati nella pipeline di elaborazione dei dati?
I limiti di velocità di importazione applicabili ai feed di dati che inviano dati dei log non elaborati nella pipeline di elaborazione dei dati di Google SecOps sono impostati su un valore superiore al limite di burst del tuo tenant.
Se superi il limite di burst, la pipeline di trattamento dei dati smette di accettare richieste aggiuntive, in base a quanto segue:
- Utilizzo di metodi basati sul pull: l'importazione viene memorizzata automaticamente nel buffer e non richiede alcuna configurazione aggiuntiva.
- Utilizzo di metodi basati sul push: Google SecOps rifiuta temporaneamente i dati con un errore HTTP 429 "Troppe richieste".
Tutti i dati trasformati dopo l'attivazione del limite di burst vengono temporaneamente memorizzati in una coda interna fino al ripristino del limite nella finestra di cinque minuti successiva.
Che cosa devo fare se il mio limite di burst è inferiore a quello previsto dal contratto?
Se il limite di burst è inferiore a quello previsto dal contratto, contatta l'Assistenza Google (vedi Assistenza Google SecOps) e indica il limite di burst previsto.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.