Entender as cotas e os limites de burst
Este documento descreve as cotas e os limites de burst no Google Security Operations.
Definição de limites de burst
Os limites de burst são uma forma de limites de serviço no Google SecOps que atuam como um limite de velocidade para a ingestão de dados, projetados para proteger a infraestrutura compartilhada da plataforma contra picos repentinos e massivos de tráfego. Um limite de burst restringe a taxa de ingestão (medida em megabytes por segundo, MBps, ou gigabytes por segundo, GBps) em uma janela móvel de cinco minutos.
Como os limites de burst são calculados
O Google SecOps atribui limites de burst aos seus tenants com base no volume de ingestão anual comprado (capacidade adquirida) de acordo com sua licença do Google SecOps.
Para acomodar variações esperadas e picos não planejados no tráfego de registros, seu limite de burst diário é provisionado como um intervalo específico, permitindo que você ingira entre uma e três vezes (1× a 3×) sua média diária esperada (calculada como sua capacidade anual comprada dividida por 365 dias). Essa permissão de volume flexível foi projetada para absorver picos de ingestão padrão sem interromper suas operações. Por exemplo, se sua capacidade anual comprada for de 365 TB, sua média diária esperada será de 1 TB. Seu limite de burst provisionado ficará estritamente dentro do intervalo de 1 TB a 3 TB por dia (o que se traduz em um intervalo de capacidade de processamento de aproximadamente 12 MBps a 36 MBps). Se a ingestão de dados exceder consistentemente esse intervalo provisionado de 1× a 3×, será necessário aumentar sua capacidade anual comprada.
Os limites de burst são aplicados por tenant do cliente do Google SecOps.
A tabela a seguir mostra como os limites de burst correspondem a diferentes quantidades de capacidade comprada:
| Exemplo de capacidade comprada | Intervalo de limite de burst | Limite de burst de 5 minutos | Ingestão no limite máximo de burst (por hora) | Ingestão no limite máximo de burst (diária) | Ingestão no limite máximo de burst (anual) |
|---|---|---|---|---|---|
| 100 TB | 3 a 10 MBps | 0,9 a 3 GB | ~34 GB | ~822 GB | 300 TB |
| 500 TB | 16 a 48 MBps | 4,8 a 14,4 GB | ~171 GB | ~4 TB | 1,5 PB |
| 1 PB | 32 a 97 MBps | 9,6 a 29 GB | ~343 GB | ~8 TB | 3 PB |
| 5 PB | 158 a 476 MBps | 47,4 a 143 GB | ~1,7 TB | ~41 TB | 15 PB |
| 30 PB | 0,96 a 2,86 GBps | 288 a 858 GB | ~10,3 TB | ~247 TB | 90 PB |
O tráfego de ingestão que inclui picos de velocidade extremos e repentinos pode estar sujeito a limitação de taxa dinâmica ou limitação temporária para proteger a estabilidade regional.
Durante esses períodos, os dados podem sofrer atrasos na ingestão até que o pico diminua.
Para requisitos de capacidade de processamento ultra-alta, consulte Planejamento de capacidade personalizada para capacidade de processamento ultra-alta.
Aplicabilidade de limites de burst para feeds baseados em pull
O Google SecOps também limita a ingestão baseada em pull a um terço (33%) do limite de burst geral por tipo de registro (em todos os feeds). Esse limite existe para garantir que a ingestão baseada em pull (geralmente de fontes de nuvem) não esgote os limites de burst gerais do tenant e prejudique a ingestão de dados usando métodos baseados em push (como o uso de agentes, encaminhadores ou ingestão direta do Bindplane nas APIs do Google SecOps).
Métodos de ingestão baseados em pull
Os métodos baseados em pull incluem métodos de ingestão (referidos como tipos de origem no Google SecOps) em que o Google SecOps entra em contato ativamente com a API de origem para buscar dados. Isso inclui os seguintes tipos de origem compatíveis com o Google SecOps:
- APIs de terceiros
- Hub de eventos do Azure
- Ingestão direta do Google Workspace e Google Cloud
- Cloud Storage
- Feed do Cloud Storage (orientado a eventos)
- Amazon S3
- Amazon SQS
- Azure Blobstore
- Solicitação SFTP
- Solicitação HTTP
Por exemplo, se o limite de burst do seu tenant estiver definido como 150 MBps e ele estiver ingerindo registros de contexto do usuário do Okta usando um conector de API de terceiros (que é um método de ingestão baseado em pull), o sistema limitará a taxa de ingestão de todos os feeds do Okta combinados a um máximo de [150/3 =] 50 MBps. Esse limite adicional será aplicado mesmo que sua taxa geral de ingestão de dados esteja dentro do limite de burst atribuído.
Exceções aos limites de tipo de registro para métodos de ingestão baseados em pull
Embora os limites de tipo de registro geralmente se apliquem a feeds baseados em pull, as seguintes exceções se aplicam:
- Webhooks HTTPS: esse é um método baseado em push com limites de tipo de registro.
- Hub de eventos do Azure: esse é um método baseado em pull sem limites de tipo de registro.
Como os limites de burst são implementados
O sistema aplica limites de burst em intervalos de cinco minutos. Por exemplo, se o limite de burst estiver definido como 50 MBps, você poderá ingerir até 15 GB a cada cinco minutos. Se você ingerir todos os 15 GB nos primeiros dois minutos, a ingestão será bloqueada nos três minutos restantes dessa janela. Esse limite é redefinido automaticamente no início do próximo intervalo de cinco minutos.
Os limites de tipo de registro são aplicados da mesma maneira, mas no nível de tipos de registro individuais. Por exemplo, se você tiver 5 GB alocados para feeds baseados em pull a cada cinco minutos e o volume total de dados ingeridos para qualquer tipo de registro exceder 5 GB nos primeiros dois minutos, a ingestão será pausada nos três minutos restantes dessa janela. O limite é redefinido automaticamente no início do próximo intervalo de cinco minutos.
O que acontece com seus dados se você exceder os limites de burst
Se você exceder o limite de burst, o Google SecOps pausará a ingestão de dados adicionais, e os seguintes mecanismos serão acionados, dependendo se os dados estão sendo ingeridos usando métodos baseados em pull ou push:
- Usando métodos baseados em pull: a ingestão é armazenada em buffer automaticamente e não requer configuração adicional do cliente. Os dados permanecem armazenados no armazenamento de buffer até que o limite seja redefinido e o Google SecOps retome a ingestão de dados.
- Usando métodos baseados em push: o Google SecOps rejeita temporariamente a ingestão de dados com um erro HTTP 429 "Muitas solicitações". Isso sinaliza que o mecanismo de ingestão deve pausar, armazenar em buffer e tentar novamente, garantindo que nenhum dado seja perdido.
Ao usar métodos de ingestão baseados em push, a responsabilidade de armazenar em buffer e tentar novamente é do cliente (consulte Responsabilidades do cliente pelo armazenamento em buffer e pela nova tentativa de dados).
As rejeições de limite de burst não são perda de dados
É importante entender que as rejeições de limite de burst (HTTP 429) não são eventos de perda de dados. Uma rejeição de limite de burst (erro HTTP 429) é uma pausa na ingestão de dados.
Ao garantir que seus sistemas baseados em push tenham armazenamento em buffer de disco e lógica de nova tentativa adequados, atingir um limite de burst resulta apenas em um pequeno atraso (atraso de ingestão), nunca na perda permanente de telemetria de segurança.
A perda de dados só ocorre se o sistema de envio (por exemplo, o agente do Bindplane, o encaminhador ou o script) ignorar o erro de rejeição do limite de burst e excluir a entrada de registro em vez de armazená-la para uma nova tentativa.
Responsabilidades do cliente pelo armazenamento em buffer e pela nova tentativa de dados
Embora o Google SecOps gerencie automaticamente o armazenamento em buffer e as novas tentativas de dados ingeridos usando métodos baseados em pull, você é responsável pelo armazenamento em buffer e pela nova tentativa de ingestão de dados usando métodos baseados em push (como webhooks HTTPS, Bindplane, encaminhadores ou Cribl).
Você precisa configurar seus sistemas para armazenar em buffer e reenviar dados automaticamente quando o limite de burst for atingido para lidar com o estouro de dados de maneira eficiente.
A tabela a seguir destaca as principais diferenças na forma como o Google SecOps processa a ingestão de dados quando o limite de burst é atingido para os dois tipos de métodos de ingestão:
| Recurso | Ingestão baseada em pull | Ingestão baseada em push |
|---|---|---|
| Como funciona | O Google SecOps entra em contato ativamente com a API de origem para buscar dados. | Seus sistemas iniciam a conexão e enviam dados ao Google. |
| Responsabilidade pelo armazenamento em buffer e pela nova tentativa de dados | O Google SecOps gerencia o armazenamento em buffer automaticamente. Quando o limite de burst é atingido, o Google SecOps pausa a ingestão de dados adicionais. Os dados permanecem armazenados no armazenamento de buffer até que o limite seja redefinido e o Google SecOps retome a busca. O armazenamento de buffer armazena dados por até 90 dias, após os quais os dados são descartados. |
O cliente precisa gerenciar o armazenamento em buffer. Quando o Google SecOps responde com HTTP 429, o sistema de envio precisa detectar esse erro, salvar os dados em uma fila local (disco ou memória) e tentar enviá-los novamente mais tarde. Se o remetente estiver definido como "descartar em caso de falha", os dados serão perdidos. |
| Tipos de fontes de dados | API de terceiros, Hub de eventos do Azure, ingestão direta do Google Workspace e Google Cloud, Cloud Storage, feed do Cloud Storage (orientado a eventos), Amazon S3, Amazon SQS, Azure Blobstore, solicitação SFTP, solicitação HTTP. | Encaminhador do Google SecOps, agente do Bindplane, Pub/Sub, Amazon Kinesis Firehose, webhook HTTPS, direto para a API de ingestão. |
| Ação do usuário | Tome medidas para alinhar o volume de ingestão de dados com a capacidade comprada. | Além disso, verifique se as fontes de ingestão estão configuradas para retenção, armazenamento em buffer e novas tentativas de dados. Para mais informações, consulte Configurações de armazenamento em buffer e novas tentativas para sistemas baseados em push. |
Quando os dados armazenados em buffer para feeds baseados em pull são preenchidos
Para feeds que usam métodos de ingestão baseados em pull, quando a janela de limite de burst é redefinida, o Google SecOps preenche os dados armazenados em buffer, priorizando os dados ativos em relação aos dados armazenados em buffer. Esse mecanismo garante que o backlog de dados armazenados em buffer não interfira no tráfego de dados ativos recebidos (o que pode agravar os atrasos na detecção).
Como visualizar o limite de burst atribuído
Para determinar o limite de burst atribuído ao seu tenant do Google SecOps, faça o seguinte:
- No console do Google SecOps, acesse Painéis > Ingestão e integridade de dados.
- Consulte o Gráfico de limite de burst – Limite de cota. O gráfico mostra o limite atribuído (a linha reta) em relação à taxa de ingestão real.
Acompanhar se você está se aproximando ou excedendo o limite de burst
É possível acompanhar a utilização usando os painéis integrados ou o Cloud Monitoring.
Usar os painéis do Google SecOps para acompanhar se você está se aproximando ou excedendo o limite de burst
Acesse Painéis > Ingestão e integridade de dados e consulte o seguinte:
- Gráfico de taxa de ingestão: mostra sua capacidade atual.
- Gráfico de rejeição de burst: mostra o volume de registros rejeitados (erros HTTP 429) devido ao excesso do limite de burst.
Usar o Cloud Monitoring para acompanhar se você está se aproximando ou excedendo o limite de burst
É possível usar o Metrics Explorer em Google Cloud para criar alertas personalizados. Recomendamos criar um alerta de ingestão que notifique você quando o volume de bytes ingeridos exceder o limite de burst.
As métricas relevantes incluem o seguinte:
- Volume ingerido:
chronicle.googleapis.com/ingestion/log/bytes_count - Volume rejeitado:
chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count
As seções a seguir contêm exemplos de consultas PromQL para monitoramento e alertas.
Ver o uso do limite de burst
Para ver o uso do limite de burst, use a seguinte consulta 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]))
Ver o número de bytes rejeitados após exceder o limite de burst
Para ver o número de bytes rejeitados após exceder o limite de burst, use a seguinte consulta 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}])))
Acionar um alerta quando você atingir 70% do limite de burst
Para acionar um alerta quando você atingir 70% do limite de burst, use a seguinte consulta 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
Para mais informações sobre como configurar alertas de ingestão, consulte Usar o Cloud Monitoring para insights de ingestão.
Processar rejeições de limite de burst causadas por métodos baseados em push
Se você encontrar erros de rejeição (HTTP 429) devido ao limite de burst para dados recebidos usando métodos baseados em push, recomendamos que você siga estas etapas:
- Verificar o armazenamento em buffer: verifique se as fontes de ingestão estão armazenando dados em buffer e tentando novamente.
- Otimizar a ingestão: revise os scripts de ingestão e verifique se eles não estão enviando dados desnecessários ou sobrecarregando a API com lotes massivos de uma só vez. Distribua os uploads de dados históricos, se possível. Filtre dados redundantes usando o recurso de pipeline de processamento de dados.
- Aguardar: para picos temporários, geralmente é suficiente aguardar a redefinição da janela de cinco minutos e tentar novamente.
Para alguns exemplos de configurações, consulte Configurações de armazenamento em buffer e novas tentativas para sistemas baseados em push.
Planejamento de capacidade personalizada para capacidade de processamento ultra-alta
Sem prejuízo de qualquer descrição nas outras seções deste documento, a capacidade de ingestão de dados que exceda 3 GBps é considerada capacidade de processamento ultra-alta. Se você estiver planejando migrações de dados em grande escala, prevendo capacidade de processamento ultra-alta sustentada ou executando arquiteturas que geram bursts de ingestão massivos de forma consistente, entre em contato com a equipe da sua conta para provisionamento de capacidade personalizada.
Como a expansão da capacidade regional dedicada pode levar várias semanas para ser implantada, notifique o Google Cloud suporte com pelo menos 90 dias de antecedência dos eventos de ingestão extremos previstos para garantir que seus requisitos de capacidade de processamento possam ser atendidos.
Perguntas frequentes
As seções a seguir fornecem respostas para perguntas frequentes.
Posso aumentar meu limite de burst?
Se você espera que o volume de ingestão de dados aumente permanentemente, entre em contato com seu representante de vendas do Google SecOps para aumentar a capacidade comprada.
Posso aumentar os limites de tipo de registro para feeds baseados em pull?
É possível aumentar os limites de tipo de registro para um tipo de registro específico fazendo uma solicitação ao suporte técnico do Google SecOps com antecedência.
Aumentar o limite de tipo de registro para um tipo de registro não altera o limite aplicado a outros tipos de registro ou o limite de burst geral.
É possível acompanhar meu backlog de dados?
Por enquanto, não.
Quais são as maneiras possíveis de limpar meu backlog de dados?
Se você acumulou um backlog de dados muito grande e quer limpar esse backlog para liberar sua cota de limite de burst, faça o seguinte:
- Compre capacidade adicional para aumentar seus limites.
- Desative feeds específicos que tiveram um pico inesperado de volume.
Peça ao suporte técnico do Google SecOps para descartar seu backlog.
Para descartar o backlog, o feed de dados é desativado temporariamente até que todas as solicitações de nova tentativa de dados preenchidos sejam processadas. Durante esse período, não será possível ingerir novos dados.
Depois que o backlog for limpo, o feed será reativado, e você verá novos dados chegando. Dependendo do tamanho do backlog, isso pode levar de alguns minutos a algumas horas.
Os limites de burst também se aplicam à ingestão de dados no pipeline de processamento de dados?
Os limites de taxa de ingestão aplicáveis a feeds de dados que enviam dados de registros brutos para o pipeline de processamento de dados do Google SecOps são definidos para serem maiores que o limite de burst do tenant.
Se você exceder o limite de burst, o pipeline de processamento de dados vai parar de aceitar solicitações adicionais, de acordo com o seguinte:
- Usando métodos baseados em pull: a ingestão é armazenada em buffer automaticamente e não requer configuração adicional.
- Usando métodos baseados em push: o Google SecOps rejeita temporariamente os dados com um erro HTTP 429 "Muitas solicitações".
Todos os dados transformados após o acionamento do limite de burst são armazenados temporariamente em buffer em uma fila interna até que o limite seja redefinido na janela de cinco minutos subsequente.
O que devo fazer se meu limite de burst for menor do que o contratado?
Se o limite de burst for menor do que o contratado, entre em contato com o suporte do Google (consulte Suporte do Google SecOps) e inclua o limite de burst esperado.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.