对 Step Functions 中的问题进行故障排除

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

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

如果您在使用 Step Functions 时遇到问题，请参阅以下故障排除资源。

以下主题为您可能遇到的与 Step Functions 状态机、服务集成、活动和工作流程相关的错误和问题提供故障排除建议。如果您发现某个问题未在此处列出，可以使用此页上的 Feedback 按钮来报告。

有关更多故障排除建议和常见支持问题的答案，请访问AWS 知识中心。

一般故障排除

我无法创建状态机。

与状态机关联的 IAM 角色可能没有足够的权限。检查 IAM 角色的权限，包括 AWS 服务集成任务、X-Ray 和 CloudWatch 日志记录的权限。.sync 任务状态需要额外的权限。

我无法使用 JsonPath 来引用上一个任务的输出。

对于 a JsonPath，JSON 密钥必须以结尾.$。这意味着 a JsonPath 只能在键值对中使用。如果你想使用 JsonPath 其他地方，比如数组，你可以使用内部函数。例如，可以使用类似以下代码的内容：

任务 A 的输出：

{
    "sample": "test"
}

任务 B：

{
    "JsonPathSample.$": "$.sample"
}

状态转换出现延迟。

对于标准工作流，状态转换的数量是有限制的。当超过状态转换限制时，Step Functions 会延迟状态转换，直到配额存储桶填满。可以通过查看 “ CloudWatch 指标” 页面执行指标部分中的ExecutionThrottled指标来监控状态转换限制情况。

启动新的标准工作流执行时，会执行失败并出现 ExecutionLimitExceeded 错误。

Step Functions 每次的开放执行上限为 100 万个 AWS 账户 。 AWS 区域如果超过此限制，Step Function 会抛出 ExecutionLimitExceeded 错误。此限制不适用于快速工作流程。可以使用 OpenExecutionCount 来跟踪何时接近 OpenExecutionLimit，并创建警报来在该事件中主动通知您。OpenExecutionCount 是已开启工作流程的大致数量。有关更多信息，请参阅 执行指标。

一个处于并行状态的分支出现故障，导致整个执行失败。

这是一个预期行为。为避免在使用并行状态时遇到故障，请将 Step Functions 配置为捕获每个分支抛出的错误。

服务集成故障排除

在下游服务中，我的作业已经完成，但在 Functions 中，任务状态仍为“进行中”或延迟完成。

对于.sync服务集成模式，Step Functions 使用下游 EventBridge APIs规则或两者的组合来检测下游作业状态。对于某些服务，Step Functions 不会创建要监控的 EventBridge 规则。例如，对于 AWS Glue 服务集成，Step Functions 不是使用 EventBridge 规则，而是glue:GetJobRun调用。由于 API 调用的频率，下游任务完成时间与 Step Functions 任务完成时间存在差异。Step Functions 需要 IAM 权限才能管理 EventBridge 规则和调用下游服务。有关执行角色权限不足如何影响任务完成的详细信息，请参阅使用.sync 执行任务的其他权限。

我想从嵌套状态机执行中返回 JSON 输出。

Step Functions 有两个同步服务集成：startExecution.sync 和 startExecution.sync:2。两者都将等待嵌套状态机完成，但它们返回不同的 Output 格式。您可以使用 startExecution.sync:2 在 Output 下返回 JSON 输出。

我无法从另一个账户调用 Lambda 函数。

通过跨账户支持访问 Lambda 函数

如果您的地区支持跨账户访问 AWS 资源，请使用以下方法从其他账户调用 Lambda 函数。

要在工作流中调用跨账户资源，请执行以下操作：

有关示例，请参阅教程中的在 Step Functi AWS ons 中访问跨账户资源。

有关指定跨账户资源的 Task 状态定义示例，请参阅 Task 状态的“凭证”字段示例。

在没有跨账户支持的情况下访问 Lambda 函数

如果您所在的地区无法跨账户访问 AWS 资源，请使用以下方法从其他账户调用 Lambda 函数。

在 Task 状态的 Resource 字段中，使用 arn:aws:states:::lambda:invoke 并传递参数中的 FunctionArn。与状态机关联的 IAM 角色必须拥有调用跨账户 Lambda 函数的正确权限：lambda:invokeFunction。

{  
   "StartAt":"CallLambda",
   "States":{  
      "CallLambda":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:us-west-2:123456789012:function:my-function"
         },
         "End":true
      }
   }
}

我无法看到从 .waitForTaskToken 状态传递的任务令牌。

您必须在 Task 状态的 Parameters 字段中传递任务令牌。例如，您可以使用与以下代码类似的内容。

{  
   "StartAt":"taskToken",
   "States":{  
      "taskToken":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
         "Parameters":{  
            "FunctionName":"get-model-review-decision",
            "Payload":{  
               "token.$":"$$.Task.Token"
            },
         },
         "End":true
      }
   }
}

活动故障排除

我的状态机执行卡在活动状态。

只有在您使用 GetActivityTaskAPI 操作轮询任务令牌后，活动任务状态才会启动。最佳实操是添加任务级超时，用于避免执行卡住。有关更多信息，请参阅 使用超时来避免 Step Functions 工作流程执行卡顿。

如果您的状态机在ActivityScheduled事件中停滞不前，则表明您的活动工作人员队列存在问题或规模不足。您应该监控该ActivityScheduleTime CloudWatch 指标，并在该时间延长时设置警报。不过，要想超时处理任何卡住的状态机执行（其中 Activity 状态没有转换到 ActivityStarted 状态），可在状态机级别定义超时。为此，请在状态机定义的开头指定一个 TimeoutSeconds 字段，该字段位于 States 字段之外。

我的活动工作线程在等待任务令牌时超时。

工作人员使用 GetActivityTaskAPI 操作来检索具有指定活动 ARN 的任务，该任务计划由正在运行的状态机执行。 GetActivityTask开始长时间的轮询，因此该服务保持 HTTP 连接处于打开状态，并在任务可用时立即做出响应。服务在响应之前保留请求的最长时间为 60 秒。如果在 60 秒内没有任务可用，轮询将返回一个带空字符串的 taskToken。要避免这种超时，请在 AWS SDK 或用于进行 API 调用的客户端中将客户端套接字配置为至少 65 秒的超时时间。

快速工作流程故障排除

我的应用程序在收到 StartSyncExecution API 调用的响应之前超时。

在用于进行 API 调用的 AWS SDK 或客户端中配置客户端套接字超时。要接收响应，超时值必须高于快速工作流执行的持续时间。

我无法查看执行历史记录，无法解决快速工作流故障。

快速工作流不会在 AWS Step Functions中记录执行历史。相反，您必须开启 CloudWatch 日志记录。开启日志记录后，你可以使用 L CloudWatch ogs Insights 查询来查看 Express Workflow 的执行情况。如果在执行选项卡中选择启用按钮，还可以在 Step Functions 控制台上查看快速工作流的执行历史记录。有关更多信息，请参阅 在 Step Functions 控制台中查看执行详细信息。

根据持续时间列出执行情况：

fields ispresent(execution_arn) as exec_arn
| filter exec_arn 
| filter type in ["ExecutionStarted", "ExecutionSucceeded", "ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
| stats latest(type) as status, 
  tomillis(earliest(event_timestamp)) as UTC_starttime, 
  tomillis(latest(event_timestamp)) as UTC_endtime, 
  latest(event_timestamp) - earliest(event_timestamp) as duration_in_ms  by execution_arn
| sort duration_in_ms desc

列出失败和取消的执行：

fields ispresent(execution_arn) as isRes | filter type in ["ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]