Amazon EventBridge 管道錯誤處理和故障排除 - Amazon EventBridge

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

Amazon EventBridge 管道錯誤處理和故障排除

瞭解 EventBridge 管道可能遇到的錯誤類型,以及如何 EventBridge 處理這些錯誤,可協助您疑難排解管道的問題。

重試行為和錯誤處理

EventBridge 管道會針對來源服務、擴充或目標服務或任何可重試的 AWS 失敗,自動重試擴充和目標叫用。 EventBridge但是,如果擴充或目標客戶實作傳回失敗,則管道輪詢輸送量將逐漸退回。對於幾乎連續的 4xx 錯誤 (例如資源有授權問題IAM或缺少資源),管道可以自動停用,並在. StateReason

管道調用錯誤和重試行為

當您調用管道時,可能會發生兩種主要類型的錯誤:管道內部錯誤客戶調用錯誤

管內部錯誤

管道內部錯誤是由 P EventBridge ipes 服務管理的呼叫方面所造成的錯誤。

這些類型的錯誤可能包括以下問題:

  • 嘗試呼叫客戶 targer 服務時發生HTTP連線失敗

  • 管道服務本身的可用性暫時下降。

一般而言,P EventBridge ipes 會無限次重試內部錯誤,並且只有在來源中的記錄到期時才會停止。

對於具有串流來源的 EventBridge 管道,Pipes 不會將內部錯誤的重試次數與串流來源的重試政策上指定的最大重試次數計算。對於具有 Amazon SQS 來源的 EventBridge 管道,Pipes 不會將內部錯誤的重試次數與 Amazon SQS 來源的最大接收計數計算。

客戶調用錯誤

客戶調用錯誤是由用戶管理的配置或代碼引起的錯誤。

這些類型的錯誤可能包括以下問題:

  • 管道的權限不足,無法調用目標。

  • 同步呼叫的客戶 Lambda、Step Functions、API目標或API閘道端點中出現邏輯錯誤。

對於客戶調用錯誤,P EventBridge ipes 會執行以下操作:

  • 對於具有串流來源的管 EventBridge 道,Pipes 會重試直到管道重試原則上設定的重試次數上限,或直到記錄保留天數上限到期 (以先到者為準) 為止。

  • 對於具有 Amazon SQS 來源的 EventBridge 管道,Pipes 會重試客戶錯誤,直到來源佇列上的最大接收計數為止。

  • 對於具有 Apache Kafka 或 Amazon MQ 來源的管道, EventBridge 重試客戶錯誤的方式與重試內部錯誤相同。

對於具有計算目標的管道,您必須同步調用管道,以便 P EventBridge ipes 知道從客戶計算邏輯引發的任何運行時錯誤,然後重試此類錯誤。管道無法重試從 Step Functions 標準工作流程邏輯擲回的錯誤,因為必須以非同步方式調用此目標。

對於 Amazon SQS 和串流來源 (例如 Kinesis 和 DynamoDB), EventBridge 管道支援目標故障的部分批次失敗處理。如需詳細資訊,請參閱部分批次失敗

管DLQ行為

管道從源繼承無效字母 queue (DLQ) 行為:

  • 如果來源 Amazon SQS 佇列已設定DLQ,則訊息會在指定的嘗試次數後自動傳送到該處。

  • 對於串流來源 (例如 DynamoDB 和 Kinesis 串流),您可以為管道和路由事件設定一個DLQ。DynamoDB 和 Kinesis 串流來源支援 Amazon SQS 佇列和 Amazon SNS 主題做為目標。DLQ

如果您DeadLetterConfig為具有 Kinesis 或 DynamoDB 來源的管路指定,請確定管道上的MaximumRecordAgeInSeconds屬性小於來源事件的MaximumRecordAge屬性。 MaximumRecordAgeInSeconds控制管道輪詢器何時放棄事件並將其傳遞給DLQ和MaximumRecordAge控制在來源串流中可見的訊息在刪除之前的時間長度。因此,請設MaximumRecordAgeInSeconds定為小於來源的值,MaximumRecordAge以便在事件傳送至事件之間有足夠的時間DLQ,以及由來源自動刪除它時,以便您判斷事件為何會移至DLQ。

對於 Amazon MQ 來源,DLQ可以直接在訊息代理程式上設定。

EventBridge 管道不支援串流來源的先DLQs進先出 (FIFO)。

EventBridge 管道不支援 DLQ Amazon MSK 串流和自我管理的 Apache 卡夫卡串流來源。

管路故障狀態

建立、刪除和更新管道是非同步作業,可能會導致失敗狀態。同樣地,管道可能會因故障而自動停用。在所有情況下,管道 StateReason 都會提供協助疑難排解故障的資訊。

以下是 StateReason 可能值的清單範例:

  • 找不到串流。若要繼續處理,請刪除並建立新的管道。

  • 管道沒有執行佇列作業所需的權限 (sqs: ReceiveMessage、sqs: DeleteMessage 和 sqs:) GetQueueAttributes

  • 連線錯誤。您VPC必須能夠連接到管道。您可以透過將NAT閘道或VPC端點設定為管道資料來提供存取權。有關如何設置NAT網關或VPC端點到管道數據,請查看文檔。 AWS

  • MSK叢集沒有與其相關聯的安全群組

管道可能會隨著更新而自動停止 StateReason。可能的原因包括:

  • 設定為擴充的 Step Functions 標準工作流程。

  • 設定為要同步調用之目標的「步驟函數」標準工作流程。

自訂加密失敗

如果將來源設定為使用 AWS KMS 自訂加密金鑰 (CMK),而不是 AWS-managed AWS KMS 金鑰,則必須明確授與管道的執行角色解密權限。若要這麼做,請在自訂CMK原則中包含下列額外權限:

{ "Sid": "Allow Pipes access", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::01234567890:role/service-role/Amazon_EventBridge_Pipe_DDBStreamSourcePipe_12345678" }, "Action": "kms:Decrypt", "Resource": "*" }

將上述角色替換為管道的執行角色。

接下來,請確保將相同的KMS權限新增至您的管道執行角色。

這對於所有管來源都是如此 AWS KMS CMK,包括:

  • Amazon DynamoDB Streams

  • Amazon Kinesis Data Streams

  • Amazon MQ

  • Amazon MSK

  • Amazon SQS