Problemi noti di Eventarc Standard

Gemini Code Assist è supportato solo in VS Code con l'estensione Gemini Code Assist + Cloud Code version+.

Questa pagina elenca i problemi noti di Eventarc Standard.

Puoi anche verificare la presenza di problemi esistenti o aprirne di nuovi negli strumenti Issue Tracker pubblici.

  • L'attivazione dei trigger appena creati può richiedere fino a due minuti.

  • Se aggiorni un trigger prima che venga inviato l'evento generato, l'evento viene indirizzato in base al filtro precedente e inviato alla destinazione originale entro tre giorni dalla generazione dell'evento. Il nuovo filtro viene applicato agli eventi generati dopo l'aggiornamento.

  • È nota la trasmissione duplicata di Cloud Audit Logs da alcune Google Cloud origini eventi. Quando vengono pubblicati log duplicati, gli eventi duplicati vengono inviati alle destinazioni. Per evitare questi eventi duplicati, devi creare trigger per i campi che garantiscono l'unicità dell'evento. Ciò si applica ai seguenti tipi di eventi:

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

    Tieni presente che, poiché Workflows gestisce la deduplicazione degli eventi, non devi assicurarti che l'evento sia univoco quando crei un trigger per Workflows.

  • Gli attivatori multiprogetto non sono ancora supportati. Il servizio che riceve gli eventi per il trigger deve trovarsi nello stesso Google Cloud progetto del trigger. Se le richieste al tuo servizio vengono attivate da messaggi pubblicati in un argomento Pub/Sub, l'argomento deve trovarsi nello stesso progetto del trigger. Consulta Eventi di routing in più progetti. Google Cloud

  • Indipendentemente dalla posizione effettiva dell'istanza di macchina virtuale, i trigger di Cloud Audit Logs per Compute Engine generano eventi provenienti da una singola regione: us-central1. Quando crei il trigger, assicurati che la posizione del trigger sia impostata su us-central1 o global.

  • Gli eventi Pub/Sub diretti non includono un campo delivery_attempt a meno che la destinazione dell'evento non sia Cloud Run o Cloud Run Functions. Ciò potrebbe influire sulla gestione degli errori relativi ai messaggi.

  • Per alcuni fornitori di eventi, puoi scegliere di codificare il payload dell'evento come application/json o application/protobuf. Tuttavia, un payload evento formattato in JSON è più grande di uno formattato in Protobuf, e ciò potrebbe influire sull'affidabilità a seconda della destinazione dell'evento e dei relativi limiti di dimensione dell'evento. Quando viene raggiunto questo limite, l'evento viene ritentato in base alle caratteristiche di ripetizione dei tentativi del livello di trasporto di Eventarc, Pub/Sub. Scopri come gestire gli errori dei messaggi Pub/Sub se viene effettuato il numero massimo di tentativi.

  • Quando utilizzi Workflows come destinazione per un trigger Eventarc, gli eventi più grandi della dimensione massima degli argomenti di Workflows non attiveranno le esecuzioni del flusso di lavoro. Per ulteriori informazioni, consulta Quote e limiti.

  • Il limite di profondità di nidificazione massimo per ogni voce di log strutturata per i trigger che utilizzano Cloud Audit Logs è di 64 livelli. Gli eventi di log che superano questo limite vengono eliminati e non vengono recapitati da Eventarc.

  • Quando crei un trigger Eventarc per la prima volta in un progettoGoogle Cloud , potrebbe verificarsi un ritardo nel provisioning dell'agente di servizio Eventarc. Questo problema può essere risolto in genere provando a creare di nuovo il trigger. Per saperne di più, vedi Errori di autorizzazione negata.