Problemas conhecidos do Eventarc Standard

Esta página lista problemas conhecidos do Eventarc Standard.

Você também pode verificar problemas existentes ou abrir novos nos issue trackers públicos.

Provisionamento e tempo

  • Tempo de implantação do gatilho: os gatilhos recém-criados podem levar até dois minutos para entrar em operação.

  • Provisionamento do agente de serviço: ao criar um gatilho do Eventarc pela primeira vez em um projeto do Google Cloud , pode haver um atraso no provisionamento do agente de serviço do Eventarc. Esse problema geralmente pode ser resolvido ao tentar criar o acionador novamente. Para mais informações, consulte Erros de permissão negada.

Configuração do gatilho

  • Gatilhos entre projetos: ainda não há suporte para gatilhos entre projetos. O serviço que recebe os eventos do gatilho precisa estar no mesmo projetoGoogle Cloud que o gatilho. Se as solicitações para o serviço forem acionadas por mensagens publicadas em um tópico do Pub/Sub, o tópico também precisará estar no mesmo projeto que o gatilho. Consulte Encaminhar eventos entre projetos do Google Cloud .

  • Gatilhos dos Registros de auditoria do Cloud para o Compute Engine: independentemente de onde a instância da máquina virtual está localizada, os gatilhos dos Registros de auditoria do Cloud para o Compute Engine resultam em eventos originados de uma única região: us-central1. Ao criar o gatilho, verifique se o local dele está definido como us-central1 ou global.

  • Gatilhos do Cloud Storage em locais multirregionais: os gatilhos do Cloud Storage podem falhar se um evento do Cloud Storage for originado em uma região não permitida pela política de armazenamento de mensagens do Pub/Sub e se as operações em trânsito forem aplicadas ("enforceInTransit": true). Ao criar um gatilho do Cloud Storage em um local multirregional, verifique se a política de armazenamento de mensagens permite todas as regiões de origem nessa multirregião. Essa política define onde as mensagens são armazenadas durante a entrega e onde as operações em trânsito são aplicadas. Para mais informações, consulte Configurar políticas de armazenamento de mensagens.

  • Atualizar um gatilho: se você atualizar um gatilho antes da entrega do evento gerado, o evento será encaminhado de acordo com a filtragem anterior e entregue ao destino original até três dias após a geração do evento. A nova filtragem é aplicada a eventos gerados após a atualização.

Payloads e entrega de eventos

  • Transmissão duplicada dos registros de auditoria do Cloud: há uma transmissão duplicada conhecida dos registros de auditoria do Cloud de algumas origens de eventos do Google Cloud . Quando registros duplicados são publicados, eventos duplicados são enviados aos destinos. Para evitar esses eventos duplicados, crie gatilhos para campos que garantam que o evento seja único. Isso se aplica aos seguintes tipos de evento:

    • Cloud Storage (serviceName: storage.googleapis.com), methodName: storage.buckets.list
    • Compute Engine (serviceName: compute.googleapis.com), methodName: beta.compute.instances.insert
    • BigQuery (serviceName: bigquery.googleapis.com)

    Como o Workflows lida com a eliminação de duplicação de eventos, você não precisa garantir que o evento seja exclusivo ao criar um gatilho para o Workflows.

  • Como processar falhas de mensagens para eventos diretos do Pub/Sub: Eventos diretos do Pub/Sub não incluem um campo delivery_attempt a menos que o destino do evento seja o Cloud Run ou as funções do Cloud Run. Isso pode afetar seu processamento de falhas de mensagens.

  • Codificação do payload do evento: para alguns provedores de eventos, é possível codificar o payload do evento como application/json ou application/protobuf. No entanto, um payload de evento formatado em JSON é maior que um formatado em Protobuf, e isso pode afetar a confiabilidade, dependendo do destino do evento e dos limites de tamanho dele. Quando esse limite é atingido, ocorre uma nova tentativa do evento de acordo com as características de novas tentativas da camada de transporte do Eventarc, o Pub/Sub. Saiba como lidar com falhas de mensagens do Pub/Sub quando o número máximo de tentativas foi atingido.

Destinos e limites

  • Tamanho dos argumentos do Workflows: ao usar o Workflows como destino para um gatilho do Eventarc, eventos maiores que o tamanho máximo dos argumentos do Workflows não vão acionar as execuções de fluxo de trabalho. Para mais informações, consulte Cotas e limites.

  • Limite de profundidade aninhada para entradas de registro: o limite máximo de profundidade aninhada em cada entrada de registro estruturado para gatilhos que usam os Registros de auditoria do Cloud é de 64 níveis. Os eventos de registro que excedem esse limite são descartados e não são entregues pelo Eventarc.