Problemas conocidos de Eventarc estándar

En esta página, se enumeran los problemas conocidos de Eventarc Estándar.

También puedes verificar los problemas existentes o abrir problemas nuevos desde la herramienta pública de seguimiento de errores.

Aprovisionamiento y tiempos

  • Tiempo de implementación del activador: Los activadores recién creados pueden tardar hasta dos minutos en comenzar a funcionar.

  • Aprovisionamiento del agente de servicio: Cuando creas un activador de Eventarc por primera vez en un proyecto de Google Cloud , es posible que haya un retraso en el aprovisionamiento del agente de servicio de Eventarc. Por lo general, este problema se puede resolver si intentas crear el activador de nuevo. Para obtener más información, consulta Errores de permiso denegado.

Configuración del activador

  • Activadores entre proyectos: Aún no se admiten los activadores entre proyectos. El servicio que recibe los eventos para el activador debe estar en el mismo proyecto deGoogle Cloud que el activador. Si las solicitudes a tu servicio se activan mediante mensajes publicados en un tema de Pub/Sub, el tema también debe estar en el mismo proyecto que el activador. Consulta Cómo enrutar eventos entre proyectos de Google Cloud .

  • Activadores de los registros de auditoría de Cloud para Compute Engine: Sin importar dónde se encuentre la instancia de máquina virtual, los activadores de los registros de auditoría de Cloud para Compute Engine generan eventos que se originan en una sola región: us-central1. Al crear tu activador, asegúrate de que la ubicación del activador esté configurada como us-central1 o global.

  • Activadores de Cloud Storage en ubicaciones multirregionales: Los activadores de Cloud Storage pueden fallar si un evento de Cloud Storage se origina en una región que no permite tu política de almacenamiento de mensajes de Pub/Sub y si se aplican operaciones en tránsito ("enforceInTransit": true). Cuando crees un activador de Cloud Storage en una ubicación multirregional, asegúrate de que tu política de almacenamiento de mensajes permita todas las regiones de origen dentro de esa multirregión. Esta política define dónde se almacenan los mensajes durante la entrega y dónde se aplican las operaciones en tránsito. Para obtener más información, consulta Configura políticas de almacenamiento de mensajes.

  • Actualización de un activador: Si actualizas un activador antes de que se haya entregado su evento generado, el evento se enruta de acuerdo con el filtrado anterior y se entrega al destino original dentro de los tres días posteriores a la generación del evento. El nuevo filtro se aplica a los eventos generados después de tu actualización.

Cargas útiles y entrega de eventos

  • Transmisión duplicada de Registros de auditoría de Cloud: Se conoce una transmisión duplicada de Registros de auditoría de Cloud desde algunas fuentes de eventos de Google Cloud . Cuando se publican registros duplicados, los eventos duplicados se entregan a los destinos. Para evitar estos eventos duplicados, debes crear activadores para los campos que garantizan que el evento sea único. Esto se aplica a los siguientes 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)

    Ten en cuenta que, como Workflows controla la anulación de duplicación de eventos, no tienes que asegurarte de que el evento sea único cuando crees un activador para Workflows.

  • Cómo controlar errores de mensajes para eventos directos de Pub/Sub: Los eventos directos de Pub/Sub no incluyen un campo delivery_attempt, a menos que el destino del evento sea Cloud Run o funciones de Cloud Run. Esto podría afectar tu control de errores en los mensajes.

  • Codificación de la carga útil del evento: Para algunos proveedores de eventos, puedes elegir entre codificar la carga útil del evento como application/json o application/protobuf. Sin embargo, una carga útil de evento con formato JSON es más grande que una en Protobuf, y esto puede afectar la confiabilidad según el destino de tu evento y sus límites de tamaño. Una vez alcanzado este límite, se reintenta el evento según las características de reintento de la capa de transporte de Eventarc, Pub/Sub. Aprende a controlar las fallas de los mensajes de Pub/Sub una vez hecha la cantidad máxima de intentos.

Destinos y límites

  • Tamaño de los argumentos de Workflows: Mientras uses Workflows como destino para un activador de Eventarc, los eventos que superen el tamaño máximo de argumentos de Workflows no activarán las ejecuciones de flujos de trabajo. Para obtener más información, consulta Cuotas y límites.

  • Límite de profundidad de anidado para las entradas de registro: El límite de profundidad de anidado máximo en cada entrada de registro estructurada para los activadores que usan los registros de auditoría de Cloud es de 64 niveles. Los eventos de registro que exceden este límite se descartan y no se entregan con Eventarc.