Entender as cotas e os limites de burst

Compatível com:

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 contínua de cinco minutos.

Como os limites de burst são calculados

O Google SecOps atribui limites de burst aos seus tenants do Google SecOps com base no volume de ingestão anual comprado (capacidade comprada) 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 de uma a 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 extração

O Google SecOps também limita a ingestão baseada em extração 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 extração (geralmente de fontes de nuvem) não esgote os limites de burst gerais do seu 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 extração

Os métodos baseados em extração 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 com suporte no 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 extração), 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

Embora os limites de tipo de registro geralmente se apliquem a feeds baseados em extração, as seguintes exceções se aplicam:

  • Webhooks HTTPS: esse método de ingestão é baseado em push e não está sujeito a limites de tipo de registro. No entanto, ele está sujeito ao limite de burst geral do tenant do cliente e retorna um código de status HTTP 429 quando um feed excede esse limite.
  • Hub de Eventos do Azure: esse é um método de ingestão baseado em extração que não está sujeito a 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 extração 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 extração ou push:

  • Usando métodos baseados em extração: a ingestão é armazenada em buffer automaticamente e não exige configuração adicional do cliente. Os dados permanecem armazenados no 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 buffer de dados e pela nova tentativa).

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 da 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 buffer de dados e pela nova tentativa

Embora o Google SecOps gerencie automaticamente o buffer de dados e as novas tentativas de dados ingeridos usando métodos baseados em extração, você é responsável pelo buffer de dados 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 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 extração 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 buffer de dados e pela nova tentativa 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 buffer até que o limite seja redefinido e o Google SecOps retome a busca.
O armazenamento em 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 Ingestion.
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 de dados, armazenamento em buffer e novas tentativas.
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 extração são preenchidos

Para feeds que usam métodos de ingestão baseados em extração, 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:

  1. No console do Google SecOps, acesse Painéis > Ingestão e integridade de dados.
  2. Confira 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 confira o seguinte:

    • Gráfico de taxa de ingestão: mostra sua capacidade de processamento atual.
    • Gráfico de rejeição de burst: mostra o volume de registros rejeitados (erros HTTP 429) devido ao limite de burst excedido.

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

Políticas de alertas prontas para uso

O Google SecOps oferece políticas de alertas prontas para uso no Cloud Monitoring que podem ser ativadas para monitorar sua cota de ingestão.

Para encontrar e ativar essas políticas, siga estas etapas:

  1. No Google Cloud console do, acesse Monitoring > Integrações.
  2. Selecione Segurança do Chronicle na lista de integrações.
  3. Clique na guia Alertas.
  4. Analise e ative as seguintes políticas de alertas de exemplo:
    • Política de alertas de limite de cota de ingestão se aproximando: detecta se o volume de ingestão de dados está se aproximando do limite de cota.
    • Política de alertas de rejeição de cota de ingestão: detecta se as solicitações de ingestão estão sendo rejeitadas devido à cota de ingestão insuficiente (erros HTTP 429).

Exemplos

As seções a seguir contêm exemplos de consultas PromQL para monitoramento e alertas.

Conferir o uso do limite de burst

  • Para conferir 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]))

Conferir o número de bytes rejeitados após exceder o limite de burst

  • Para conferir 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 monitorar o volume de ingestão diário em relação aos limites contratuais, use a métrica Tamanho total do registro ingerido (chronicle.googleapis.com/ingestion/log/bytes_count).

Para instruções sobre como configurar uma política de alertas de volume diário, consulte Configurar uma política de exemplo para monitorar o volume de ingestão diário. Para instruções sobre como configurar outros alertas de ingestão, consulte Analisar a ingestão com o Cloud Monitoring.

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. Se possível, distribua os uploads de dados históricos. Filtre dados redundantes usando o recurso de pipeline de tratamento 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

Apesar de tudo o que foi descrito nas outras seções deste documento, a capacidade de processamento de ingestão de dados que excede 3 GBps é considerada capacidade de processamento ultra-alta. Se você estiver planejando migrações de dados em grande escala, prevendo alta 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 de conta para provisionamento de capacidade personalizada.

Como a expansão da capacidade regional dedicada pode levar várias semanas para ser implantada, notifique Google Cloud o 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 o representante de vendas do Google SecOps para aumentar a capacidade comprada.

Posso aumentar os limites de tipo de registro para feeds baseados em extração?

Você pode aumentar os limites de tipo de registro para um tipo de registro específico fazendo uma solicitação com antecedência usando o suporte técnico do Google SecOps.

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 no 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 tratamento de dados?

Os limites de taxa de ingestão aplicáveis aos feeds de dados que enviam dados de registros brutos para o pipeline de tratamento de dados do Google SecOps são definidos para serem maiores que o limite de burst do seu tenant.

Se você exceder o limite de burst, o pipeline de tratamento de dados vai parar de aceitar outras solicitações, de acordo com o seguinte:

  • Usando métodos baseados em extração: a ingestão é armazenada em buffer automaticamente e não exige 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.