Problèmes connus concernant Eventarc Standard

Cette page répertorie les problèmes connus liés à Eventarc Standard.

Vous pouvez également consulter les problèmes existants ou signaler de nouveaux problèmes dans les outils publics de suivi des problèmes.

Provisionnement et timing

  • Délai de déploiement des déclencheurs : l'activation des déclencheurs nouvellement créés peut prendre jusqu'à deux minutes.

  • Provisionnement de l'agent de service : lorsque vous créez un déclencheur Eventarc pour la première fois dans un projet Google Cloud , le provisionnement de l'agent de service Eventarc peut prendre quelques instants. Ce problème peut généralement être résolu en essayant à nouveau de créer le déclencheur. Pour en savoir plus, consultez Erreurs d'autorisation refusée.

Configuration du déclencheur

  • Déclencheurs multiprojets : les déclencheurs multiprojets ne sont pas encore acceptés. Le service qui reçoit les événements pour le déclencheur doit se trouver dans le même projetGoogle Cloud que le déclencheur. Si les requêtes adressées à votre service sont déclenchées par des messages publiés dans un sujet Pub/Sub, ce sujet doit également se trouver dans le même projet que le déclencheur. Consultez Acheminer des événements entre les projets Google Cloud .

  • Déclencheurs Cloud Audit Logs pour Compute Engine : quel que soit l'emplacement réel de l'instance de machine virtuelle, les déclencheurs Cloud Audit Logs pour Compute Engine produisent des événements provenant d'une seule région : us-central1. Lorsque vous créez votre déclencheur, assurez-vous que l'emplacement du déclencheur est défini sur us-central1 ou global.

  • Déclencheurs Cloud Storage dans les emplacements multirégionaux : les déclencheurs Cloud Storage peuvent échouer si un événement Cloud Storage provient d'une région non autorisée par votre règlement sur le stockage des messages Pub/Sub et si les opérations en transit sont appliquées ("enforceInTransit": true). Lorsque vous créez un déclencheur Cloud Storage dans un emplacement multirégional, assurez-vous que votre règlement sur le stockage des messages autorise toutes les régions sources de cette multirégion. Ce règlement définit l'emplacement de stockage des messages lors de leur distribution et l'emplacement où les opérations en transit sont appliquées. Pour en savoir plus, consultez Configurer des règles de stockage des messages.

  • Mise à jour d'un déclencheur : si vous mettez à jour un déclencheur avant que son événement généré ne soit distribué, l'événement est acheminé conformément au filtrage précédent et envoyé à la destination d'origine dans les trois jours suivant la génération de l'événement. Le nouveau filtrage est appliqué aux événements générés après votre mise à jour.

Charge utile et diffusion des événements

  • Transmission en double des journaux d'audit Cloud : la transmission en double de Cloud Audit Logs à partir de certaines sources d'événements Google Cloud est un problème connu. Lorsque des journaux sont publiés en double, des événements en double sont distribués aux destinations. Pour éviter ces doublons, vous devez créer des déclencheurs pour les champs qui assurent l'unicité de l'événement. Cette règle s'applique aux types d'événements suivants :

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

    Notez que, comme Workflows gère la déduplication des événements, vous n'avez pas besoin de vous assurer que l'événement est unique lorsque vous créez un déclencheur pour Workflows.

  • Gérer les échecs de messages pour les événements Pub/Sub directs : Les événements Pub/Sub directs n'incluent pas de champ delivery_attempt, sauf si la destination de l'événement est Cloud Run ou des fonctions Cloud Run. Cela peut avoir un impact sur la gestion des échecs de messages.

  • Encodage de la charge utile de l'événement : pour certains fournisseurs d'événements, vous pouvez choisir d'encoder la charge utile de l'événement en tant que application/json ou application/protobuf. Cependant, une charge utile d'événement au format JSON est plus grande qu'une charge utile au format Protobuf, ce qui peut avoir un impact sur la fiabilité en fonction de votre destination d'événement et de ses limites de taille. Lorsque cette limite est atteinte, l'événement est relancé en fonction des caractéristiques de nouvelles tentatives de la couche de transport d'Eventarc, Pub/Sub. Découvrez comment gérer les échecs de messages Pub/Sub si le nombre maximal de tentatives est atteint.

Destinations et limites

  • Taille des arguments Workflows : lorsque vous utilisez Workflows comme destination d'un déclencheur Eventarc, les événements supérieurs à la taille maximale des arguments Workflows ne déclenchent pas d'exécution de workflow. Pour en savoir plus, consultez la page Quotas et limites.

  • Limite de profondeur des entrées de journal : la limite maximale de profondeur des entrées imbriquées de journaux structurés pour les déclencheurs utilisant Cloud Audit Logs est de 64 niveaux. Les événements de journaux qui dépassent cette limite sont supprimés et ne sont pas diffusés par Eventarc.