Problemi noti di Eventarc Standard

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.

Provisioning e tempistiche

  • Tempo di deployment del trigger: i trigger appena creati possono richiedere fino a due minuti per diventare operativi.

  • Provisioning dell'agente di servizio: quando crei un trigger Eventarc per la prima volta in un progetto Google 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ù, consulta la sezione Errori di autorizzazione negata.

Configurazione del trigger

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

  • Trigger Cloud Audit Logs per Compute Engine: indipendentemente da dove si trova effettivamente l'istanza di macchina virtuale, i trigger 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.

  • Trigger Cloud Storage in località multiregionali: i trigger Cloud Storage possono non funzionare se un evento Cloud Storage ha origine da una regione non consentita dalla policy di archiviazione dei messaggi Pub/Sub e se le operazioni in transito vengono applicate ("enforceInTransit": true). Quando crei un trigger Cloud Storage in una località multiregionale, assicurati che la policy di archiviazione dei messaggi consenta tutte le regioni di origine all'interno di quella multiregionale. Queste norme definiscono dove vengono archiviati i messaggi durante la consegna e dove vengono applicate le operazioni in transito. Per saperne di più, consulta Configurare le policy di archiviazione dei messaggi.

  • Aggiornamento di un attivatore: se aggiorni un attivatore 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.

Payload e distribuzione degli eventi

  • Trasmissione duplicata di Cloud Audit Logs: è nota una trasmissione duplicata di Cloud Audit Logs da alcune origini eventi Google Cloud . 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.

  • Gestione degli errori dei messaggi per gli eventi Pub/Sub diretti: 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.

  • Codifica payload evento: per alcuni fornitori di eventi, puoi scegliere di codificare il payload 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 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.

Destinazioni e limiti

  • Dimensioni degli argomenti di Workflows: quando utilizzi Workflows come destinazione per un trigger Eventarc, gli eventi più grandi delle dimensioni massime degli argomenti di Workflows non attiveranno l'esecuzione del flusso di lavoro. Per saperne di più, consulta Quote e limiti.

  • Limite di profondità nidificata per le voci di log: il limite di profondità nidificata 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.