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 funcionam como um limite de velocidade para a ingestão de dados. Eles foram criados 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 do Google SecOps com base no volume anual de ingestão 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, o limite de burst diário é provisionado como um intervalo específico, permitindo ingerir entre uma e três vezes (1× a 3×) sua média diária esperada (calculada como a 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 a capacidade anual comprada for de 365 TB, a média diária esperada será de 1 TB. O limite de burst provisionado vai estar 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 vezes, será necessário aumentar a capacidade anual comprada.

Os limites de burst são aplicados por locatário 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 do 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ário) 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 - 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 reduçã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 ultrarrápida, consulte Planejamento de capacidade personalizada para capacidade de processamento ultrarrápida.

Aplicabilidade dos 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 geral de burst por tipo de registro (em todos os feeds). Esse limite existe para garantir que a ingestão baseada em pull (geralmente de fontes na nuvem) não esgote os limites gerais de burst do seu locatário 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 para as APIs do Google SecOps).

Métodos de ingestão baseados em pull

Os métodos baseados em pull incluem métodos de ingestão (chamados de 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 fontes compatíveis com o Google SecOps:

  • APIs de terceiros
  • Hub de eventos do Azure
  • Ingestão direta do Google Workspace e do Google Cloud
  • Cloud Storage
  • Feed do Cloud Storage (baseado em eventos)
  • Amazon S3
  • Amazon SQS
  • Blobstore do Azure
  • Solicitação de SFTP
  • Solicitação HTTP

Por exemplo, se o limite de burst do seu locatário estiver definido como 150 MBps, e ele estiver ingerindo registros de contexto do usuário do Okta usando um conector de API de terceiros (ou seja, um método de ingestão baseado em pull), o sistema vai 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 é aplicado mesmo que sua taxa geral de ingestão de dados esteja dentro do limite de burst atribuído.

Exceções aos limites no nível do tipo de registro para métodos de ingestão baseados em pull

Embora os limites no nível do logtype geralmente se apliquem a feeds baseados em pull, as seguintes exceções se aplicam:

  • Webhooks HTTPS: é um método baseado em push com limites no nível do tipo de registro.
  • Hub de Eventos do Azure: é um método baseado em pull sem limites no nível do logtype.

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 for 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 no nível do tipo de registro são aplicados da mesma forma, 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 vai 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 exige nenhuma 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 "Too Many Requests". Isso sinaliza para o mecanismo de ingestão 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 é sua, o cliente (consulte Responsabilidades do cliente para armazenamento em buffer e novas tentativas 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 buffer de disco e lógica de novas tentativas adequados, atingir um limite de burst resulta apenas em um pequeno atraso (defasagem 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 para o buffer e a nova tentativa de dados

Embora o Google SecOps gerencie automaticamente o buffer de dados e as novas tentativas para dados ingeridos usando métodos de ingestão baseados em pull, 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).

É necessário 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 extração Ingestão baseada em push
Como funciona O Google SecOps entra em contato com a API de origem para buscar dados. Seus sistemas iniciam a conexão e enviam dados ao Google.
Responsabilidade pelo buffer e pela nova tentativa de dados O Google SecOps gerencia o buffer automaticamente. Quando o limite de burst é atingido, o Google SecOps pausa a ingestão de mais dados. Os dados permanecem armazenados no buffer até que o limite seja redefinido e o Google SecOps retome a busca.
O buffer armazena dados por até 90 dias, depois disso, eles são descartados.		 O cliente precisa gerenciar o buffer. Quando o Google SecOps responde com HTTP 429, seu sistema de envio precisa detectar esse erro, salvar os dados em uma fila local (disco ou memória) e tentar enviá-los 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 (acionado por 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, buffer e novas tentativas de dados.
Para mais informações, consulte Configurações de buffer e novas tentativas para sistemas baseados em push.

Quando os dados em buffer de 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 em tempo real em vez dos dados armazenados em buffer. Esse mecanismo garante que o backlog de dados armazenados em buffer não interfira no tráfego de dados em tempo real recebidos, o que pode aumentar os atrasos na detecção.

Como conferir seu limite de burst atribuído

Para determinar o limite de burst atribuído ao seu locatário do Google SecOps, faça o seguinte:

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

Use 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 da 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.

Use o Cloud Monitoring para acompanhar se você está se aproximando ou excedendo o limite de burst

Use 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 taxa de transferência.

As métricas relevantes incluem:

  • 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 console do Google Cloud , acesse Monitoring > Integrações.
  2. Selecione Chronicle Security na lista de integrações.
  3. Clique na guia Alertas.
  4. Revise e ative as seguintes políticas de alertas de exemplo:
    • Política de alertas de aproximação do limite da cota de ingestão: detecta se o volume de ingestão de dados está se aproximando do limite da cota.
    • Política de alerta 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.

Ver o uso do limite de burst

  • Para conferir o uso do limite de burst, use esta consulta do 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 esta consulta do 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 siga estas etapas:

  • Verifique o buffer: confira se as fontes de ingestão estão armazenando dados em buffer e tentando novamente.
  • Otimize 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 enormes 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.
  • Aguarde: para picos temporários, geralmente é suficiente esperar que a janela de cinco minutos seja redefinida e tentar novamente.

Para alguns exemplos de configurações, consulte Configurações de buffer e de novas tentativas para sistemas baseados em push.

Planejamento de capacidade personalizado para capacidade de processamento ultra-alta

Não obstante qualquer disposição nas outras seções deste documento, a capacidade de processamento de ingestão de dados que exceda 3 GBps é considerada capacidade de processamento ultrarrápida. Se você estiver planejando migrações de dados em grande escala, prevendo uma capacidade de processamento ultrarrápida sustentada ou executando arquiteturas que geram consistentemente grandes picos de ingestão, entre em contato com sua equipe de conta para fazer o provisionamento de capacidade personalizada.

Como a expansão da capacidade regional dedicada pode levar várias semanas para ser implantada, notifique o suporte do Google Cloud pelo menos 90 dias antes dos eventos extremos de ingestão 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 no nível do logtype para feeds baseados em extração?

É possível aumentar os limites no nível do logtype para um logtype específico fazendo uma solicitação com antecedência usando o suporte técnico do Google SecOps.

Aumentar o limite no nível do logtype para um logtype não muda o limite aplicado a outros logtypes 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 mais capacidade para aumentar seus limites.
  • Desativar feeds específicos que tiveram um aumento inesperado no volume.

  • Peça ao suporte técnico do Google SecOps para reduzir o backlog.

    Para reduzir o backlog, seu 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, seu 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 processamento de dados do Google SecOps são definidos para serem maiores do que o limite de burst do seu locatário.

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

  • Usar 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 "Too Many Requests".

Todos os dados transformados depois que o limite de burst é acionado 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.