事件交付偵錯 - Amazon EventBridge
重試事件傳送使用無效字母佇列

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

事件交付偵錯

事件傳遞問題可能很難識別， EventBridge 提供了一些方法來調試和從事件傳遞失敗中恢復。

如何 EventBridge 重試傳遞事件

有時，事件未成功交付至規則中指定的目標。這可能發生，例如：

  • 如果目標資源不可用

  • 由於網絡條件

如果事件因為可重新擷取的錯誤而未成功傳遞至目標，請 EventBridge 重試傳送事件。您可以設定嘗試的時間長度，以及目標的重試政策設定中重新嘗試的次數。預設情況下， EventBridge 重試傳送事件 24 小時和最多 185 次，並具有指數退回和抖動，或隨機延遲。

如果事件在所有重試嘗試都用盡之後仍未傳遞，則會捨棄該事件，而且 EventBridge不會繼續處理該事件。

使用無效字母佇列來處理未傳遞的事件

若要避免在無法交付至目標後遺失事件，您可以設定無效字母佇列 (DLQ)，並將所有失敗事件傳送至事件，以便稍後處理。

EventBridge DLQ 是標準的 Amazon SQS 佇列， EventBridge 用來儲存無法成功傳遞至目標的事件。建立規則並新增目標時，您可以選擇是否使用 DLQ。設定 DLQ 時，您可以保留任何未成功交付的事件。然後，您可以解決導致事件交付失敗的問題，並在稍後處理事件。

當您為規則的目標設定 DLQ 時， EventBridge 會將叫用失敗的事件傳送到選取的 Amazon SQS 佇列。

事件錯誤以不同的方式進行處理。有些事件會捨棄或傳送至 DLQ，而不會嘗試任何重試。例如，針對由於缺少對目標的許可或目標資源不再存在而導致的錯誤，所有重試嘗試都會失敗，直到採取動作解決基礎問題為止。如果您有的話，請直接 EventBridge 將這些事件傳送至 DLQ，而不是重試。

當事件交付失敗時，會將事件 EventBridge 發佈到 Amazon 指 CloudWatch 標，指出目標invocation失敗。如果您使用 DLQ，則會將其他指標傳送至 CloudWatch包括InvocationsSentToDLQ和InvocationsFailedToBeSentToDLQ。

如果您用 AWS KMS 客戶受管金鑰 來加密靜態事件，也可以為事件匯流排指定 DLQ。如需詳細資訊，請參閱 使用無效字母佇列擷取加密的事件錯誤。

DLQ 中的每則訊息都會包含下列自訂屬性：

  • RULE_ARN

  • TARGET_ARN

  • ERROR_CODE

    以下是 DLQ 可傳回的錯誤代碼範例：

    • CONNECTION_FAILURE

    • CROSS_ACCOUNT_INGESTION_FAILED

    • CROSS_REGION_INGESTION_FAILED

    • ERROR_FROM_TARGET

    • EVENTS_IN_BATCH_REQUEST_REJECTED

    • EVENTS_IN_BATCH_REQUEST_REJECTED

    • FAILED_TO_ASSUME_ROLE

    • INTERNAL_ERROR

    • INVALID_JSON

    • INVALID_PARAMETER

    • NO_PERMISSIONS

    • NO_RESOURCE

    • RESOURCE_ALREADY_EXISTS

    • RESOURCE_LIMIT_EXCEEDED

    • RESOURCE_MODIFICATION_COLLISION

    • SDK_CLIENT_ERROR

    • THIRD_ACCOUNT_HOP_DETECTED

    • THIRD_REGION_HOP_DETECTED

    • THROTTLING

    • TIMEOUT

    • TRANSIENT_ASSUME_ROLE

    • UNKNOWN

  • ERROR_MESSAGE

  • EXHAUSTED_RETRY_CONDITION

    可能回傳以下條件：

    • MaximumRetryAttempts

    • MaximumEventAgeInSeconds

  • RETRY_ATTEMPTS

下面的影片介紹了設定 DLQ：

使用無效字母佇列的考量

