Problemi noti di Eventarc Standard

Le limitazioni, i sintomi e le soluzioni alternative attuali per Eventarc Standard ti aiutano a identificare e mitigare i problemi operativi.

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

Provisioning e tempistiche

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

  • Provisioning del service agent: quando crei un trigger Eventarc per la prima volta in un progetto Google Cloud , potrebbe verificarsi un ritardo nel provisioning del service agent 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 tra progetti: i trigger tra progetti 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 Instradare gli eventi tra i 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 dai criteri 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 i criteri di archiviazione dei messaggi consentano tutte le regioni di origine all'interno di quella multiregionale. Questo criterio definisce dove vengono archiviati i messaggi durante la consegna e dove vengono applicate le operazioni in transito. Per saperne di più, consulta Configura le policy di archiviazione dei messaggi.

  • Aggiornamento di un trigger: se aggiorni un trigger prima che venga recapitato l'evento generato, l'evento viene indirizzato in base al filtro precedente e recapitato 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 di messaggio.

  • 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, viene eseguito un nuovo tentativo di invio dell'evento 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.

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 massimo di profondità nidificata 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.