Problemas conhecidos do Eventarc Standard

O Gemini Code Assist só é suportado no VS Code com a extensão Gemini Code Assist + Cloud Code version+.

Esta página apresenta uma lista de problemas conhecidos do Eventarc Standard.

Também pode verificar se existem problemas ou abrir novos problemas nos rastreadores de problemas públicos.

  • Os acionadores criados recentemente podem demorar até dois minutos a ficarem operacionais.

  • Se atualizar um acionador antes de o evento gerado ser enviado, o evento é encaminhado de acordo com a filtragem anterior e enviado para o destino original no prazo de três dias após a geração do evento. A nova filtragem é aplicada aos eventos gerados após a atualização.

  • Existe uma transmissão duplicada conhecida de registos de auditoria do Cloud a partir de algumasorigens de eventos.Google Cloud Quando são publicados registos duplicados, os eventos duplicados são enviados para os destinos. Para evitar estes eventos duplicados, deve criar acionadores para campos que garantam que o evento é único. Isto aplica-se aos seguintes tipos de eventos:

    • 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)

    Tenha em atenção que, uma vez que os fluxos de trabalho processam a desduplicação de eventos, não tem de garantir que o evento é único quando cria um acionador para fluxos de trabalho.

  • Os acionadores entre projetos ainda não são suportados. O serviço que recebe os eventos para o acionador tem de estar no mesmo Google Cloud projeto Google Cloud que o acionador. Se os pedidos ao seu serviço forem acionados por mensagens publicadas num tópico do Pub/Sub, o tópico também tem de estar no mesmo projeto que o acionador. Veja Eventos de rotas em Google Cloud projetos.

  • Independentemente da localização real da instância da máquina virtual, os registos de auditoria na nuvem acionados pelo Compute Engine resultam em eventos originados numa única região: us-central1. Quando criar o acionador, certifique-se de que a localização do acionador está definida como us-central1 ou global.

  • Os eventos Pub/Sub diretos 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. Isto pode afetar a forma como lida com as falhas de mensagens.

  • Para alguns fornecedores de eventos, pode optar por codificar a carga útil do evento como application/json ou application/protobuf. No entanto, uma carga útil de eventos formatada em JSON é maior do que uma formatada em Protobuf, e isto pode afetar a fiabilidade consoante o destino do evento e os respetivos limites no tamanho do evento. Quando este limite é atingido, o evento é repetido de acordo com as características de repetição da camada de transporte do Eventarc, o Pub/Sub. Saiba como resolver falhas de mensagens do Pub/Sub se for feito o número máximo de tentativas.

  • Ao usar os fluxos de trabalho como destino de um acionador do Eventarc, os eventos superiores ao tamanho máximo dos argumentos dos fluxos de trabalho não acionam execuções de fluxos de trabalho. Para mais informações, consulte o artigo Quotas e limites.

  • O limite máximo de profundidade aninhada em cada entrada de registo estruturado para acionadores que usam os registos de auditoria do Google Cloud é de 64 níveis. Os eventos de registo que excedam este limite são ignorados e não são entregues pelo Eventarc.

  • Quando cria um acionador do Eventarc pela primeira vez num Google Cloud projeto, pode haver um atraso no aprovisionamento do agente do serviço Eventarc. Normalmente, pode resolver este problema tentando criar novamente o acionador. Para mais informações, consulte o artigo Erros de acesso negado.