設定 DLQ 時，請考慮下列事項。 EventBridge

  • 僅支援標準佇列。您無法將 FIFO 佇列用於中的 DLQ。 EventBridge

  • EventBridge 在訊息中包含事件中繼資料和訊息屬性，包括：「錯誤碼」、「錯誤訊息」、「用盡重試條件」、「規則 ARN」、「重試嘗試次數」和「目標 ARN」。您可以使用這些值來識別事件和失敗原因。

  • 相同帳戶中 DLQ 的許可：

    • 如果您使用主控台將目標新增至規則，並在同一帳戶中選擇 Amazon SQS 佇列，則授予佇列 EventBridge 存取權的資源型政策會附加至佇列。

    • 如果您使用 EventBridge API 的PutTargets操作新增或更新規則的目標，並在同一帳戶中選擇 Amazon SQS 佇列，則必須手動授與所選佇列的許可。如需進一步了解，請參閱將許可授予無效字母佇列。

  • 從不同 AWS 帳戶使用 Amazon SQS 佇列的許可。

    • 如果您從主控台建立規則，則不會顯示來自其他帳戶的佇列供您選取。您必須為其他帳戶中的佇列提供 ARN，然後手動附加以資源為基礎的政策，以授予佇列的許可。如需進一步了解，請參閱將許可授予無效字母佇列。

    • 如果您使用 API 建立規則，則必須手動將以資源為基礎的政策附加到另一個帳戶中作為無效字母佇列的 SQS 佇列。如需進一步了解，請參閱將許可授予無效字母佇列。

  • 您使用的 Amazon SQS 佇列必須位於建立規則的相同區域。

將許可授予無效字母佇列

若要成功地將事件傳遞至佇列， EventBridge 必須具有這樣做的權限。當您使用 EventBridge 主控台指定 DLQ 時，會自動新增權限。其中包含：

如果您使用 API 指定 DLQ，或使用其他 AWS 帳戶中的佇列，則必須手動建立以資源為基礎的政策，以授與所需權限，然後將其附加至佇列。

目標無效字母佇列權限範例

以下以資源為基礎的政策示範如何授與將事件訊息傳送 EventBridge 至 Amazon SQS 佇列的必要許可。此原則範例會授與 EventBridge 服務權限，以便使用SendMessage作業將訊息傳送至名為 "MyEventDLQ" 的佇列。佇列必須位於帳戶 123456789012 中的 us-west-2 區域中 AWS 。此Condition陳述式只允許來自帳戶 123456789012 中 us-west-2 區域中建立的名稱為 MyTestRule "" 的規則的請求。 AWS 

{
  "Sid": "Dead-letter queue permissions",
  "Effect": "Allow",
  "Principal": {
     "Service": "events.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:us-west-2:123456789012:MyEventDLQ",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:us-west-2:123456789012:rule/MyTestRule"
    }
  }
}

事件匯流排無效字母佇列權限範例

下列以資源為基礎的原則示範如何在為事件匯流排指定 DLQ 時授與必要權限。在此情況下，請aws:SourceArn指定事件傳送至 DLQ 之事件匯流排的 ARN。在此範例中，佇列必須與事件匯流排位於相同的區域。

{
  "Sid": "Dead-letter queue permissions",
  "Effect": "Allow",
  "Principal": {
     "Service": "events.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:region:account-id:queue-name",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:region:account-id:event-bus/event-bus-arn"
    }
  }
}

若要將政策附加到佇列，請使用 Amazon SQS 主控台，開啟佇列，然後選擇存取政策並編輯政策。您也可以使用 AWS CLI。如需進一步了解，請參閱Amazon SQS 許可。

如何從無效字母佇列重新傳送事件

您可以以下列兩種方式將訊息從無效字母佇列中移出：

  • 避免編寫 Amazon SQS 消費者邏輯 - 將無效字母佇列設為 Lambda 函數的事件來源，以耗盡無效字母佇列。

  • 撰寫 Amazon SQS 取用者邏輯 — 使用 Amazon SQS API、 AWS 開發套件或撰寫自訂 AWS CLI 取用者邏輯，以便輪詢、處理和刪除 DLQ 中的訊息。