本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Pip EventBridge es 错误处理和故障排除
<a name="eb-pipes-error-troubleshooting"></a>

了解 EventBridge 管道可能遇到的错误类型以及如何 EventBridge 处理这些错误，可以帮助您解决管道问题。

## 重试行为和错误处理
<a name="eb-pipes-error-handling"></a>

EventBridge 如果源服务、扩充服务或目标服务出现任何可重试的 AWS 故障，Pipes 会自动重试扩充和目标调用，或者。 EventBridge但是，如果富集或目标客户实施返回故障，管道轮询吞吐量将逐渐退避。对于几乎持续的 4xx 错误（例如 IAM 的授权问题或资源缺失），可以自动禁用管道，并在 `StateReason` 中提供一条消息进行解释。

## 管道调用错误和重试行为
<a name="eb-pipes-error-invoke"></a>

调用管道时，可能会出现两种主要类型的错误：*管道内部错误* 和*客户调用错误*。

### 管道内部错误
<a name="eb-pipes-error-invoke-internal"></a>

管道内部错误是由 EventBridge 管道服务管理的调用的各个方面导致的错误。

这些类型的错误可能包括以下问题：
+ 尝试调用客户目标服务时 HTTP 连接失败
+ 管道服务本身的可用性暂时下降。

通常，Pip EventBridge es 会无限次重试内部错误，并且仅在源中的记录到期时才会停止。

对于带有流源的管道， EventBridge Pipes 不会将内部错误的重试次数与流源的重试策略中指定的最大重试次数进行计数。对于具有 Amazon SQS 源的 EventBridge 管道，Pipes 不会将内部错误的重试次数计入亚马逊 SQS 来源的最大接收次数。

### 客户调用错误
<a name="eb-pipes-error-invoke-customer"></a>

客户调用错误是由于用户管理的配置或代码而导致的错误。

这些类型的错误可能包括以下问题：
+ 管道的权限不足，无法调用目标。
+ 同步调用的客户 Lambda、Step Functions、API 目标或 API Gateway 端点中的逻辑错误。

对于客户调用错误，Pip EventBridge es 会执行以下操作：
+ 对于带有流源的管道，Pipes 会重试直至 EventBridge 管道重试策略上配置的最大重试次数，或者直到最大记录期限到期（以先到者为准）。
+ 对于具有 Amazon SQS 源的 EventBridge 管道，Pipes 会重试客户错误，直至达到源队列的最大接收计数。
+ 对于带有 Apache Kafka 或 Amazon MQ 源的管道 EventBridge ，重试客户错误的方式与重试内部错误的方式相同。

对于具有计算目标的管道，必须同步调用管 EventBridge 道，这样 Pipes 才能知道客户计算逻辑引发的任何运行时错误并重试此类错误。Pipes 无法重试从 Step Functions 标准工作流程的逻辑中引发的错误，因为必须异步调用此目标。

对于 Amazon SQS 和流源，例如 Kinesis 和 DynamoDB，Pipes 支持对目标故障进行部分 EventBridge 批量故障处理。有关更多信息，请参阅[部分批处理故障](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes-batching-concurrency.html#pipes-partial-batch-failure)。

## 亚马逊 SQS 源代码重试时间为 maxBatchWindow InSeconds
<a name="eb-pipes-sqs-retry-timing"></a>

使用 Amazon SQS 队列作为管道源时，重试计时行为会有所不同，具体取决于您是否配置了以下参数：`maxBatchWindowInSeconds`
+ **无 maxBatchWindow InSeconds** — SQS 轮询器使用队列的可见性超时设置进行重试。处理失败时，消息将在可见性超时持续时间内保持隐藏状态，然后才可供重试。要减少重试延迟，请将队列的可见性超时配置为适合您的用例的值。
+ **Wit maxBatchWindow InSeconds** h — SQS 轮询器使用以下公式动态设置轮询消息的可见性超时:。`functionTimeout + maxBatchWindowInSeconds + 30 seconds`对于 Pip EventBridge es，函数超时为 7 分钟，因此可见性超时约为 7.5 分钟，再加上您配置的`maxBatchWindowInSeconds`值。处理失败时，消息会在这段长时间内保持隐藏状态，然后才可供重试。

当使用[部分批量响应](eb-pipes-batching-concurrency.md#pipes-partial-batch-failure)时，这种行为尤其重要。如果您需要更快的重试时间，请避免设置`maxBatchWindowInSeconds`，而是依赖队列配置的可见性超时。

## 管道 DLQ 行为
<a name="eb-pipes-dlq-behavior"></a>

管道从源继承死信队列 (DLQ) 行为：
+ 如果源 Amazon SQS 队列配置了 DLQ，则消息将在尝试了指定次数后自动传送到该队列。
+ 对于流源，例如 DynamoDB 和 Kinesis 流，您可以为管道配置 DLQ 并路由事件。DynamoDB 和 Kinesis 流源支持使用 Amazon SQS 队列和 Amazon SNS 主题作为 DLQ 目标。

如果您为具有 Kinesis 或 DynamoDB 源的管道指定 `DeadLetterConfig`，请确保管道的 `MaximumRecordAgeInSeconds` 属性小于源事件的 `MaximumRecordAge` 属性。`MaximumRecordAgeInSeconds` 控制管道轮询器何时放弃事件并将其传递给 DLQ，`MaximumRecordAge` 控制消息在被删除之前在源流中的可见时长。因此，请将 `MaximumRecordAgeInSeconds` 设置为小于源 `MaximumRecordAge` 的值，这样在事件发送到 DLQ 到事件被源自动删除之间，您就有足够的时间来确定事件进入 DLQ 的原因。

该`MaximumRecordAgeInSeconds`参数的应用与重试行为无关。轮询流源时，如果记录的存在时间超过该`MaximumRecordAgeInSeconds`值， EventBridge 无论是否存在重试情况，Pipes 都不会处理该记录。这些记录直接发送到 DLQ（如果已配置），无需任何处理尝试。

对于 Amazon MQ 源，可以直接在消息代理上配置 DLQ。

EventBridge 对于直播源，Pipes 不支持先进先出 (FIFO) DLQs 。

EventBridge Pipes 不支持 Amazon MSK 直播和自托管 Apache Kafka 直播源的 DLQ。

## 管道故障状态
<a name="eb-pipes-failure-states"></a>

创建、删除和更新管道是异步操作，可能会导致失败状态。同样，管道可能会因故障而被自动禁用。在所有情况下，管道 `StateReason` 都可提供信息来帮助排除故障。

以下是 `StateReason` 可能值的示例：
+ 未找到流。要恢复处理，请删除管道，然后创建一个新管道。
+ 管道没有执行队列操作所需的权限（sqs: ReceiveMessage、sqs: DeleteMessage 和 sqs:）GetQueueAttributes
+ 连接错误。您的 VPC 必须能够连接到管道。您可以通过配置 NAT 网关或 VPC 端点来提供访问权限。有关如何将 NAT 网关或 VPC 终端节点设置为管道数据，请查看 AWS 文档。
+ MSK 集群没有关联的安全组

管道可能会自动停止并更新 `StateReason`。可能的原因包括：
+ 一个 Step Functions 标准工作流程配置为[富集](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html#pipes-enrichment)。
+ 一个 Step Functions 标准工作流程配置为[同步调用](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html#pipes-invocation)的目标。

## 自定义加密故障
<a name="eb-pipes-error-handling-cms"></a>

如果将源配置为使用 AWS KMS 自定义加密密钥 (CMK) 而不是 AWS托管 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