Eventarc에서 알려진 문제

이 페이지에는 Eventarc에서 알려진 문제가 나와 있습니다.

공개 Issue Tracker에서도 기존 문제를 확인하거나 새로운 문제를 개설할 수 있습니다.

  • 새로 생성된 트리거가 작동하는 데 최대 2분이 걸릴 수 있습니다.

  • 생성된 이벤트가 전송되기 전에 트리거를 업데이트하면 이전 필터링에 따라 이벤트가 라우팅되고 이벤트 생성 후 3일 이내에 원래 대상으로 전달됩니다. 새 필터링은 업데이트 후에 생성된 이벤트에 적용됩니다.

  • 일부 Google Cloud 이벤트 소스에서 Cloud 감사 로그의 전송이 중복되는 알려진 문제가 발생합니다. 중복 로그가 게시되면 중복된 이벤트가 대상에 전달됩니다. 이러한 중복된 이벤트를 방지하기 위해 이벤트가 고유하도록 보장하는 필드의 트리거를 만들어야 합니다. 이 문제는 다음 이벤트 유형에 적용됩니다.

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

    Workflows에서 이벤트 중복 삭제를 처리하므로 Workflow의 트리거를 만들 때 이벤트가 고유하지 않아도 됩니다.

  • 프로젝트 간 트리거는 아직 지원되지 않습니다. 트리거의 이벤트를 수신하는 서비스는 트리거와 동일한 Google Cloud 프로젝트에 있어야 합니다. Pub/Sub 주제에 게시되는 메시지에 의해 서비스 요청이 트리거되는 경우 주제는 트리거와 동일한 프로젝트에 있어야 합니다. 여러 Google Cloud 프로젝트에 걸쳐 이벤트 라우팅을 참조하세요.

  • 가상 머신 인스턴스가 실제로 있는 위치와는 관계없이 Compute Engine에 대한 Cloud 감사 로그 트리거는 단일 리전 us-central1에서 이벤트를 발생시킵니다. 트리거를 만들 때 트리거 위치가 us-central1 또는 global로 설정되었는지 확인하세요.

  • 일부 이벤트 제공업체의 경우 이벤트 페이로드를 application/json 또는 application/protobuf로 인코딩하도록 선택할 수 있습니다. 하지만 JSON으로 형식이 지정된 이벤트 페이로드는 Protobuf에 형식이 지정된 이벤트 페이로드보다 크며, 그로 인해 이벤트 대상 및 이벤트 크기 한도에 따라 안정성에 영향을 미칠 수 있습니다. 이 한도에 도달하면 Eventarc의 전송 레이어인 Pub/Sub의 재시도 특성에 따라 이벤트가 재시도됩니다. 최대 재시도 횟수에 도달하면 Pub/Sub 메시지 실패를 처리하는 방법을 알아보세요.

  • Workflows를 Eventarc 트리거의 대상으로 사용할 때는 최대 Workflows 인수 크기보다 큰 이벤트로 워크플로 실행이 트리거되지 않습니다. 자세한 내용은 할당량 및 한도를 참조하세요.

  • Cloud 감사 로그를 사용하는 트리거의 각 구조화된 로그 항목에 대한 최대 중첩 깊이 한도는 64개 수준입니다. 이 한도를 초과하는 로그 이벤트는 삭제되고 Eventarc에서 전송되지 않습니다.

  • Google Cloud 프로젝트에서 Eventarc 트리거를 처음 만들 때 Eventarc 서비스 에이전트 프로비저닝이 지연될 수 있습니다. 이 문제는 일반적으로 트리거를 다시 만들면 해결할 수 있습니다. 자세한 내용은 권한 거부 오류를 참조하세요.