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 mobile 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 imprevisti nel traffico di log, il limite di burst giornaliero viene fornito come intervallo specifico, che ti consente di importare una quantità di dati compresa tra una e tre volte (da 1× a 3×) la media giornaliera prevista (calcolata come capacità annuale acquistata divisa per 365 giorni). Questa quota flessibile di volumi è progettata per assorbire i picchi di importazione standard senza interrompere le tue operazioni. Ad esempio, se la capacità annuale acquistata è di 365 TB, la media giornaliera prevista è di 1 TB. Il limite di burst di cui è stato eseguito il 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 MB/s a 36 MB/s). 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 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 burst di 5 minuti | Importazione al limite massimo di burst (orario) | Importazione al limite massimo di burst (giornaliero) | Importazione 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 | ~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 dinamica o throttling temporaneo per proteggere la stabilità regionale.
Durante questi periodi, i dati potrebbero subire ritardi nell'importazione finché 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'importazione 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, forwarder o importazione diretta di Bindplane 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 di 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à complessiva di importazione dati rientra nel limite di burst assegnato.
Eccezioni ai limiti a livello di tipo di log per i metodi di importazione basati sul pull
Sebbene i limiti a livello di tipo di log si applichino generalmente ai feed basati sul pull, si applicano le seguenti eccezioni:
- Webhook HTTPS: si tratta di un metodo basato sul push con limiti a livello di tipo di log.
- Azure Event Hub: si tratta di un metodo basato sul pull senza 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 cinque minuti. Se inserisci tutti i 15 GB nei primi due minuti, l'inserimento viene bloccato per i tre minuti rimanenti di quella finestra. Questo limite viene reimpostato 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 allocati 5 GB per i feed basati sul pull ogni cinque minuti e il volume totale di 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 azzerato 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 nella memoria buffer fino al ripristino del limite e alla ripresa dell'importazione dei dati da parte di Google SecOps.
- 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 nessun dato venga perso.
Se utilizzi metodi di importazione basati sul push, la responsabilità di memorizzare nel buffer e riprovare spetta a te, il 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 sul 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 per i dati importati utilizzando metodi di importazione basati sul pull, sei responsabile del buffering e dei nuovi importazione dati utilizzando metodi di importazione basati sul push (come webhook HTTPS, Bindplane, forwarder o Cribl).
Per gestire in modo efficiente l'overflow di dati, devi configurare i tuoi sistemi in modo che memorizzino automaticamente i dati nel buffer e li inviino di nuovo quando viene raggiunto il limite di burst.
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 importazione:
| 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 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 memorizzati nell'archivio buffer fino al ripristino del limite e alla ripresa del recupero da parte di Google SecOps. L'archivio 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 "Elimina in caso di errore", 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, API di importazione diretta. |
| Azione 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 ti stai avvicinando o superando il limite di burst
Vai a Dashboard > Inserimento e integrità dei dati e visualizza quanto segue:
- Grafico della velocità di importazione: mostra la velocità effettiva attuale.
- Grafico dei rifiuti in burst: mostra il volume di log rifiutati (errori HTTP 429) a causa del superamento del limite di burst.
Utilizza Cloud Monitoring per monitorare se ti stai avvicinando o superando il limite di burst
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
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]))
Visualizzare 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 del 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 enormi 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 sistemi basati su push.
Pianificazione della capacità personalizzata per una velocità effettiva ultra elevata
Nonostante quanto descritto nelle altre sezioni di questo documento, il throughput di importazione dati superiore a 3 GB/s è considerato throughput ultra elevato. Se prevedi migrazioni di dati su larga scala, un throughput ultra elevato e sostenuto o esegui architetture che generano costantemente picchi 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 essere implementata, comunica Google Cloud al team di 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 seguenti sezioni 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 utilizzando 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 miei dati?
Al momento non è possibile.
Quali sono i possibili modi per eliminare l'arretrato dei 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.
- Disattiva feed specifici che hanno registrato un aumento imprevisto del volume.
Richiedi l'assistenza tecnica di Google SecOps per eliminare il backlog.
Per eliminare il backlog, il feed di dati viene temporaneamente disattivato finché tutte le richieste di nuovi tentativi 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 diverse ore.
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 trattamento 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 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.
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.